Monday, June 24, 2024 Where From Here?

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

There’s been little question, for a long time now, that the free-and-open-source office suite (or OO.o) has been stagnating. It’s a grand and daring project that’s been choking on its own inertia for too long.

The good news is that some fresh blood may finally be entering its veins, in the form of the Document Foundation creating their own branch of OO.o: LibreOffice. What’s less clear is whether or not they will simply repeat the mistakes of the past.

I myself in these pages penned a farewell letter to OO.o in favor of Microsoft Office 2010, mostly out of practicality. I haven’t summarily decided that I’ll never use OO.o again—I’m always willing to give future iterations of the program a chance—but I see now that a great deal of work needs to be done with it, both as a program and as a project.

I say these things not out of contempt for OO.o, but because I want to see it improved—and real improvement is often painful and difficult.

So here’s my take on what needs to be done with OO.o to make it competitive.

Make it easier to contribute—and make it open core

More than anything else I’ve heard, the biggest complaint about OO.o as an open source project is how difficult it’s been historically to get contributions accepted from outside Sun.

Most of the work done on OO.o was internal to the company, and a big reason for that was the politics of the submissions system. Back in 2008 Michael Meeks of Novell recommended that to prevent further stagnation, Sun needed to “kill the ossified, paralysed and gerrymandered political system in OO.o.” The company need to “put the developers (all of them), and those actively contributing into the driving seat.”

The process of getting code included, he wrote, was “horribly demotivating and dysfunctional”. So much so, from my perspective, that developers were resorting to the most extreme solution possible—forking the entire code base (e.g., Go-OO, and now LibreOffice) and adding their own improvements there, rather than deal with Sun at all.

It’s all too clear that the management of the project has been one of its own worst enemies. How Oracle or the Document Foundation choose to deal with this is entirely up to them, but I’m with a number of others—including Meeks—who suggested that the project should be spun off into its own, self-sustaining foundation a la Mozilla.

There’s another question that comes up, which I find more pressing than the question of governance. Is it even possible to take a project of the scope and dimensions of OO.o, and make it a competitive product while also keeping it entirely open source?

This is where I break ranks and suggest something many people are not going to like: OO.o should, for the sake of its own future as a project and a product, adopt an open core strategy. Give away the basic version of the product, and sell closed-source, differently-licensed add-ons that people are willing to pay for.

If that turns out to be a direct and efficient way to fund development of the project and bring more open source development into its fold from the outside, then I for one wouldn’t flinch from that.

If my roster of added functionality bits—e.g., a robust, context-sensitive grammar and spelling checker—came to $40 a piece, I could buy four such add-ons and still be coming in at less than the cost of Microsoft Office in its current incarnation. And all that money would be going right back into OO.o development. (Perhaps older versions of the add-ons in question could be released under a more permissive license, with the for-pay versions being the newest and most valuable.)

Right now, Oracle is indeed selling their own commercial edition of OO.o as Oracle Open Office, but their approach is different from what I had in mind. Most of what Oracle is selling consists of a) support and indemnification, b) bundling of add-ons normally downloaded separately, and c) migration tools for those leaving Microsoft Office behind.

Those are all good things, and I can see them being worth paying for. Indemnification and support, in particular, are probably impossible to provide without paying for. But separating these components out even further and selling them piecemeal allows OO.o to get valuable information about the most important thing: what the users really want.

I know there are a lot of people who find an open core strategy unpalatable. But I think it’s a better compromise than anything else I’ve seen—and one more likely to produce truly useful software that will bring more people to OO.o — users and developers alike — in the long run.

Make it a product, not just a project

In the same spirit, OO.o needs to be thought of as a product and not just a project if it’s ever going to make any serious inroads against entrenched competition.

Firefox and Google Chrome, two other remarkably successful open source projects, are successful as products as well as projects. Part of it, I think, comes from a certain degree of separation of one from the other.

In Chrome’s case, the project version (the Chromium project) is kept discrete from the product version (Google Chrome itself). Firefox’s project is Gecko; the product is Firefox itself.

But over and above that, there’s a good deal of attention in both products towards what the user experiences and why. The people responsible for the development of those programs may not charge money for the use of their products, but there is still a currency involved: the user’s investment of time and effort, which is always more precious than money.

That’s where the “product” end of things comes in. With a product, people feel they are using something that has been polished and thought through, not simply created in direct outwards imitation of something else.

There’s been a fair degree of attention paid in OO.o to workflow and productivity, and it’s paid off. But it’s been almost entirely reactive. It’s keyed more to responding to what Microsoft Office is doing lately (e.g., creating their own implementation of an Office 2007-style tabbed interface) than any kind of innovative, independent research in workloads or application interaction.

If OO.o is to truly compete, then its developers need to be as daring about it as any for-pay competitor of Microsoft’s.

The document, the application, or the work?

OO.o needs to be more than just a way to work with documents authored to the ODF standard.

This may sound like an odd stipulation, but one common reason people rally around OO.o is its implementation of, and support for, the ODF standard. The Document Foundation wants to use OO.o as a major flagship for promoting ODF, especially in sectors where openness is crucial—medicine, government, not-for-profits.

The ODF standard is a laudable concept, and I rather like the idea of not being tied to any one particular application if I can help it. The documents we create are always more valuable than the apps we use them in.

But I’d argue that it’s the work accomplished with that document—independent of file format or application—that’s even more crucial. And I’d also argue that the applications that are the most polished, definitive and focused help people get that work done best—and that, sadly, many open source programs don’t behave like that yet because they’re not really built to satisfy those demands.

Case in point: The Excel jockeys I know refuse to use if they can help it, because of its laggardly support for Excel’s macros, with which they accomplish any amount of custom-tuned number-crunching. Blaming them for adopting a proprietary product accomplishes nothing.

Or consider the endless and tiresome debates about replacing Photoshop with The GIMP, which always revolve around the end user being re-educated and not about the program being made appreciably better.

If OO.o supports all of ODF’s features perfectly, but is still a frustrating application to deal with on a day-to-day basis, it won’t amount to much of a victory.

A real guiding hand

What most needs, more than anything else, is a string guiding hand that will not be afraid of moving it forward—that will make it a truly useful alternative instead of just a no-cost substitute, and which is capable of seeing open source as a sensible development strategy rather than an unreachable ideal.

OO.o has been a political pawn of one kind or another, as opposed to a useful piece of software, for far too long. Back when the Oracle acquisition of Sun was brand-new, Larry Ellison proposed moving away from C++ for OO.o’s development and using JavaFX (a conveniently proprietary item in Oracle’s technology portfolio).

I can’t find anyone apart from Ellison who thought this was a great idea—not least of all because Java development itself has been stagnant for years now, but because anyone who has written a program of any size knows how brutally difficult something like that is. If taken seriously, such a measure would have probably killed OO.o for keeps, or at least stalled it once more for years on end. (Let’s not even speculate about that being what Ellison wanted.)

The inheritors of’s throne—whether it’s Oracle, IBM, the Document Foundation or some other party waiting offstage—need to keep all this in mind. The number of people who value the utility of their software far outnumber those who value freedom over other things. If you can’t build a product that makes them happy, you probably won’t be able to make anyone else happy either.

Subscribe to Data Insider

Learn the latest news and best practices about data science, big data analytics, artificial intelligence, data security, and more.

Similar articles

Get the Free Newsletter!

Subscribe to Data Insider for top news, trends & analysis

Latest Articles