Slashdot Mirror
The Uncertain Future of OpenOffice.org
eldavojohn writes "What's the biggest threat to the success of OpenOffice.org? Is it Microsoft Office? Is it the simple fact that Dell doesn't offer it with computers? Not according to some participants in the 'open' source project itself, they say the biggest problem with OO.o is the fact that Sun codes, owns & makes all key decisions for the project when it should be more community oriented. A professor who participates in the project itself said 'enough developers are frustrated by both the technical and the organizational infrastructure at OpenOffice.org' and cites this as 'a real problem that is weighing on the project.' Other members of the community agree like Michael Meeks who asked 'At what fraction of the community will Sun reconsider its demand for ownership of the entirety of OpenOffice.org?' Hopefully with IBM's entrance into OO.o participation we will see the product become more community controlled & accessible. Has anyone else experienced this when developing for OO.o or another 'open' source project? Is it a good idea to criticize a company when they've put so much effort into a project that is technically open source and completely free? Is Sun trying to control OO.o like Java? Do they have good reasons or evil underlying intentions?"
As near as I can tell, OOO has two major problems. Once upon a time, StarOffice actually had it's own mini-desktop from which the major pieces of the app like Writer and documents could be started from. This desktop even had its own widget set called VCL. Sun wisely did away with the goofy Desktop UI but OOO's UI is still implemented in this widget set. Whenever OOO is ported to a new environment, the major sticking point is that a binding layer has to be created from VCL to a widget set in the environment. Being a C++ widget set with more or less conventional semantics, VCL mapped well to GTK2 and Windows so Linux and Windows are easy ports in that regard. It is a very poor impedance match to Cocoa on Objective C and still appears to be hosing a truly native Mac port to this day. The NeoOffice guys use Cocoa through Java which makes a thin shim programming wise but a pig memory and resource wise as they have to have Java active and resident in memory for their VCL -> Cocoa mapper.
The other problem is that OOO isn't well divided up internally. It was designed to load as a huge glop o' code back in the StarOffice days and still does. I once argued about this until I was blue in the face with a OOO developer on NewsForge. I could not get it through his head that I wasn't talking about splitting off Writer, Calc and so-forth into separate apps. I understood that OOO's "apps" are developed from an internal common set of objects (which also means an equivalent to MS' COM system is also loaded with the main app). I was talking about being smarter about which objects to load initially and then loading others on demand. This would get the startup time and usual memory usage down. It would also make it easier to use OOO as an API the way Office is used as an API.