Grayson, Westley, Stanislaus County, Western San Joaquin Valley, California. Seventh and eighth grad . . ., 05/09/1940

I'm always impressed by the enthusiasm of OpenOffice users to try out the next great release.  A frequent question is, "When will it be released?"  I see this question on Facebook and Twitter, the Forums and mailing lists.    "When will version of OpenOffice be ready?"    I'd like to answer the question fully here, so we can refer users to this answer in the future.

It is tempting to give the response, "It will be released when it is ready".  But that sounds a bit snarky, although it is accurate.   But the truth is software engineering schedule estimation is notoriously difficult and predicting a specific date is a sure way of looking foolish later on.

There is a well-known diagram in the software industry of a triangle, with the sides labeled: "good", "cheap", "fast" and with the title, "Pick any Two".  This expresses the ever-present trade-off between quality, cost and schedule. 

In commercial software development arbitrary dates can (sometimes) be met, by dropping quality (or features) or by adding resources to tasks (increasing costs).  To some extent open source projects can also try to hit arbitrary dates by dropping quality.  But unlike commercial endeavors open source projects don't have the same ability to add resources to recover a schedule slip.  On the Apache OpenOffice project we are mainly volunteers, dedicating free time to the project, and that time varies according to school and holiday schedules and other personal needs.  So we cannot stick to a schedule in the same way that a commercial software publisher can.

OpenOffice is a mature product and users expect it to just work.  They are not looking for surprises.  Users want to spend time doing their task, their
work, their business.  OpenOffice is a tool, a means to an end, and
having a stable, familiar tool that gets the job done is golden. There
is little pleasure in getting a new hammer and screwdriver every month, with
new bugs, except for the small minority of technologists who relish the challenge and risk of frequent updates.  The rest of us have real work to do and don't want to worry about whether the feature that worked last week still works today.

So generally, we've been aiming for two high-quality release of Apache OpenOffice per year, with a cycle that looks approximately like this:

  • Brainstorm and discuss possible features.  Even before version N is released we're discussing what will be included in version N+1.  This includes specific new features, enhancements, new languages, bug fixes, etc.  Much of this is tracked in our Bugzilla issue tracker (for bugs and enhancements) and on our mailing lists and wikis (for major features).  The contents of the release are determined by the volunteers who do the work, based on their interests and motivations.  These are discussed, documented on the wiki and become the goal for the next release. 
  • Development of the new features occurs, the coding often occurring in "branches" which are segregated areas in our Subversion version control system which help the developers to not step on each other's toes when stabilizing their code.
  • As features are completed they are "merged into the trunk".  We regularly build install sets from the trunk, so project participants can try the new features as soon as they are ready and give feedback.
  • Once all the feature work is done for a release, we translate and test.
  • We iterate on testing and fixing bugs until we've eliminated all "release blocking" bugs and have something of sufficient quality to call a Release Candidate.  We then vote on the Release Candidate, and if approved it becomes the new release.

So rather than asking about dates, the smart question is to ask, "Where in the release cycle are you now?".  In the case of Apache OpenOffice 4.0, we're on that last step, finishing the translation and test work.  How long that step will last will depend on how many bugs are found, how many of them are release blockers, and how long it takes to fix them.  These are things that are not easy to predict.  Again, it comes down to the old saying: good, cheap, fast -- pick any two.

We welcome help from new volunteers in all parts of the Apache OpenOffice project.  If you want to learn more please have a look at our Get Involved page.