As a consultant, consistency and trends are essential signifying elements in determining where software, hardware and IT is heading. In some cases this can be predictable, such as Linux, but it can also be a total surprise right out of the blue with success piggybacking onto an application from nowhere, such as with Firefox and Moodle. Either way, it is important that the consultant identifies how the application is becoming used, and importantly for Open Source tools, the long-term vitality of the project. Sure it may be cool now, but will it be around next year?
One of the most critical Open Source desktop applications is OpenOffice.org. Back in the day when I started taking a keen interest in Linux on the desktop, an office suite was always the problem. There were efforts going into KOffice, but about the only mature office suite that anyone could use was Applixware. There was one problem, Applixware sucked. It looked ugly, involved your wallet and felt quite clunky. Another option was StarOffice, an office suite barely known, despite its early roots, and a behemoth of an application which was so bloated it actually included its own desktop. Back then there simply was no Open Source office suite that was mature enough to use, but that was about to change.
As time moved on and StarOffice creator StarDivision were bought by Sun, the announcement was made that OpenOffice.org would become the Open Source licensed version of StarOffice. This was critically important, and as important as Netscape opening up their browser (which later became Firefox). This move ensured that the strength of the GPL could unite a community of contributors to dust off the code, fix it up and make something happen. The potential for an Open Source office suite, a critical component for an Open Source desktop, was here.
Although the theory held and does hold water, the reality of maintaining an office suite is the sheer size of the project. With around 10 millions of lines of code, hundreds of dialog boxes, thousands of words and bags and bags of features, OpenOffice.org is one hell of a project. Aside from the massive codebase, the project includes entire copies of dependent software such as glib and Python. This huge statically linked application was developed in such a way that it would run on anything, a far cry from the Linux world where every application requires a tree of dependencies automatically handled by the distribution packaging system.
Finding the Developers
As work opened on OpenOffice.org, many companies such as Red Hat, Novell and Sun have contributed developers to spit and shine OpenOffice.org and get it into a reasonable state. With 1 RedHat, 80 Sun, and 8 Novell hackers, the number of paid developers greatly outweighs the less than 10 active external coders involved in the project. If you then factor in the need for artists, quality assurance, documentation, translations, system administration and more, the project needs a huge development backbone to keep going.
One of the problem that faces OpenOffice.org is a lack of hands on deck. It has already been well reported that OpenOffice.org 2.0 has been delayed due to a lack of developers. Despite the fact that 100 active developers sounds like a lot, that is approximately 100,000 lines per developer; a burden that few developers are comfortable with handling, and a burden that requires significant resources just to understand the codebase, let alone hack on it. The problem is of course that the code is so large and monolithic and despite prominent efforts to rip away much of the fat, the challenge is still great.
The issue that concerns me is the sheer dependence on OpenOffice.org and the responsibility for the suite to help the push to Open Source. With huge roll outs occurring across the world, and OpenOffice.org’s reputation as a truly core piece of Open Source desktop technology, the software is not just important, but critical. If you then factor in Microsoft’s efforts with their up and coming version of Microsoft Office, the importance for OpenOffice.org to succeed is essential. I would go so far as to say that a feature complete, high performing and integrated OpenOffice.org is key to the success of the Linux desktop. In many ways, the efforts with GNOME and KDE pale in importance to the work on OpenOffice.org. People will not move to the Linux desktop if there are not the applications, and OpenOffice.org is essential. GNOME and KDE offer the icing on the cake for many people making the decision; “Wow, OpenOffice.org looks awesome, and Linux seems really stable, and GNOME/KDE is really simple and powerful. Where do I sign up?”.
This importance is key, and I get concerned when I hear that there is a lack of hands. So, what can we all do? How can we help? How can we make OpenOffice.org into the office suite that is not only capable, but has the strong vitality that I mentioned earlier?
Anyone can contribute
I had a chat with Michael Meeks about how people can help. I have known Michael for a while and those who are familiar with his work will be well aware of his phenomenal hacking abilities. If anyone should wear a cape and live in the hackcave it is Michael. As someone who is heavily involved with OpenOffice.org, he is well aware of the kind of contributions that people can make to OpenOffice.org. So how do you help? “Well, grok bugzilla / your personal collection of tricky MS files, find some scab and pick at it” he says. He continues, “the first thing to do is to download the latest ooo-build, and build it yourself, then go over the My First Hack page. Be sure to pop onto IRC and ask for help.
A hugely important point to stress is that non-coders can help out with OpenOffice.org too. If you don’t have an affinity for code but still want to contribute, head over to the contributions page and read up on the different ways in which you can help. The page gives details about helping with writing, marketing, helping users, graphics/art, translations and quality assurance. A successful application suite is certainly not only about development and each of these other roles is critically important. This can be identified when talking to people about moving to OpenOffice.org - they are often attracted by the range of translations, documentation, support forums and more. It can often be easy to fall into the trap of thinking that a non-coding contribution doesn’t count, but it really does.
Moving to the six-month cycle
The development of an Open Source application is heavily reliant on a solid release process, good bug reporting systems, and essentially, plenty of useful feedback from the userbase. This feedback can not only help fix bugs, but also outline usability imperfections, feature requests and more.
In recent years, a number of projects have moved over to six-month release cycles. With a shortened cycle such as this, the relationship between developers and user feedback is better aligned. Not only do bugs get fixed and released quicker, but the application remains more present in the minds of users with important new features being released regularly. This process is essential in providing more mindshare when competing with a product such as Microsoft Office that has a much longer release schedule.
The problem is that OpenOffice.org has a painfully slow release process. Releasing upward of 16 months, the release process feels slow and sluggish and from a user perspective OpenOffice.org feels like a slow maturing and lethargic application. Michael outlined why a six monthly cycle is so important:
- Currently we do a tonne of bug-fixing at the end of the release cycle - if this is 9 - 18 months after the feature was written it’s far harder to fix the bugs well.
- Features only really get tested when people use them - QA is all very well, but really, people have to use code to find the sticky bugs. Shortening the feedback cycle really helps get things right fast.
- Predictable releases encourage co-operation - currently there is no predictable release cycle, hence the incentives for working with Sun are lowered - working to get a fix into the ‘up-stream’ build whence it may be released after one’s own distro deadline is not attractive.
- Community / Excitement - it’s silly to have almost finished features festering for months in CVS without being released such as native widget integration which was completed over a year ago and is still not released.
With such compelling reasons for a shortened release cycle, and factors that are critical to the future growth of the increasingly important office suite, why is it not happening? Discussion of a shorter release cycle has been rumbling on for quite some time now. Although there is increasing understanding further up-stream, Michael believes it is mostly management who need to understand the importance of a shorter cycle. StarDivision are really unusual by Linux standards and Michael outlines why:
- They ship a boxed product - that has to work on (n) crazy/whacky linux distributions, lots of them quite old with many missing core pieces.
- Their mind-set is based around a new boxed-product every 18 months - if there are more frequent releases, the channel doesn’t like it (although this is interestingly not the case for eg. SUSE)
- Some (internal) changes to team deployment / planning are necessary to get 6 monthly releases to work - not everyone will be working to the same deadline and there is potential for problems/conflict. The changes need to be managed sensibly.
Any kind of structural change in release management is going to be a tough balance for a team, but sometimes the difficult decisions need to be made. With so many developers out there asking for a shorter release cycle, and with the success of projects such as Ubuntu and GNOME who have six-monthly cycles, the direction seems sensible. There is certain to be an argument that this cannot happen with a project the size of OpenOffice.org, but the current situation cannot happen either. Maybe the best solution is to provide a phased shortening of the release process. First, make it an annual release. Create a solid set of milestone deadlines for feature freeze, string freeze etc, and ensure that a release manager drives the community in the right direction to work around the timescale. This way huge changes can be dropped in a decent timescale, but there is also a clear roadmap for system integrators, distributors and users. I am absolutely positive that this will improve OpenOffice.org substantially. If the process scales to a yearly release cycle well, it could then be shortened to eight months or possibly six months.
Make it happen
OpenOffice.org is critically important. With such compelling features, attractive licensing, cross platform support, and such simple installation, OpenOffice.org plays a key role in not only moving businesses to Open Source, but also in propagating the important OpenDocument format. This is already happening in earnest with large government migrations such as Massachusetts. As governments, schools and businesses move over to OpenOffice.org due to not only a better software and license offering but the eventual adoption of OpenDocument, I suspect we will see a steady growth in adoption.
To make this happen, a shorter release cycle and a larger development team are essential. A great comparison to the potential for adoption is Firefox. With the impressive efforts from the SpreadFirefox project and a regularly released high quality project, we have seen huge migrations to the browser. These migrations have not only been secured due to the cross platform nature of Firefox, but also its unique features and its sheer ease of installation and compatibility. OpenOffice.org also incorporates these merits, and OpenOffice.org also came from a wad of code that was Open Sourced. Firefox offers possibly the finest example of how an Open Source application should be maintained, supported and marketed. Indeed, the SpreadOpenOffice.org site has been set up to provide a similar level of marketing push.
To conclude, OpenOffice.org inspires the same potential that has electrified other software blessed by the Open Source methodology. The opportunity for a community of enthusiastic contributors to come together and potentially change the way software is used is there. OpenOffice.org offers so much potential for those who want move away from Microsoft Office. I have dealt with businesses, schools and charities who have saved huge amounts of money by moving to OpenOffice.org and engaged in a more open and manageable office suite to boot. Money originally destined for licenses can be instead pushed into more human, tangible areas such as staff, care, equipment and events.
If you are reading this and feel inspired to contribute, I really encourage you to. Everyone can do something, even if it is just filing a bug report. The smallest contribution can net the greatest outcome when more and more people get involved. As OpenOffice.org moves towards a shorter release cycle and more people get involved, I am positive that OpenOffice.org can compete with anything that Microsoft can throw at it, but the only way it can happen is for the collaborative Open Source process to be successful, and these means that we should all help where we can.
I would love to hear from those of you who have contributed to OpenOffice.org in some way. What did you do? How did you get involved? How is the community and support? Use the comments box below to let readers know how you got involved and what you do/did.
What do you think? What are your experiences with OpenOffice.org and contributions? Scribe them here…