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 
15 Comments
thanks for this. this is a beautiful vision and i really hope it comes to pass. right now, as a long-time user of OOo, I’ve passed the stage of frustration and moved on to hopelessness — I really hope that will change some day…
Is it really best to try to make OOo way of doing things the standard? Wouldn’t it be more productive to replace OOo’s “home grown” systems with the systems the “outside FLOSS world” have already set as the standards?
Hi Thorsten,
Great post to read after the breakfast! I agree that OOo should be much more modular to be used in other application or frameworks.
IMHO, the exemple of Eclipse is a good one: everything is plugin over a small core. This kind of concepts would be greatly appreciated by developers which could even build applications on top of OOo.
Thanks for your clear comments, and your extremely relevant vision of OpenOffice.org, I share for most of it.
@AndersH: well, that was not my point. In fact, the projects I mentioned (glib, cairo, fontconfig) are IMO at least on par with what OOo has internally (and likely will be ahead in the future) – we should therefore save us the effort maintaining our own version. But: there’s still tons of very valuable stuff inside the code base, that other people/projects could greatly benefit from – and we should make that easily accessible to others.
Hi Thorsten,
though I’m very disappointed that you took a two line quote of a long discussion on our dev-list and used it out of context. So let me correct the fundamental error I see in your blog.
Obviously you don’t make a difference between “description of status quo” and “vision” here. The quote you took from my mail describes the status quo, not a “vision”, not even a plan of what we will do in the future.
Of course we also have visions, but talk is cheap and it doesn’t help people asking for concrete actions to answer with visions. That exactly happened in said discussion that you quoted so selectively. If someone asks me to get something, I don’t tell him that I have the “vision” to give that in an unclear future. In such case I explain why it isn’t there, what we think how it could be changed and what obstacles we face. That’s what happened in the discussion that you misquoted.
OK, now about visions. I can say that I agree with you in many of your points, not in all of them. As I promised already on the dev list a few days ago, I’m going to present my “visions” for the project soon. I would be glad to discuss them with you as well as with others in a constructive way.
In concrete terms and to give an outlook, I would welcome efforts in the direction of modularization, re-usage of code inside and outside of the project.
In said discussion I supported the idea of better modularization several times and I did the same in my talk at last year’s OOo conference.
So either you willingly “ignored” that or you didn’t understand it.
At this moment I see that meanwhile you have replied on the dev-list. I’m glad that we can continue our discussion there.
AndersH, thorsten: we use fontconfig already on the X11 platforms (well, on the subset that actually has a fontconfig library). However most of these FLOSS “standards” mean exactly nothing on Windows or Mac. Which are platforms I wouldn’t want to drop in favor of “FLOSS standards”; running only on (SuSE š ) Linux is just not good enough. We need our own abstraction layer to work platform independently. There is of course nothing keeping us from making the Unix implementations use glib or fontconfig – which we incidentally already have.
@Mathias: I think we both agree that your quote accurately describes the past (and to a large extend the status quo). I introduced your quote, saying that it set me off for this rant, and that’s what it did. I fail to see any misrepresentation here, and am happy that you share most of my points – because I really believe this is to a large extend a question of mind-set.
Philipp, isn’t Thorsten’s point that if OOo has such a good cross-platform toolkit, then let’s get it out there (aggressively, even) so that everyone else trying to do cross-platform development can make use of the same tools. I’m not a programmer, but listening in to programmers in several different contexts, cross-platform development seems to be in constant need of better and improving tools. What a gift OOo could make to that wider community!
Qt? Gtk+? What are OOo’s advantages over competing architectures?
One significant advantage of building OOo on a more generally used toolkit (beyond easing maintenance) would be to make the code much more inviting to outside devs. The custom stuff remains fairly obscure relative to other toolkit/platform offerings.
@Josh: well, the significant advantage is that 80% of OOo code is built against this toolkit – that notwithstanding, you’re right. š
But that was not my point.
So it’s essentially a short-term vs. long-term tradeoff, right? In the short run, a switchover to another toolkit/platform would require significant investment of developer resources. If a switch was not done, then, in the long run, significant investment will have to continue to be made in maintaining the current toolkit. If you let the long run be long enough (using economics speak) then these will eventually even out to be the same amount of effort required either way. The switchover requires more resources up-front, but also most likely leaves the code in a more useful, easily-maintainable state thereafter.
Of course, since I’m not an OOo developer (nor do I intend to be) I certainly can’t dictate which way to go. But, if a more “standard” toolkit/platform was being used, then I think I’d much more likely become an OOo dev sometime in the future. FWIW
Josh, yep, this generally captures it. But there’s work underway, since several years, to at least loosen the coupling between OOo’s current toolkit & higher-level UI code. The goal is to have most of the code abstracted away from concrete implementation, and then be able to plug (almost) arbitrary toolkits beneath (note that using neither Gtk nor Qt is considered a smart idea on Windows or Mac).
This slowly drifts away from the actual posting, though, but might be worth a separate write-up…
Thanks for your replies. I’m glad to hear that thought is being given to gradual decoupling. Best wishes.
Why not to attack Mozilla project. They have the same. They have done all the same way. Firefox has also abstraction layer over toolkit.
Exactlly the same is for component model. They have also XUL which is not used anywhere else.
What would be great it would be to have abstract API for clossplatform C/C++ application like Firefox and OpenOffice. It should abstract canvas, font, layout, toolkit, component model, scripting, networking.
But it should be Apache2 licensed, not GPL like QT or LGPL like GTK (which will kill it in Mozilla and often in commercial applications)