Improving cooperation in volunteer projects

Workflow, communication, tools — and how to get people to adopt them

Martin F. Krafft <>

  • Ph.D. student, University of Limerick, Ireland
  • Developer with the Debian, Zope, and Plone projects
FrOSCon 2006, Sankt Augustin, Germany 24 June 2006




In gardening and botanical terminology, a volunteer is a plant that grows on its own, rather than being deliberately planted by a human farmer or gardener (Wikipedia).


Less botanical:

One who enters into, or offers for, any service of his own free will (Webster's (via
Any service?


I need a volunteer, please...


Sorry; moving on...

One who enters into, or offers for, any service of his own free will (Webster's (via

Other works on motivation (e.g. The Cathedral and the Bazaar), we'll concentrate on one main aspect:

Giving direction

If "volunteers do just what they want", how can projects follow a direction?

(this list is not supposed to be flame bait!)

Size matters

In smaller projects, leaders look up to governors who are decision makers.

As the project grows more diverse,

Diverse projects have a strong self-dynamics.

It is impossible to change existing processes by force in volunteer projects.



What am I actually trying to do?

Revolutionise project leadership?



(you can stop worrying now)

Goal: improve cooperation

... where "improve" primarily means "facilitate" or "streamline".

Why? What problem am I trying to solve?

Stagnation and inflexibility due to high inertia

Stagnation and inflexibility in Debian

Claim: Debian could be further and more agile

(I don't want to paint a black picture though)

I have two hours to work on a Debian package, I don't want to spend most of that on learning how a certain package is managed!


Improving Cooperation

How can cooperation be facilitated, streamlined?

Some ideas:

Example: package maintenance

The principles should be:

Don't do manually what you can automate!

Keep it simple, stupid!

Top-down vs. bottom-up

Comparisons: Plone and Debian

Differentiate between projects, take Plone and Debian as examples:

Criterium Plone Debian
Age relatively young relatively aged
Jumpstart sprang from Zope started from scratch (pioneer)
Size small number of contributors large number of contributors
VCS usage used one VCS from the start tried to introduce VCS later, no standard
Bug tracking in flux, standardised now early introduction of debbugs
Workflow simple(r), one product Various, many constituents

Main points of focus

Debian package maintenance:

Improving cooperation in Debian

Some ideas:

The problem with VCS

How to get people to adopt?

We cannot just revolutionise the process.

Remember: volunteers don't like to be told how to do things

Two strategies for adoption:

Seamless integration

What to integrate?

Integration of VCS with debian/changelog


Integration of VCS with debbugs


The word "automatic" does cause chills among many. Things should be automated the Debian way, as in: facilitated but requiring manual action.

Integration of VCS with the upload process

Problem: maintenance is distributed, but we still need one developer for the upload. This can lead to a myriad of problems, ranging from bottlenecks to quality control.



Technical merits

What are technical merits that will lead users to adopt?

Tools that have been successful

Successful introduction: debian-installer

Successful introduction: debhelper

Tools that have been less successful

Unsuccessful introduction: pkg-zope

Successful tools, improving cooperation

What are the characteristics of successful tools?
What other ways are there to improve cooperation?

This is only the beginning...

Thank you for your attention!


These slides, their design, and the content are © Martin F. Krafft and released under the terms of the Artistic Licence.

reStructuredText sources: slides.rst and ui/base/*