As mentioned in the introduction entry, every one-man hobby open source project has three main parts – development, maintenance and promotion. Today, i’m going to talk about where it all starts, and, if you’re not careful enough, where it all ends.

It all starts, of course, with the development. You take an idea and you put it to a virtual life. This is perhaps, the most enjoyable part of a new project, at least for some of us. This is the time where everything seems possible, where there are no implementation complexities, no bugs to fix and no annoying support requests for esoteric environments. Even if you are doing this on your free time, it doesn’t take a lot of commitment to just sit down in front of your favourite editor and start banging away. It is also, unfortunately, a time where a very sizeable percent of the projects simply die.

It takes a serious commitment to continue developing a new project on your own free time, at the expense of your other hobbies and sometimes even a family. This is not only being enthusiastic about your idea. It is about being passionate. If you’re not passionate about the idea in particular, and about its field in general, you might as well not start at all.

There are three main aspects of the development. These are most certainly not specific to one-man projects. However, due to the very nature of such projects (when that one man leaves, the project is no more), not planning the development cycles in advance can have very adverse impact on the project’s ability to survive in the wild ocean of today’s open-source.

The majority of successful open-source projects (no matter how big the development community is) have a very clear set of tenets. This is sometimes referred to as project goals, vision, direction or guidelines. While the tenets do not need to be set in stone, it is crucially important that a project has a clear, concise and simple definition of what it aims to do. A clear project vision helps immensely in deciding what goes in and what stays out. It helps the users to understand whether the project fits their needs, and it makes sure that the project does not end up being a jack of all trades, and master of none.

It is certainly not my intent to create a bad impression on this specific project, and i’ll let you judge its vision on your own:

[…] is a high performance, vastly scalable, embeddable, internet-centric client/server computing platform with a breakthrough adaptive runtime technology.

Speaking only for myself, this is full of buzzwords and marketing speak. Too much information is crammed in here, with too many generic overused words. I had a hard time remembering it a few days after seeing it on the net. Now, compare it to these very focused and plainly-worded tenets of FormLayout project:

It is a very simple and down-to-earth list. It is also very memorable. The entire library is driven by these four statements which set the clear rules for what goes in and what stays out. It doesn’t claim to want to be the best for everybody, and it doesn’t proclaim to provide a solution for all possible scenarios. Instead, it focuses the APIs around a simple and coherent vision, and even explains why some things (that the author considers bad) are hard to achieve.

I will talk about the features in the next entry, but for now i’d like to skip to the third facet of the development – the release schedule. Here is a real example of one of the projects hosted on SourceForge, illustrating the “anti-pattern” or release schedule planning:

On the face of it, everything looks good. There have been eleven releases over the last six years, and the project looks quite active and maintained. However, there are two big sore points with this table – the leading zero in version numbers and the ever increasing time span between consecutive releases.

In this particular case, even the project’s developer does not consider it to be worthy of “1.0” release label. One might say that it is a minor thing which has nothing to do with the actual quality of the project. However, the outside looks count and not only in real life, unfortunately. As cliche as it might be, dress for success is a very good advice, and in virtual world this means stripping the alpha / beta / 0.* status from your project. You have very short time window to impress the potential users, and a solid release number with no greek letters is a must-have. This is the least you can do after six years of development.

The second sore point of this specific project is the ever-growing time frame for each release. It took 2-3 months for the first six (when the initial level of commitment was quite high), which then dropped to 4-6 months for the next two releases, and 11-14 (and counting) for the last two. The potential users that seriously consider investing in your project (using, sending bug reports or even contributing bug fixes) might be rightfully scared by such a trend.

To each his own, but i found that the following release schedule works best for me:

Here, i have three minor releases in between each pair of major releases. I give ten weeks for .1 and .2 release (more on the inner structure of each release later), twelve weeks for .3 release and twenty weeks for the major .0 release. The extra two weeks in the .3 release cycle are spent on code health which will be the main topic of the next entry. The extra ten weeks in the major .0 release cycle are spent on code health, removing all dead code and deprecated functionality (even if it means breaking binary compatibility and existing clients) and allowing the early adopters some time to test the changes and adapt their applications.

There are quite a few advantages of having a regular and predictable release cycle. As long as you commit to the planned release cycle, it allows your users (existing and potential) to align their plans and schedules and make sure that they are not going to slip their schedule because of you. It also gives a very important outward sense of stability and predictability about your project. In addition, it puts a quite welcome (if not necessarily obvious) pressure on making sure that you continue actively looking for the new ways to improve your project.

I’d like to elaborate a little on the last point. When you only have ten weeks for a minor release, you need to be constantly aware that the release must be “justified”. Allowing yourself to postpone your work on the project just because it’s summer, or just because you met this great new girl, or just because there’s some pressure at work is a luxury that a one-man project simply cannot afford. The more you postpone, the more it becomes a norm, and the end result is seen in the previous slide (going from 2-3 months to 11-14 months in between releases). Waiting for a “perfect moment” to work on all those great new features once you get enough free time does not work. The more time you spend away from the project, the harder it becomes to get reacquainted with it when you get back. When you think in terms of “next weekend” instead of “tonight”, it becomes very easy to postpone it to yet another weekend and the one after that, especially if you’re waiting for a chunk of 10-12 straight hours that you want to dedicate to it.

“Justifying” the release means that you need to show compelling reasons to take a new version. It includes bug fixes, performance improvements, reduced memory consumption and new features. When you only have ten weeks to work on a release, it becomes a cycle that feeds itself (just like getting into the habit of postponing the development is a cycle that feeds itself). Developer’s work is never done. We’re constantly striving to expand our knowledge and grow professionally, and this means that the code we wrote yesterday will ever be questioned tomorrow. The project may be “good enough” to some, but the really successful projects are never good enough in the eyes of their developers.

This release cycle has a nice side effect – it adds up to 52 weeks in between the major releases. This means that your project will have a major release once a year, further strengthening the outward appearance of both stability and progress.

The next entries will continue talking about the specific project tasks.

• Part 3 talks about the maintenance
• Part 4 talks about the promotion
• Part 5 summarizes the discussion

The image is available under Creative Commons Attribution NonCommercial license from the following flickr.com stream:

• Leeping dog by i am brad