| |
| |
| <!--#include virtual="/doctype.html" --> |
| <html> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> |
| |
| <link href="/css/ooo.css" rel="stylesheet" type="text/css"> |
| |
| <meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8"> |
| |
| |
| <script src="https://www.apachecon.com/event-images/snippet.js"></script> |
| </head> |
| <body> |
| <!--#include virtual="/brand.html" --> |
| <div id="topbara"> |
| <!--#include virtual="/topnav.html" --> |
| <div id="breadcrumbsa"><a href="/">home</a> » <a href="/editorial/">editorial</a></div> |
| </div> |
| <div id="clear"></div> |
| |
| |
| <div id="content"> |
| |
| |
| |
| <h2> Community |
| Articles: Opinions, Interviews, Analyses</h2> |
| <p><a href="//lspintro.html" target="_blank">-Louis Suárez-Potts</a></p> |
| <p>2 July 2001</p> |
| <p> </p> |
| <h4>The OpenOffice.org Infrastructure Upgrade</h4> |
| |
| <p>The OpenOffice.org infrastructure is going to be upgraded. In less than two |
| weeks' time, on the afternoon of July 13, 2001, OpenOffice.org will move from |
| its current infrastructure (<a href="http://www.tigris.org" target="_blank">Tigris</a> |
| Classic), to a more modern and sophisticated version, <a href="http://www.sourcecast.org/products/sourcecast/" target="_blank">SourceCast</a>. |
| During this period of transition, the site, including the <a href="http://www.cvshome.org/" target="_blank">CVS</a> |
| repository, will be down for what may end up being several hours. And when it's |
| back up, it will be decidedly improved.</p> |
| |
| <p>What does the upgrade bring? To begin with, SourceCast gives the community |
| the tools by which they can more directly participate in building OpenOffice.org |
| and its member projects. Second, it simplifies the task of managing mailing |
| lists and projects. </p> |
| |
| <p>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 <i>content,</i> or the OpenOffice.org 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. </p> |
| |
| <p>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.</p> |
| |
| <br> |
| <h4>Joining projects</h4> |
| <p>Join a project? With our present model, that phrase almost makes no sense. |
| One can certainly <i>subscribe</i> 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? </p> |
| |
| <p>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. </p> |
| |
| <p>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. </p> |
| |
| <p>SourceCast <i>does not</i>, 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.</p> |
| <br> |
| <h4>Proposing projects</h4> |
| |
| <p>Currently, any regular visitor of the OpenOffice.org site can propose a new |
| project. Most regular visitors to OpenOffice.org probably don't know this, but, |
| it's so. It's also one of the better features not only of OpenOffice.org 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. </p> |
| |
| <p>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. </p> |
| <br> |
| <h4>Conclusion</h4> |
| |
| <p>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.</p> |
| <p>Next week, I will further focus on what is entailed by joining a project.</p> |
| <br><br><a href="./editors.html">Previous Articles |
| </a> |
| |
| |
| </div> |
| <!--#include virtual="/footer.html" --> |
| </body> |
| </html> |