Community Articles: Opinions, Interviews, Analyses
13 July 2001The OpenOffice.org Infrastructure Upgrade, Part II
OpenOffice.org will be migrating from its current platform, Tigris Classic, to SourceCast, an updated version of Tigris. In a previous article, I discussed some of the more obvious advantages the new platform offers the community. I'd like here to go over two other important features community members will be able to take advantage of: logging in and project and user groups.
Log In
Tigris Classic places a harmless cookie in a user's browser. This cookie generates a session id that is valid only for that session. Users are not identified, sessions are: Privacy is respected. SourceCast follows in a similar vein, in that it respects user privacy, as does Sun Microsystems (which sponsors OpenOffice.org) and CollabNet (which hosts OpenOffice.org). Only, because it has been designed to support project joining and thus log-ins, SourceCast uses a different technology: log-ins. Casual visitors who visit OpenOffice.org on SourceCast will be logged in as "guest" and given a randomly generated password good for that session. For casual visitors, that's it, and no other information will be asked for. In short, there will be no experiential difference between OpenOffice.org on SourceCast and OpenOffice.org on Tigris Classic, at least for the casual visitor.
But for those who want to join projects (and propose them), and who want to contribute patches, etc., to OpenOffice.org? For these individuals, there is a difference. By registering and logging in, the contributor can join projects, can propose projects, and can work on the issues that concern a project. The reason for this? To encourage members to join projects and to provide project leads (named project owners in SourceCast) with some means by which to manage the work that must be done. And, as I mentioned last week, this and other features are optional. One need not join a project to participate in OpenOffice.org.
Okay, but what is entailed in registration? That is, what sort of information is garnered? And what about privacy? Briefly, SourceCast gathers a username, password, and e-mail address. The advantages? In this way, for instance, registered users, who have joined projects and agreed to work on issues, can file and be assigned issues and contacted for work on those issues by IssueZilla, our bug and issue tracker. This represents a change: currently, anyone can file an issue; but people seldom seem to, and instead resort to sending email. With SourceCast, only registered users will be able to file issues (and be assigned issues). As a result of this change, the hope is that registered users will feel more involved in the community and consider OpenOffice.org a community for which the contributor is partly responsible. Gone will be the situation in which you can file an issue without the sense that someone else can assign you one, too. In this way, we move further away from a retail model, in which there are customers or clients who might complain about issues and there is an 'us' and 'them,' and closer to a true, Open Source model, in which everyone is involved.
Registration enables project leads to invite registered users to their projects. The registered user can of course decline the offer, of course, as there the choice remains, naturally, with the developer. And, no doubt, some developers will be more popular for some than others: the meritocracy won't disappear. Actually, SourceCast will allow the development of a more nuanced meritocracy. For it articulates a sophisticated ensemble of roles and permissions that registered users can be granted. Tigris Classic has really only two categories: someone can either write or they can't, to the CVS tree. In SourceCast, a registered user can be a "content developer," an "observer" or any other role that the project lead feels addresses what must be done.
Indeed, by registering, we are making it much easier for a worthy project to succeed, for the project owner will be able to invite talented contributors with a spectrum of talents with minimal fuss.
Groups: Projects and Users
SourceCast allows for the grouping of registered users and projects. Projects can be grouped together according to any reasonable criteria, such as technology. What is more, any one project can belong to more than one group. And users can be involved in several user groups. Thus, for instance, the Porting project might become affiliated with a GUI project, and with the XML project.
In effect, a project group can be considered a sort of inclusive project, with much of what that implies, minus the presence of a project lead. The grouping feature is more than an administrative boon. It also makes it easier for users to keep apprised of what is going on in those projects with which she is involved, and simplifies the process by which a user's roles and permissions can be managed.
There are, to be sure, other features which I have not fully discussed. Such as searchable mail archives (finally); or the possibility of per-project news. As the migration process continues, I will be posting more tips on SourceCast.
