Difference between revisions of "Abandonware"
(How to reboot an abandoned project)
Revision as of 04:59, 12 October 2010
- 1 How to reboot an abandoned project
- 2 Inspirational sources
How to reboot an abandoned project
This is a page about how to reboot a project that has been abandoned!
Contact original maintainer
Maybe a fork isn't necessary, because the original maintainer is willing to step up if people actually care about the project! Maybe they're just discouraged by perceived lack of interest, or maybe they've actually been doing work in secret. Even if they are no longer interested, they might be able to give you access to the original repository/bugtracker/website so there is no fork. Finally, even if they are unreachable, at least you did them the courtesy of trying to contact them, which may result in better feelings if/when they start contributing back to the new fork/project.
If possible, ask the original maintainer why they stopped development of the project. Did they forsee an obstacle that they weren't able to overcome? If so, you may need to find a fix for this obstacle before you can continue development of the project. If you're in contact with the original developer, they can give you details of where they left off and which options they have explored.
Look for other forks of the project
If you are interested in reviving an abandoned project, there's a chance other people have had the same thought. Step one is to see if you can join anyone else's fork.
If there is no existing fork (or none that is satisfactory) start your own.
Copy the code into a new repository (easy with e.g. git or Github). Set up a new bug tracker and a new mailing list/forum/wiki for community organizing plus a new website/blog/microblog for announcing new developments.
Figure out why people should care
Why should people use your fork instead of the dead original project?
Does your project have a live mailing list, when the parent project's list has died? What features or bugs do you intend to fix in your fork? Do you intend to merge with other forks, and if so, which ones?
This can be done by simply picking up development yourself.
Would you want to join a project if it looks like the developer can't even find the time to post updates to the project's website? I wouldn't. Take the initiative, don't expect other people to do the work for you. Post updates about the project and the progress that it's made recently.
Once you have the skeleton of the project up, however, finding developers who are willing to help you may get easier. You can look for other developers on OpenHatch by going to http://openhatch.org/people/ and searching for people who are interested in the relevant language or related projects. (Or at least you will be able to once that page is no longer broken, see https://openhatch.org/bugs/issue134 )
This isn't as complicated as it sounds, it's as easy as discussing the project on it's mailing list, or adding comments to blog posts of the parent dead project about the alternative fork that you've restarted development on, or even simply writing a blog post about your fork.
Get the word out there that your fork exists, and that it supercedes the parent project. Do your best to make it as obvious as possible for people searching for the parent project that yours is where the development is these days.
Make sure not to jump ahead to this step too soon. Don't advertise that you've fixed bugs or implemented features until you've done it, aka don't advertise your intentions advertise your accomplishments.
Once your project and bug tracker are hosted publicly, there are lots of other ways OpenHatch can help!
- Search for your project's name at http://openhatch.org/+projects/ and if you don't already have a project page on OpenHatch, create one! (Why do you want a project page on OpenHatch?) Fans can say “I want to help” on your project's page. You can learn more about these people, and assign them tasks that they might like to do.
- You can have OpenHatch list your bugs to elicit support from others. Get OpenHatch to crawl your bugtracker! http://openhatch.org/wiki/Bug_trackers
- Mark a few bitesized bugs in your bugtracker, e.g. with a label or keyword. These should be bugs that are relatively trivial to fix, and would make a good starting point for newcomers to the project. OpenHatch remembers these bugs when crawling a bugtracker and keeps track of them, allowing potential contributers to easily notice them. (Don't you need a specific keyword, specifically "bite-size"? And can we get an explanation of bite-size bugs outside of this tutorial?)
Build your community
The final hurdle is to build the community around your new project, try to keep your blog posts frequent, bugs fixed regularly, and seek help from your community (and others, if necessary) when you're stuck on something.
Also, remember to engage your community. Failing to do this can curtail your revival efforts. If someone asks a question, be it on a mailing list or in an IRC channel, make a best effort to respond. This is part of that "don't expect others to do the work for you" thing. Respond to comments on your blog, but obviously not to the detriment of progress on the project. Where this line is drawn is up to you, many projects of many sizes vary greatly on this.
Don't forget to add an OpenHatch "I'd like to help" button to your website! Just go to your OpenHatch project page (for example, here's the GIMP's project page: http://openhatch.org/+projects/GIMP ) and scroll down to the bottom where it says "You can embed the "I want to help" button on your website." and click that link to expose the HTML for embedding the "I want to help" button. For more information on why you want to do this, see http://openhatch.org/blog/2010/let-people-help-your-project-give-them-a-button-to-click/