Release Plans

With open source projects, there is an adage of "Release early, release often". These words can really help an open source project get off of the ground and run smoothly. It allows users of the code to provide feedback and see progress. It also means bug fixes are quick to make their way out the door, so a user doesn't have to shelf a project because they are waiting on the fix. Finally, it helps the hype machine - if I'm making announcements often about my library's releases, it means more chances for those who would be interested to stumble upon it.

My time grows increasingly finite as my duties as a web developer and father increase, but I actively maintain three projects with more on the way. Seeing how much favoring process over code helps my productivity at the workplace makes me quick to apply the concept towards this problem. I need a process that allows me to direct small amounts of time to the project that are hyper-productive, and will force a release out even if the amount of work I have accomplished is less than profound.

My plan is to commit to about five hours of side-project work a week. A small amount of weekend time plus half an hour here and there spread across the week should keep that manageable. Each week will have some goal in mind, even if it is minor. Bug fixes must come first, and there should be sufficient test coverage. Next, I plan on alternating my project every week. At the end of the week, I will do a release. If I'm planning on having somewhere between 4-6 projects going, this means I have a release coming every month to a month and a half - often, but not spammy. This process isn't unlike what we use to great effect at Integrum, so I can't count myself as creative.

As of this writing I'm already in the middle of a week, but the best time to start is always now.