Continuous growth

Figure 1: Number of dependencies of selected metapackages

Once a piece of software is packaged, the effort needed for its future maintenance is relatively small. Nevertheless, care is needed not to exhaust initial maintainers' enthusiasm since continuous maintenance requires investigation of submitted bug reports and following the ``upstream'' development. Also, for many package maintainers, to understand the upstream code, to learn from it, and to contribute back is a part of their motivation - and that often does not scale. In the longer run, continuous growth can only come through attracting additional contributors to the Debian project. Debian welcomes contributions and has set up Sponsored Maintainer and Debian Maintainer programs to lower the entry barrier. Those programs allow anyone to contribute without requiring an official Debian Developer status, obtaining of which requires going through an often lengthy Debian New Maintainer process. Moreover, the Debian policy is not requiring any kind of a Contributor Agreement, thus ownership for any contributed work remains with the authors, which is an important incentive in the true spirit of open source. As a result, anyone interested can easily contribute and acceptance might be only a couple of emails away.

Several Free Software projects which try to deal with small user group software started with a lot of enthusiasm but at some point in time developers had other interests or changed their job. There are just several reasons why people are not able to continue maintenance of a project because of lack of man power.

To make sure the manpower of the team can fully concentrate on the field of work they really want to do the strategy of Debian Med is to stay strictly inside Debian - so even if the team started with a few people they were able to relay on a solid technical basis without extra effort.

Thus Debian Med is not a derived distribution and is a part of the Debian project. Debian Med relies on the core Debian infrastructure (e.g. build farm for a variety of architectures, online repositories and mirrors, bug tracking system) and only complements it with an additional thin layer yet again functioning within Debian infrastructure. That guarantees that the overall development system remains robust and does not require extra effort from the Debian Med sub-community. Moreover, adherence to common principles and organisation helps Debian Med project members to improve efficiency and share overall maintenance cost because many actions can be performed on the entire pool of maintained packages at once. Admittedly, quite frequently software products maintained by Debian Med are of generic utility, such as Java or Python libraries, and thus of interest to the Debian audience outside of the target scope of Debian Med- Medicine, as a result benefiting Debian as a whole.

Figure: Activity of most active authors on the Debian Med mailing list

The success of the Debian Blends approach finds evidence in e.g. a continuous growth of the number of packages inside Debian that are of interest for health care. Taking the number of dependencies of some metapackages into account (see figure 1), only a small set of packages useful for medical care was available at the beginning of the Debian Med project in 2002. A nearly linear growth with a gradient that perfectly reflects the availability of programs in this field can be observed.

Besides the growth of the output of a project it is useful to characterise the commitment of people involved in the project. It is important to ensure that fresh blood is coming into the project to compensate for the normal loss of supporters, which always happens in Free Software projects (people find new jobs with different orientations or have less spare time for private reasons etc.). A raw measure for the activity of members might be their mails to the project mailing list. Figure 2 shows the number of mails from the ten most active posters on the Debian Med mailing list. This graph shows that the number of active supporters was growing constantly in the first years and is now at some constant level.

Considering that some technical discussions initiated at Debian Med mailing lists quite often naturally migrate to the packaging list (see Figure 3(a)) the number of postings of the most active people remained quite constant and only one member of the team became inactive (while some new people came in but are not yet visible in the graphs).

Figure 3: Activity on development list
font=small [] []

The most active people committing packaging materials are shown in Figure 3(a). In the last year 26 developers did 1,108 commits to the SVN repository and since the beginning of Debian Med, 47 developers did 5,545 commits regarding packaging medical applications or documentation about the project.

Andreas Tille 2010-12-10