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.

Originally published in Python Magazine Volume 2 Issue 9 , September, 2008