The Free and Open Productivity Suite
Released: Apache OpenOffice 4.1.14
Editor's Column: 16 January 2001

Editor's Column

-Louis Suarez-Potts

16 January 2001

Quo Vadis

Where is headed? It is, of course, far too early to consider seriously answering that question. As I write this, is barely three months old; the community that has formed around the project is still, in fact, coming to terms with the enormity of the task. And although the next version of Sun's StarOffice, StarOffice 6, which will employ a good portion of the technology created by, is scheduled to be released later this year, that release will hardly spell the end of the project. It goes without saying that the nature of an open-source project is precisely that it is never done. There is always something that can be improved.

This incessant perfectionism does not mean that there must be no roadmap for open-source projects, however. It is to say, though, that the great strength--and perhaps also a small weakness--of open-source projects lies precisely in their anarchic creativity, which roadmaps try to contain and channel. But here lies the difficulty, for a roadmap that is too confining risks destroying the very thing that open source models engender. is often compared to, and the comparisons are just. Both projects are enormous, and both aspire to run across platforms and in a way that allows users greater reliability and flexibility than current programs. For this reason, it is worthwhile glancing at's recent roadmap.

To begin with,'s roadmap serves primarily as a list of stages and milestones that should be met. Underlying's or any open-source's roadmap is the emphasis placed on the community's role in determining the actual product. This is not merely a marketing ploy to entice community members. The community quite clearly controls much of the direction of the project and obviously determines its actual success. But not entirely; the governing body--however it is defined and constituted--sets the goals and limits the activity.

In's roadmap, for instance, the community's imagination is almost bound to the more tedious chore of making the program perform stably and correctly. But even here, the binding terms are laced with implicit apologies to the plausibly frustrated contributors, and Brendan Eich, the author of the roadmap, goes out of his way to "make clear here that useful and relevant (defined by the community) extensions are always welcome, provided" that is, that they don't interfere with the charted goals.

Much younger than, is still very much in the period of creative growth. Ideas and suggestions are very much welcome, from anyone in the community; wishlists can become reality. But all this depends on the nature of the dialectic established by the community (however defined: it may include users, too) and the governing body.

This issue is far larger than any one article can encompass. In the coming weeks, I will be revisiting it. In my column for next week, I will begin an examination of the structure of another enormous open-source project, Apple's Darwin.


Previous columns

3 January 2001 Sun's open door

9 January 2001 The 613 build:  problems and opportunities


E-mail: louis at*

*By spelling out the mail address, I'm hoping to defeat spam crawlers.

Apache Software Foundation

Copyright & License | Privacy | Contact Us | Donate | Thanks

Apache, OpenOffice, and the seagull logo are registered trademarks of The Apache Software Foundation. The Apache feather logo is a trademark of The Apache Software Foundation. Other names appearing on the site may be trademarks of their respective owners.