Best way to keep a large number of hobby projects alive; open sourcing?

Question

Because my time is limited I can usually only focus on one or two of my hobby projects, while the others sit there wasting away.

I am looking for a solution that would allow me to divide my time better. is open sourcing where I take the role of guiding the project realistic, or are there better solutions?

In my case, one project has a reasonably sized community of users going for it but is currently closed source. There have been requests to open source it.

Answer 1

Your projects will still waste away as open source. An open source project takes even more work, because you will have to:

• keep documentation up to date so other developers will be able to understand it
• If you actually get people submitting changes, integrate them or explain to them why their changes can't be included..
• maintain a vision as to what your product is supposed to be, and keep people from implementing features that detract from that vision.

Answer 2

Open-sourcing may indeed be a good idea. If your project is interesting and useful to others, fellow developers may come quicker than you would think. It may also be a great pleasure and motivation for you to see others pick up your work and contribute to it.

On the other hand, if you open-source a project it is not just done by throwing it on Sourceforge. To make the project attractive to fellow developers, it should have:

• A public SVN, git or equivalent repository which you use yourself as extensively as possible
• A website or small wiki (or some pages on your website) with all the necessary documentation to download and built and whatever the code
• Good documentation (preferably doxygen which you can then throw on the website) of the code, and
• If you really want to motivate others to work on your code maybe you have to clean-up the project and its design as well
• A listing at typical websites like freshmeat.net (if a Unix project) which you update with every release; and if possible: communication with relevant communities, like posting about your project in other project's mailing lists.
• Even while not working on the specific project, being very responsive on any querys about it

I did this with two projects of mine. After some months, they were included into major distributions. After another time, I found a french guy writing a whole gui for one of the projects. Several developers were interested in the other, but eventually nobody really sent a patch.

If you just do it half-assed -- throw it on Sourceforge and then upload a new version every second year -- I don't see how it would help. The more you invest in it, the more attractive your projects are to others, the more revenue in developer help you will earn in the long run.

The answer to your case may be to think about which projects are really/most worth these efforts and then continue with them.

Answer 3

Keep the number of projects at two or three, and open-source them. Keep hacking code yourself and spend some time guiding the few projects. Open-source doesn't mean you could now have tens of projects and completely rely on your peer programmers.

Answer 4

Projects are alive because there are people looking after them. Open Source is not the solution per default, just look at the large number of dead or otherwise orphaned products on SourceForge.

If you open source, your next step is to build a user base that will look after the product. Once this user base is built, you can step away from it.

Answer 5

Use them - or find someone who does.

They will survive only when there is demand for features and fixes, people desperately working around bugs, or figuring "this would solve my problem if only..." Without demand, noone will feel compelled to dig through your code, yourself included.

If the users are there and you have a hard time meeting their demands, open source is a viable solution.

However, submitting a project to SourceForge and slapping a "GPL" sticker on it will not create demand. You could at least improve visibility: set up a web site, add some verbal description, make sure google indexes it, submit it to "free software" sites.

If it's programming tools, try to work them into an ongoing project of yours.
If it's applications, figure out what problem they solve, then who else got this problem, then why aren't they using it.

Or - even if it sounds harsh - Let them rest in peace.

Answer 6

Focus on just one project at a time (two at most). Prioritize your projects based on their usefulness for others and for yourself. Focus on the project that is (1) the most useful and has the most users (for example if it does something that no other program does), or the one that (2) gives you the most intellectual challenge. If the project is both, then it's even better.

Those in the first category might be able to live as open source, if you keep the project active long enough for it to gather a large user base. Then some other developers might also take interest in the project and join it (for the Subversion project, it took many months before the first developer joined it from the outside - mentioned in this video around 32min). A project with only one developer may die at any time, but if there are multiple motivated developers, then the project has better chances of living. The important thing is to get something working released. If nobody can use the program, then it won't gather a user base.

Those in the latter category are primarily just for you to learn something yourself, but which might not be that valuable to others. If you lose interest in them, just bury the code in a corner of your hard drive and move on. Even if you release it as open source, nobody will continue developing it. If you like, just zip it in a package and put it on your web site where you show things that you have done, but do not expect anybody to download and use it, let alone continue developing it.

The book and videos at http://producingoss.com/ are a good source of finding out how to make an open source project successful.

Answer 7

For the projects that you deem unworthy of your time, you can still change their name prior to releasing as OSS and let your user base know. It will be clear it is something else and you won't be involved, but it might just be what a couple of programmers were waiting for to keep your work going.