The following statement from one of the OpenOffice.org project leads set me off this morning:
It’s clear that the re-usability of OOo code in other projects isn’t in our focus. I hope it’s understandable that our main interest is the success of OOo as an end user application. It may be even a bit short-sighted, I don’t know. But that’s as it is.
When I look at the OOo universe, it’s reminiscent of a ghetto – we live in our own world, with everything different from the rest of the FLOSS town: own build system (even with the luxury of our own make utility), own operating system abstraction (sal, osl, rtl, vcl), own configuration system, own string classes (oh, actually, two of them), own component model (UNO), etc. ad infinitum. There were good reasons to implement those back in the day, with OOo being one of the very few truly cross-platform applications.
But the world has changed, and instead of OOo promoting their libs to the rest of the FLOSS world, investing some amount of time & effort in separating e.g. UNO out of OOo and making it easily usable for others (saying that URE is such an independent package is a joke), that outside FLOSS world set the standards for those portable core libs (glib, cairo, fontconfig, dbus, etc.) – because they did succeed in encouraging other people to use their code. It’s not that other projects will come and invest time to mine for reusable code – developers don’t work that way, they require a decent amount of readiness, comfort, and conformance with de-facto standards (and active lobbying, sometimes), before they use it. With this myopic focus on the shipped product (disregarding the value that lies in OOo’s core libs), we missed quite some chance to firmly embed OOo core technology at the heart of other FLOSS projects (that would, I conjecture, have created win-win situations, in sharing the load of maintenance, and also dragging devs into other parts of OOo – and the project has failed miserably to attract developers outside a very limited set of corporate contributors. When compared to e.g. the Linux kernel).
It’s high time then, to challenge this limited vision of OOo as only an end-user application. In fact, the source tree is a gold-mine of excellent technology, that we can be proud of, and that really deserves to be used outside of the core OOo project. And to actually walk my talk, I’ve just put out an independent copy of the basegfx graphic core library to gitorious.org, that should build & run on anything that has the usual ./configure; make; make install working.
That’s because, if we fail at that – if we don’t get more developers (directly, or indirectly by contributing to spin-off libs) working on the code, what will become of OOo in, say, five or ten years from now (cue vastly different UI concepts here, large software packages running on mobile phones etc.)? Think about what’s the true value of OOo – those parts that set it apart from other, similar text processing/spreadsheet/presentation packages. Is it the dialogs, the toolkit, interactions or the packaging? Or rather the filters, ODF, the application cores, UNO? Personally, I’d love to see those jewels survive the test of time, and the challenge web-based & mobile computing poses.
And no, I don’t believe just taking OOo as-is, and putting it onto a server in headless mode, makes the project appealing to anybody – it’s a stop-gap solution, and as soon as light-weight, stable, threadable alternatives appear, people will flock over to them. Instead, my vision of OOo is more that of a document processing toolkit, with webkit possibly the role model of the kind of “engine” I have in mind – portable, easily pluggable, widely used (both hardware- and software-wise).
Thorsten's Weblog 