The Apache Software FoundationBlogging in Action.

Apache OpenOffice

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 <insert next 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.

It's good to see this being discussed, but I feel you're rather missing the point by assuming we users are interested only major versions. It's been a year since 3.4.1, and it still has plenty of bugs. We don't need major new features, but it would be nice to know when the next minor revision is coming out to fix the irritations. At this point I assume we're just getting 4.0 next, whenever that may be.

@Andrew, the process is the same for minor releases as it is for major releases. Ditto for essential trade-off of quality, schedule and resources. The only difference in minor releases is their scope. They are smaller and focused on fixes rather than new features.

I, for one, am glad for the slow releases and that the OpenOffice developers take their time.
I've tried LibreOffice, and while it does have a few fun features, it seems to have added them at the cost of stability. For example, one persistent bug in LibreOffice is that I cannot edit large files for long without it crashing. OpenOffice, on the other hand, is solid as a rock with anything I throw at it.
So please, take your time. A polished, stable product is worth it! Thank you all so much for giving us such a product!

I hope it will more support or fully support with normal MS office document (not docx, xlsx, or pptx). The major bug of 3.4.1 is when I save it as xls file it broke the file format and can't open anymore :(
So...today, I switch to LibreOffice for a while and hope to see OO be better or equal LiberOffice.
I love OO because UI and icon are look professional than Libre and work smoothly.
(Sorry for my bad English lang)