Releasing Software
“Release early, release often.” How often is enough and does it count if you just commit?
I’ve always been interested in development processes and how they impact the software being created. I have worked in shops with a range of formal processes, and after some experimentation with different methodologies, I find myself most comfortable somewhere in the middle of the spectrum. I like to have enough controls in place to understand how forward progress is made and prevent regressions, but also want a certain degree of flexibility to bend the rules when the situation calls for it. While no software is ever complete, I want the ability to put a stake in the ground and say “This version is done”, for some definition of “done”.
In early June, Christian Joergensen wrote on his blog about his frustrations with the lack of official releases from Django. Until recently, the Django team has had a policy of releasing by committing to the trunk in their subversion repository, but going no further until they were ready for the 1.0 release. Producing intermediate releases was deemed to take time and effort that could otherwise be applied to development of new features, refactoring, API polishing, and all of the other work that was on the “must have” list for 1.0. As a result, the active Django user community has grown used to “tracking trunk”, to the point that the This Week in Django podcast has an entire segment dedicated to reporting trunk changes.
In his post, Joergensen made several points about the difficulties of keeping up with security patches and managing configurations on multiple servers for different projects. The ensuing discussion in the comments, and later on the django-dev mailing list, were interesting; he seems to have struck a nerve. The reactions ranged from heated rejections of the idea to whole-hearted agreement that a release was long over due. The entire conversation was a little surprising to me, because I’ve never really considered not releasing software as part of a development cycle, even for my personal open source projects. SVN repository access has always been a bonus on top of formal releases.
Because I’m a Django user but find myself without the time (or inclination) to “track trunk”, I was glad to see that the Django team used the discussion resulting from Joergensen’s post as the impetus to ramp up their efforts to wrap up the 1.0 release. As I write, the major branches have been merged into trunk and an alpha release is available, with a beta due to be posted soon. The final 1.0 release candidate should be online by the time you read this. Reaching 1.0 is a big step for any project, and especially one of this size. Congratulations, Django developers!
The conversation led me to think about the fact that in the commercial software world producing releases is an unquestioned activity. What makes commercial and free apps different in this respect? Is it that users don’t have access to the source code? That’s not always the case, depending on the way the commercial application was built. Some “enterprise” applications are big (and complicated) enough that having access to the source is not, by itself, sufficient to let you replicate their functionality. In these cases, at least part of the source is distributed so that services teams can modify it when integrating it with other systems.
Some might point out that companies wouldn’t be paid if there was no release. That’s not always true, either. Over time, companies tend to make more from support contracts than from selling the initial licenses to the application. Professional services for installation and customization can also be big source of revenue. In quite a few cases, the services revenue is enough to support the development of open source software that is freely licensed. See Zope Corp., Sugar CRM, and Collabnet for a few examples of companies that have organized creative business models around open source software.
Perhaps it is a fundamental difference in the definition of what is being created. Many organizations don’t even consider software a product until there is documentation and training materials to go with it. Preparing an official release is an important convergence point for the different parts of the project team. The QA, documentation, and professional services groups all have deliverables of their own to be added to the software. The act of preparing the release forces everyone involved to tie up loose ends from incomplete features (or at least tuck them under).
Overall, I come down on the side of formal releases. The steps of packaging a set of files to create a release tells the end user that the results are “official”, in some sense. New and casual users of a project, who don’t have time to follow every commit log message or keep up with the developer mailing list to understand when it is safe to pull a version out of the source repository, need that affirmation when they are trying to figure out how to install the application. I’ve also encountered plenty of production shops where software could only be installed through the OS native package management system, making packaged releases a requirement.
There are plenty of questions left open about how frequently to prepare releases, and how to define them. We have to balance features with schedule. Lacking economic incentive to create regular releases to keep maintenance contract fees coming in, open source packages tend to place more emphasis on features, letting the date slip as needed. That’s as it should be. On the other hand, corporate customers like regularly scheduled releases because they make planning easier. With hundreds, or thousands, of systems to keep consistent, they can’t update them piecemeal or have patches coming faster than they can test and apply them. Even if the software runs on only a few infrastructure systems, a certain level of stability in the day-to-day operation of the company is necessary. Life is chaotic enough without having to worry whether the email server is going to be online every day.
Instead of “release early, release often”, should we be saying “release early, release regularly”? Let me know what you think in the comments.