The Structure, Organisation, Scheduling and Control of Open Source Projects
Open Source projects are often very large, in terms of their
codebase, participation, significance and maturity. I am
interested in how these projects organise themselves to
provide a stable, reliable, high quality product in a context
where the customary control measures utilised within a
commercial organisation are completely absent.
From a commercial standpoint, OS projects ought to be an
anarchic mess and many IT professionals reject OS due to this
prejudice. It is common to find a 'no Open Source' rule stated
and applied within commercial organisations, to the extent
that proposals are rejected out of hand if they
incorporate OS components. In my experience this is due to two
factors - a perceived inability to apply Change Control
measures to OS software, and a perceived lack of support for
OS software.
The opposite position is taken by OS advocates - the
only context in which successful, high-quality software
can be created on a large scale is in an OS project. In a
commercial context there are several factors pushing projects
towards low-quality work including time-pressure and a lack of
appreciation of the value of investment in automating
processes. It is still near-universal in commercial
organisations to "confuse effort with progress" (Brooks, 1976)
and to refuse to support the implementation of tools. Instead,
hands-on management is advocated. Of course we know that this
leads directly to resentment, "them-and-us", no sense of
ownership by the development community and ultimately wild
costs, low quality and failure.
In an OS context we have no
possibility of imposing management structures or of demanding
that time is spent "digging" instead of planning - and yet
these projects are models of productive, high-quality
efficiency, with near-zero costs and extremely tight version
control and testing. I believe there is a middle-ground where
adoption of appropriate OS tools and methodologies can enable
commercial organisations to free themselves from the endless
"cat-herding" and last-minute quality crises, to provide
easily-accesible, automated management tools which bridge the
divide between development, project management and customers.
The merits of OS in principle have been argued by many people
over recent years with varying degrees of success. Some in the
IT community point to "The Cathedral and the Bazaar" as a
key document in this debate, but my own opinion is that it is
largely irrelevant. Of much greater significance is the
organisation and productisation of individual OS projects.
This is Project Management, but not as we know it - it is Open
Source Project Management (OSPM).
Such is the success of projects such as Mozilla and Eclipse at
presenting a corporate image, that many assume that they are
in fact traditional organisations. However, with the exception
of some of the biggest projects (eg Mozilla has an
office), there is no project office you can go and visit ,
there are no paid staff on these projects, and there are no
support contracts between the producers of the software and
the users of the software. The question is - what is there
then?
The stalwarts of OS are
the GNU
Foundation, and Richard
Stallman in particular. For 20 years Stallman has developed
the ideas and practice of Free Software, which he has defined
very precisely as distinct from the general Open Source
category of software. This comes down to
arguments
over licencing and the implications on users of the
software. Whilst of vital importance, this is not the focus
of this article. This article is about how things get done.
It will be argued that the licencing of a project
fundamentally affects the organisation and participation in
the project, and I accept that. However, here I am
concentrating on the mechanics of OSPM.
I will examine a series of successful OS projects and document
their Project Management practices. Through this there will
emerge common themes and strong differences across projects
which will enable me to categorise those projects and
hopefully to draw conclusions about the requirements and
implications of adopting any one OSPM technique.
Mailing Lists
Pretty much all communication within OS projects is through
subscription mailing lists. These have been around for almost as long
as email itself - they are so simple in concept. The standard
mailing list management programs are themselves OS projects,
the classic one being Majordomo.
Here is a review
of 4 commercial but free to use mailing list services .
Several mailing lists typically exist for any one OS project,
each focussed on a different aspect of the project. Typically
this is developers, users, new users, and announcements.
The lasting value of these lists is in searchable archives -
the high profile Linux Kernel Mailing List (LKML) even has a
dedicated summary web
site through which provides weekly news pages for the
major LKML topics.
Types of OS projects
The nature of an OS project can be largely determined by it's
scope. As I research this subject, it is clear that it is of
fundamental importance to understand the Type of project under
discussion. In the absence of a categorisation scheme, I will
use the following. Note that the terms "association",
"aggregate" and "composite" are here used as in UML - this is
well
described on JGuru.
- Atomic Project
- An Atomic Project is one with a single product. An example
is the Linux Kernel.
Another is the Vim project.
- Aggregate Project
- An Aggregate Project is an association of seperate projects
with a common theme, but with no necessary technical coupling.
An example is the Apache Project.
- Composite Project
- A Composite Project is an association of seperate projects
with a common technical coupling. An example is
the Eclipse
Project. Another is
the KDE Project.
- Meta Project or Political Project
- This is a project enabling project - Meta Project - which
does not itself produce anything of a functional nature.
Initial Projects
These are the projects I will initially examine. They are
different in their intent, audience and age. Some are enormous
and so I will no doubt experience varying degrees of success
in characterising each project.
Also of interest: marketing, funding/sponsorship.
Commercial Companies Supporting Open Source projects
The motives of these commercial companies are varied, and I
will try to glean as much as I can. For the moment, this is
just a list.
Marketing
Commercial tools used by OS projects.
- JIRA - used by
codehaus, "JIRA is a J2EE-based, issue tracking and project
management application developed to make this process easier
for your team." Maven uses this as an issue tracker, and the
Apache home site is less dynamic.
- Linux Kernel uses BitKeeper
20050531: Linux Kernel has changed to Git, a
system under development by Linux Torvalds himself! I'm
searching for some definitive stuff on this major event,
and for the moment there's
this
kernel traffic report. I'll add more as I find them...
OK, I found one:
git(7) Manual Page
- ... and it's
controversial!
Check this out (by Larry McVoy):
"The only reason I end up railing against RMS is he is really
trying to hijack the Linux effort for his own purposes... The
amount of source code that the Free Software Foundation has
funded is almost zero. The amount of source code that RMS
himself has written is also very small. He did write the first
version of GCC and did a lot of work on that, but by far the
vast majority of the code in GCC was done by Cygnus as
contracting work to make other chips go. I am personal friends
with all three founders of Cygnus, so I know what I am talking
about."
Here is
an article just about the time BK was adopted.
Git Development
As described in various articles and mailing list digests,
BitKeeper is no longer available to the Linux Kernel project
as a freebie. So, Linus has said that he will go back to
manually processing the patches sent to him by email. Well,
this didn't last long! Linus almost immediately started work
on Git, his "stupid (but extremely fast) directory content
manager" - ie a merge tool.
Since Git is deliberately restricted, others have jumped in
with more able wrappers. In particular we have
Cogito
for human interaction with the Git system. Git Traffic has
the
Cogito 0.8 announcement, which contains a good summary.
Interesting articles
|
|
|
