The Joy and Pains of Releasing Open Source Software

Analysis
Oct 21, 20103 mins

How many balls can you juggle? Being in charge of a FOSS project will test you.

For those of you who have never had the pleasure of releasing an open source software product I thought I would let you in on a secret – IT IS VERY PAINFUL. In fact, it is the only time that I dream of how great it is to work on a proprietary software product with product managers running detailed schedules and Engineering managers working directly with those schedules to meet objectives and dates. They don’t know how easy they have it…

Here are some issues that are faced by open source communities when releasing software:

  • Roadmaps- where do roadmaps come from and who decides what gets in; after all, community members participate for many reasons that are not all unified behind the single goal of a new release so features that are added may or may not reflect what is needed on an official roadmap. You just get what you get as developers choose what they want to work on.
  • Release Dates – it is difficult to set an exact release date as features and fixes are added daily by developers and may or may not be thoroughly tested as people who test open source builds also have their own reasons for testing and will focus on features that interest them; thus, it is a challenge to state that on a specific date we will freeze development.
  • Development Freeze – A major issue that arises with every release is the “can you just wait a bit longer for my feature” hold up – once the community becomes settled on a date there is a last minute rush of new features and changes that come pouring in; thereby, making the freeze even harder to declare. After all, if you leave someone’s feature out, they may not be so excited about doing development in the future.
  • Release Package Testing – Once the community has finally agreed on a date, what features are in and out, we have the final hurdle of testing the release and making the fixes to bugs found. Many communities will run a series of release candidates which are tested for bugs and once a large enough set of bugs are fixed, another release candidate is created and made available for testing. This process works well for an open source community but takes longer to achieve a final release as its always harder to get developers to fix a bug rather than create something new.

Whew, we did it. We released a new version of the software and released to a community of users who will immediately discover lots of problems missed during the release candidate cycle thereby forcing developers to once again do bug fixes on a released package OR start working on new features for the next release. The cycle never ends and the endless goal of finding developers who love to fix bugs instead of creating new features continues. Oh, and I forgot to mention documentation…