The Free and Open Productivity Suite
Apache OpenOffice 4.1.5 released

Community Articles: Opinions, Interviews, Analyses

-Louis Suárez-Potts

2 July 2001


The Infrastructure Upgrade

The infrastructure is going to be upgraded. In less than two weeks' time, on the afternoon of July 13, 2001, will move from its current infrastructure (Tigris Classic), to a more modern and sophisticated version, SourceCast. During this period of transition, the site, including the CVS repository, will be down for what may end up being several hours. And when it's back up, it will be decidedly improved.

What does the upgrade bring? To begin with, SourceCast gives the community the tools by which they can more directly participate in building and its member projects. Second, it simplifies the task of managing mailing lists and projects.

But first: The site will look pretty much the same. Changes will mostly be subtle. But many will find additions that will prove very welcome indeed; these need to be highlighted. For instance, SourceCast comes replete with logically laid-out documentation on how to use IssueZilla, CVS, and just about everything else pertaining to the site infrastructure. (As opposed to the site content, or the code.) This means that users (at least those who read the Help) will at last be able to find context-sensitive answers to many questions.

I would like in this article to go over some of the differences in SourceCast and to suggest ways in which community members will be able to grasp this opportunity to--perhaps!--accelerate the development of the project. For, as has become clear in the last several weeks, the community has reached point where members are forming projects to satisfy longstanding needs. This discussion will be the first of at least two; it will focus on joining and proposing projects. Subsequent announcements will deal with other aspects of the upgrade.

Joining projects

Join a project? With our present model, that phrase almost makes no sense. One can certainly subscribe to a project's mailing list, and, to be sure, a select few can even become committers to a project's CVS tree. But join?

Yes, join. SourceCast formalizes a process that in our current model of Tigris is by no means self-evident. Thus, the group that is working on, say, the Documentation Project in the Whiteboard, may work together, and well, but there is no clear and efficient mechanism for them to distribute work among themselves; or if there is, it is home-grown and not necessarily extensible to other projects. This situation holds true for other, larger projects, such as Porting, where the problem is magnified by the extent and complexity of the work.

So instead of a system that relies upon the unformalized understanding of a project's contributors and mailing-list subscribers, SourceCast allows for a clarification of responsibility. Members can be more coherently thought of as "members," with clearly understood responsibilities (determined by the leader and group). Again, this system has more or less worked fine so far. But, as I've noted before, we are growing, and fast.

SourceCast does not, by any means, require that community members (loosely defined) join a project, in order to work on that project. The status quo can continue, and we need not change our way of operating. But let's say that a project lead, supported by that project's contributors, does take advantage of the SourceCast functionality, and chooses to use the joining feature. Members will not only possess a better understanding of their responsibilities and of the tasks they have agreed to undertake, but they will also be able, if the project lead is willing, to have a more pronounced role in determining a project. I'll go over these points in greater depth later, but, in a nutshell, the point of explicit membership is not just to provide a mechanism for the allocation of work but to grant to members the incentive of clearly established responsibility.

Proposing projects

Currently, any regular visitor of the site can propose a new project. Most regular visitors to probably don't know this, but, it's so. It's also one of the better features not only of but of any Open Source project: If you want something done, you can join or create a project to get that thing done. SourceCast takes this characteristic of an Open Source project and foregrounds it, making it a simple exercise for members to propose new projects. The (hoped-for) result: More things are accomplished by more community members working together.

Implicitly, the emphasis for now is on "proposing projects." And why just propose and not actually create? Because it would be foolish to allow for the empty proliferation of unneeded and unheeded projects that might end up proving more distracting than useful. So, every new proposal will have to be approved before it is accepted. As it happens, this is the way we've been working so far. That said, I fully expect that the simplicity of the new model will eventually lead to some modifications in the process by which proposed projects are approved.


To say that SourceCast has many other features that the community will benefit from is to understate the case. For instance, as I will describe in subsequent articles, with SourceCast we can organize and group projects and members in ways that counteract the fragmentation any large Open Source project is subject to.

Next week, I will further focus on what is entailed by joining a project.

Previous Articles

Apache Software Foundation

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

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