Michael Meeks hacks on OpenOffice.org (and other code) for Novell. While very few people question Sun’s generosity in purchasing Star Office and subsequently opening the code, there have been persistent questions regarding the community management of the project. Michael’s work log for 02 October 2007 highlights what appears to be lopsided behavior from Sun. In particular:
If OpenOffice was blessed (like other more sensibly structured projects) with a large, diverse and healthy developer-base, then perhaps we could expect to go around rejecting big chunks of code, offending developers and driving away potential contributors. To do this solely in order for Sun to retain total ownership of the code-base (and even loosely coupled components) - seems rather a betrayal of it’s self-appointed stewardship role wrt. OO.o code ownership (under the JCA).
Ultimately, it seems to me the current setup is not a winning, open approach, but a dangerous situation that hobbles OpenOffice.org, and leaves us in a bind.
This fits with a lot of semi-public criticisms I’ve heard of the project management over the past few years: onerous change request processes, an insular development process, and tight control from some managers at Sun. It’s not all Sun’s fault, though–someone reminded me that the StarOffice team is a tight-knit group of developers who’ve all been working in the same building on the same code for a decade, so a distributed, community-driven development process is a big change.
OO.o development has not exactly progressed with rapidity. While loosening the grip of the main contributor over the project is no guarantee that the project will attract more developers, the opinion I’ve heard from contributors from almost everywhere but Sun is that it’s an experiment well-worth trying, lest OO.o manage itself into irrelevance.
Update: Michael has comments on the related Slashdot story (Sun Refuses LGPL for OpenOffice; Novell forks), mostly refuting a very misleading headline. Also, GNOME co-founder Federico Mena-Quintero argues that the OO.o governance model appears designed to discourage outside contributions, with examples from Ximian and Evolution as well as Mozilla.
hear hear!
I've had the displeasure of filing a OO.o bug report and watched it get subsumed into a more general set of feature requests which have been active for the past 3 years without serious attention (the request concerned data import/export in calc).
With OO.o being so big and cumbersome, here's what I'd love to see happen:
1. OO.o gets broken down into components, including a minimalist core component (kernel?), with distinct individuals/entities in control of each component (and someone to assume overall oversight to maintain consistency across the total product).
2. Debian styled stable and experimental builds with the stable build on a two year cycle and the experimental build updating much more frequently with lots of experimentation permitted and less rigid adherence to process, specs, QA etc (of course, these should be obstacles to making it into the stable build)
OO.o is hobbled with backward compatibility libraries that don't even build with newer gcc versions. I agree with dm that it would be much easier to build a faster developed OOo core and optionally use as many system components as possible so as to keep the code base in good shape and buildable on modern Linux distributions. This would also make it a lot easier to port the suite to alternative architectures.
While I agree with some of Michael Meeks' points I have found the combination of OpenSUSE and Novell's versions of OO.o buggier than that of Slackware and Sun OO.o. I also couldn't get the Novell Edition of OO.o for Windows installed on the newest WINE so as to be able to read OOXML files.
Simon Phipps in response
http://blogs.sun.com/webmink/entry/sca_r_office
Michael Meeks in response: http://www.gnome.org/~michael/activity.html#2007-10-04