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…
Community-building
OpenOffice might be "open source", but is it truly Free software? There are issues, like the use of (non-free) Java. It's not fully GPL'd. That's the reason for a lack of developers. Want to get more people excited about OpenOffice? Here's some practical advice: make it fully free.
Stop worrying about Linux. No single project is critical to it's success. It's doing fine and will continue to improve, slowly but surely -- what's the hurry? -- with or without OpenOffice.
Contributing
I got into OpenOffice.org while I was looking for a job last year. Now I have a job, I have less time, but I have still managed to post a couple of bugs and a suggestion for an improvemnt in the Window installation process. I like to think that any small contribution like this can help. If many others join in, in the same way, like you suggest, it will push OpenOffice.org's success forward.
What's the hurry?
The hurry is the same reson its desirable to do at all. There are always going to be disagreements about degrees of freedom. What matters is improvement. Is it better tomorrow than to-day? And by how much? Hence fast progress is inherently better than slow progress. ODF is the real jewel in the crown because an agreed open standard for documents means a whole range of document manipulation software is possible. OOo is currently the strongest vehicle for ODF and its needed for ODF to flourish. With ODF established, if you don't think OOo is free enough you can use KDE or whatever you like without having to worry about people saying they can't read your files. So OOo is strategically important for anyone who wants to see a Linux desktop with a significant enough presence to start providing real choice. I am a committee member of the UK AFFS so I believe in free software. I fi I have to put up with some Java for a while to get more people using free software globally, so be it.
ODF and KOffice
ODF is *critical* to interoperability. KDE and KOffice are adding support for ODF to the next versions. Unfortunately M$ will not add support to Word.
Community-building
This is really starting to sound more and more like FUD. OpenOffice.org is free/open source software, licensed under the LGPL. As far as free/open source Java platforms go GCJ compiles it well enough for Fedora, Ubuntu, etc. What more do you need for it to be "fully free"?
OpenOffice.org, Java, and the Web
OpenOffice.org is indeed one of the most important F/OSS projects with regards to the future of Linux and Open Source movement. However, traditional desktop software is not the future of computing. The very concepts of word processing documents, spreadsheets, and self-contained databases (Access/Base) are terribly dated in today's web-connected world. I see OpenOffice.org and the OpenDocument formats primarily as a transition tools towards open platforms rather than as an end in themselves. While I hope that OpenOffice.org gets the resources it desperately needs, I believe that it is even more important to begin developing the next generation of web-based document production systems that will someday obsolete both MS Office and OpenOffice.org. Think of the lessons we have learned from web content management systems and then apply these to the future software that will replace "office suites" as rich-web applications. Imagine: forget trying to integrate "office suites" with your enterprise software. Web-based document production systems can become an integrated whole with enterprise software!
As per the subject line, how does Java play into this? Simple: Unlike C/C++, Java is re-usable on the web. Any component of OpenOffice.org that is developed using Java can be re-used in Java or Mono/.NET web applications. I would go as far to say that all new OpenOffice.org development should be in Java and that old code that needs re-written should be re-written in Java wherever feasible.
Those who are worried that Java isn't "free" enough should direct their attention and resources to the Apache Harmony project, which working on a fully Open Source J2SE 1.5 runtime and class
library. GCJ is a workable compromise for now.
Does Sun want linux to succeed?
I would question whether Sun even wants linux to succeed. I bet they do want StarOffice to succeed. I would think that because of that, they want the development of OpenOffice to go smoothly. I wonder about their intentions around linux, however. They recently opened up Solaris 10 to get the mindshare of developers out there and have been competing with Red Hat.
It just makes me wonder really. If something is critical to the success of linux, something they don't necessarily have an interest in at best and something they want to fail at worst (especially with the suspicious Microsoft deal), then why would they go out of their way to make the development cycle fit with Linux's priorities?
Does Sun want linux to succeed?
What you seem to forget is that Sun actually has its own Gnome-based desktop-Linux distribution called "JDS on Linux". This includes OpenOffice and was chosen recently by Indonesia as a national-standard desktop, so it is not just a fad. You also seem to forget that Sun's latest Opteron-powered x64 servers are all Linux-certified.
Sun is a company, and companies are in this for the money, not because they love open source. What else are you expecting Sun to do for open source (because they really did a lot already), and what would they have to gain out of it? Don't you think that maybe, just maybe, Sun needs some proof that open sourcing actually benefits them, before doing something we all want, like open sourcing Java? What better proof could they expect other than having people help them by contributing to the development of projects like OpenOffice?
Now, returning to your Linux question, why would Sun want Linux to succeed, when they already have a viable recently open sourced operating system like OpenSolaris? The answer is pretty simple, I think: because Microsoft's world domination hurts them tremendously. Maybe they cannot fight Microsoft in the open any more without the risk of getting totally crushed, because now they are small, compared to what they were several years ago at least. But they will surely try to support any alternative to Microsoft's products, Linux included. That is why they bought StarOffice in the first place, isn't it?
Slashdotted
Not much discussions going on in here so far. You might want to check this slashdot thread: http://linux.slashdot.org/article.pl?sid=05/09/18/1951209
KOffice
There's still a lot of effort going into KOffice, you know. The 1.4.2 release is coming out soon, with improvements to the vector app and to the pixel app, and 1.5 is scheduled for end of January 2006. That will include for the first time true cmyk and 16-bit channel support in the pixel app, Krita, and a host of other improvements to Karbon and the other applications. And KOffice supports OpenDocument, too.
Even though the filters for MS documents aren't as good as OpenOffice's documents, many people are quite happy using an office app that gives you the application before OpenOffice gives you its splash screen (to quote the Linux Format review of KOffice 1.4.0).
And you know what? Hacking KOffice is actually fun!
entry point
Maybe the entry point for developers is important too. In Firefox, you first try and develop an extension, which is very simple. Then you might go out and dive into the app-code, which should be easier because you know of xul (the gui-language) and other inner workings before you even enter the real stuff. It's so easy to get into. Further more, javascript is the glue, css defines the looks. The barrier is much lower in that way. Maybe Oo.o should try to be less monolithic or something. Maybe even use Xul for 3.0, it's great (especially when Xul gets to version 2.0). Why invent the wheel again and again?
Open Office Codebase question
Having not "played" with Open Office or the GCC in a number of years, I am admittedly not up to date, but here is my question anyway:
Firefox obviously benefited from a re-write of the Mozilla code base. Is OpenOffice equally accessible to the same type of re-write in terms of bloat elimination, etc.?
The reason I ask is that back in the mid '90s I was involved in a project where we essentially tore apart the MFC and recoded the non- "windows.h" portion of the C++ code, and the resulting executables were something like 1/8th the size of MFC applications, and a couple times faster. (Not co-incidentally subsequent versions of the Visual C++ compiler tools did a much better job of eliminating bloat from their MFC apps...)
So if a single source or single-team rewrite would hammer the code into better conditions for maintainability, portability, and upgradability, perhaps we as a community of developers should get involved in rebuilding OpenOffice from the ground up. What do you think?
OpenOffice.org, Java, and the Web
Well, I highly agree with your first paragraph as OOo is not the end of the development, but the right way to head. I also think, that more and more office work will be done online. At least as soon as we can online catch up with the desktop apps. Or at least provide the right components the people really need. All the previous movements in this direction sucked completely and never got much attention.
What I highly disagree with is the Java paragraph. Sorry, but the way OOo is integrating Java sucks completely. And I say this as a Java user and advocate. The move was useless, cause I can't see much market for OOo Base and secondly it requires OOo to utilize Java in some weird locations - Wizards!!
And will we really get a reuseable framework? Or even components to use on the web? And how do you want to reuse it in Mono? IKVM? Ever tried it? Sorry, I don't see here much possibility for reuse that is capable to attract users and customers. The backend stuff can be used nicely on the server part.
Well, as I lead a team developing a WYSIWYG layout system for print papers, I can tell you, that writing such a thing is not easy in Java and a lot of boulders are thrown at you from Java, too. Such a tool has to be snappy, responsive, fullfeatured and so on and so on.
I personally don't believe, that it is a good idea to develop anything inside OOo in Java. Start thinking about the stuff after OOo. Integrating Java code inside existing C++ apps can be/is PITA. The currently visible results (OOo Base) prove that. And GCJ? OOo is running much slower on Linux using GCJ/GIJ compared to Suns JDK.
Jono: You're Right on the Money...
...and the natural course is to have a Foundation (the formation to be quite possibly influenced by the structure of Mozilla Foundation & Corporation) and restructure the development team according to the 6-month release schedule with more contributors -- both salaried and independent -- and offering bounties, too.
Accordingly, many on the Sun Hamburg Team would nominally move over to the OOFoundation (quite possibly staying in Hamburg) and some would stay at Sun, these to ostensibly work the StarOffice and Solaris builds (but that's Sun's business).
This would both spread the financial pressure to relieve Sun of the entire burden as well as remove the structural impediment of the conflict of interest Sun has in which the requirements of a boxed product drive the resources of an Open Source and Free Software project. I don't think it's presumptuous of me to say that it would be a relief to Sun without penalizing them or preventing them from moving forward with even more efficacy on StarOffice.
The trick is to get industry participation (financial & other resources) from the interested parties to fund The OOFoundation. This would naturally include all parties interested in the success of OpenDocument, Linux and/or increased competition for Microsoft. I am not aware of a swelling interest here, but it is the sine qua non of an OOF. This ignores also the need for something similar for OpenDocument -- the more important phenomenon by several lengths.
I believe a large missing piece for OOo thus far is the utter and complete absence of universities. An OOF would be the right kind of body to interest them to claim a stake in OpenOffice; and additionally we need to seed a grass roots effort that would grow a software distribution network among students at universities and high schools -- a "Software Underground" -- because the university comp sci departments, faculty & administrations move too slowly (and, besides, they are party to illegal software agreements with Microsoft which effectively prohibit competition). OOF would get a lot of coders from universities and schools -- not to mention accelerate the vital Localization efforts which already produce over 70 language versions of OpenOffice with very little dedicated organization.
You're firing, Jono, on all cylinders!