Commentary

Serdar Yegulalp
 

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.


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

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 OpenOffice.org 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.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links