Supporting Open-Source Software via Online Community
by Ben Adida
and Philip Greenspun
This documents the SDM ("software development manager") subsystem
extension to the core ArsDigita Community
System necessary to support people who are using, extending, and
fixing bugs in collaboratively developed and maintained software. The
development model supported is central control. Software is divided
into modules. For each module, one person is designated as
owner. The owner has the authority to check in changes and elect
peers, other programmers who also have the authority to check in
changes. Modules that need to work together are referred to as
related and, for each relationship, a record is kept of the
person who is the relationship manager.
Because the core community system and this subsystem are entirely
Web-based, SDM lends itself nicely to open-source software development
by contractually unrelated parties. However, there is nothing that
would keep a company from running SDM internally to support
collaboration among employee developers.
Roles
The following kinds of people use the SDM:
- project leaders
- programmers
- users
The project leaders are supported with up-to-date information on
programmer assignments, bug reports, feature requests, and release
schedules. For the purpose of any given module, programmers are divided
into two classes: module owners and contributors. The SDM can keep a
module owner up to date on all the unfixed bugs, unimplemented features,
and proposed modifications and extensions from contributors. Users are
supported by the SDM in that they can be alerted via email when their
bug report or feature request has been addressed in a new release. The
SDM provides a standard repository for new releases and patches.
Two-Phase Development of the SDM
The Software Development Manager subsystem will be constructed in two
phases. In the first phase, we will keep information about modules of
software, e.g., "bug 37 was fixed in release 4.2". In the second phase,
we will intimately involve the SDM in keeping track of the actual code,
e.g., the SDM itself will automatically do a build every night from the
CVS tree and send email notifications of problems to appropriate
programmers.
We expect to complete development of Phase 1 by March 15, 1999. We can
meet this schedule because most of the software is already present in
the ArsDigita Community System. We expect to complete development of
Phase 2 by August 15, 1999. We can meet this schedule because most of
the required software is available from mozilla.org and other
open-source development communities.
Data Model
Here are the core tables of the SDM:
modules: each row represents a collection of
related source code; columns include module name, owner, current
version, description, etc.
module_relationships: each row records which
modules interact significantly and who owns the interface between them
module_releases: each row represents a named
version of a module, e.g., "3.7"; columns include
release_date (null until done),
anticipated_release_date,
release_name, (just text; SDM doesn't care if 3.7 comes after 4.0)
manager (person responsible for this particular release;
typically the module owner)
module_log: a linear log of dated information
about progress on a given modulebugs_and_features: each row is one report from a
user of a bug or a requested new feature; columns include who has been
assigned to it, what priority it has been assigned, when it is expected
to be fixed/added, whether it has in fact been fixed/added and, if so,
in which release
bug_release_map: there will be a row if a bug is
present in a particular release a module (covers the case where a bug is
discovered in version 1.4 and we need the SDM to inform users that it is
also present in 1.2 and 1.3).tasks: something to be done by a participant in
SDM, typically a programmer. Testing is an example of an appropriate
entry for the tasks table.
user_interest_map: records the fact that a user
of the SDM is interested in monitoring the progress of a bug, feature,
or task.
Elements of Collaboration
The real power of the SDM is that it enables participants in the
development process to collaborate in a structured fashion. For
example, rather than simply using the ArsDigita Community System's
standard discussion forum software, we tag threads to particular
modules, particular bugs, or particular tasks. Because bugs and task
may be tied to module releases, a manager can say "show me all the
discussions about bugs that are due to be fixed in Release 3.8".
Here are the core elements of collaboration:
- module
- module version
- bug/feature
- task
- programmer
- reporting user
- reporting user group
Structured statements may be made by users that include these
elements. For example, a project leader can use a Web form to tell the
system that Programmer X is assigned to Task Y. This enable subsequent
reporting along any of these element axes. For example, someone could
ask "Show me the average time that it took to fix a bug reported by
someone in User Group Z."
Background
For more information on the benefits of open-source software
development, see
ben@mit.edu
and
philg@mit.edu