Saving OpenOffice From Itself (And Oracle)

For my last shot at what's going wrong with Oracle and Sun, I've singled out one of Sun's most important projects -- and also one of its most contentious: OpenOffice.

For my last shot at what's going wrong with Oracle and Sun, I've singled out one of Sun's most important projects -- and also one of its most contentious: OpenOffice.

There's been glum word about OpenOffice in the air for some time now, with much of the bad word revolving around its management as a project and its laggy development cycle. So here  are three things that must be done with no matter what, and no matter who ends up being the true custodian of its codebase.

Give OO.o the autonomy it badly needs. This part no one argues with. Sun's stewardship of the project reminds me of a really bright young man who's forced to stay at home by his overbearing mother instead of go out on dates. The project needs the kind of creative freedom -- and creative dignity -- that can only be had by giving the project the right to choose its own destiny and creative partners.

The big question is: will Oracle let such a thing happen? If they don't, the only alternative may be to fork it and let IBM (via the Lotus Symphony project) or Novell (via Go-OO) pick up the pieces. The former brought a great sense of design and integration to the suite; the latter a tenacity to improve the whole in ways that were previously neglected. Maybe the two of them can join forces on this one; they'd both have everything to gain.

Make it easier to contribute. This one's a no-brainer that follows from #1 above. If the barrier to contributing is too high, people aren't going to bother -- and right now contributing code to OO.o is far too insular and has been for some time. This is a point that's been made many times before so I won't dwell on it.

Create a sustainable internal revenue model. If OO.o is going to go indy, it needs to be able to swim on its own and not cling to a corporate life preserver when things get rough. To that end, it has to become a revenue-generating outfit on the order of Mozilla. Corporate sponsors can dry up or change loyalties; OO.o needs to remain independent lest they run the risk of becoming a flavor of the week.

One way to do this would be to charge a modest but suitable sum for pro-level program add-ons. Example: $20 for a professional-level grammar checker -- something OO.o has badly needed, and which I would gladly pay for. The program by itself has only a framework for grammar checking, not an actual module, and the one major add-on for OO.o that does grammar checking falls so far short of the mark it's not funny. Even if the module in question is closed-source (Lernout & Hauspie could be a subcontractor for this), it would still be better than the cobbled-together patchwork of non-solutions we have now.

All of this stuff isn't just meant to keep OO.o from becoming a beached whale of a project. If other projects of this scope and tenor are going to get off the ground -- like, say, a proper FOSS video editing suite, or an honest-to-god Photoshop replacement that professionals can use -- there need to be more examples of how to do this sort of thing right across the board.

Attend a virtual event on how virtualization is driving value from the desktop to the data center. It happens May 20. Find out more and register.

Follow me and the rest of InformationWeek on Twitter.

Editor's Choice
Brian T. Horowitz, Contributing Reporter
Samuel Greengard, Contributing Reporter
Nathan Eddy, Freelance Writer
Brandon Taylor, Digital Editorial Program Manager
Jessica Davis, Senior Editor
Cynthia Harvey, Freelance Journalist, InformationWeek
Sara Peters, Editor-in-Chief, InformationWeek / Network Computing