The Document Foundation blog has announced the release of LibreOffice 3.4 Beta 5 and at the same time has signalled a change to its communication strategy and explained its time based release model.
Up until now news of the latest beta release of LibreOffice has been circulated via its "announce" mailing list and in future only announcements of final and stable versions will be sent using this list.
News of beta releases will in future be announced on its "projects", "development" and "localisation" mailing lists - that is the lists to which the developers and volunteers involved in extending, testing and patching the project subscribe.
The blog also explained that the way in which LibreOffice relies on collaborative development effort, and a time based release model (such as other collaborative development projects like GNOME and KDE) is rather different from the past with OpenOffice.org, where most of the development was happening inside a closed group and releases often didn't keep to the release schedule.
The LibreOffice aim is to be able to involve "anyone with some time and a PC" in building new release using free tools stating:
This is rather different from the past at OOo, where release builds came from a proprietary build environment run by a small team of build engineers.
Many open source projects can count on the fact that the consumers of the products coincide to a large extent with their developer community and have a fairly high level of technical competence. However in the case of LibreOffice a large proportion of the end users are not involved in the ongoing development of the project - and the fact that in the past they have been made aware of the latest beta release which is still under active testing and development has been problematic.
So in order to make sure that users select the correct release of the LibreOffice for each situtation the blog proposes a simple scheme summarised in a diagram:
Spelling this out the blog states:
- For the most conservative users, we recommend a commercially supported version, which enables you to indirectly support the project’s development. Such stable versions will typically be based on a point release, such as LibreOffice 3.3.2 today.
- For those interested in the bleeding edge, who want to enjoy new features and fixes, we recommend LibreOffice 3.4.0, release candidates, betas or even nightly builds, which enable a participation in the development, evaluation and quality control process
In other words, "innocent" end users should stick to versions that have three numbers making the emergence of the "point releases" into significant milestones, and anybody downloading a beta release should expect it to contain bugs and be willing to actively engage in finding and fixing them. Early adopters who download the 3.4 release when it becomes available shoud understand that the software is still in its testing phase.
This may sound a complicated sort of system to use in the release cycle of a product but it recognizes the difference between open source and fully commercial software. With open source you can upgrade at any time - but should you? Commercial software has a revenue imperative that demands that as many users upgrade when a new version with tempting advantages is released. Open source can afford to be more relaxed about the upgrade cycle. LibreOffice seems to have a sensible approach - let's see how it works.
If you would like to be informed about new articles on I Programmer you can either follow us on Twitter or Facebook or you can subscribe to our weekly newsletter.