The Five Stages of Open Source Volunteering

Dirk Riehle,,

Orig­i­nal­ly pub­lished as a FAU Tech­ni­cal Report, lat­er repub­lished by Springer Ver­lag. Please use and cite the Springer Ver­lag ref­er­ence.


Today’s soft­ware sys­tems build on open source soft­ware. Thus, we need to under­stand how to suc­cess­ful­ly cre­ate, nur­ture, and mature the soft­ware devel­op­ment com­mu­ni­ties of the­se open source projects. In this report, we review and dis­cuss best prac­tices of the open source vol­un­teer­ing and recruit­ment process that suc­cess­ful project lead­ers are using to lead their projects to suc­cess. We com­bine the per­spec­tive of the vol­un­teer, look­ing at a project, with the per­spec­tive of a project lead­er, look­ing to find addi­tion­al vol­un­teers for the project. We iden­ti­fy a five-stage process con­sist­ing of a con­nect­ing, under­stand­ing, engag­ing, per­form­ing, and lead­ing stage. The under­ly­ing best prac­tices, when applied, sig­nif­i­cant­ly increase the chances for a suc­cess­ful open source project.

1. Introduction

Open source soft­ware has become an impor­tant part of the Inter­net and today’s enter­pris­es. There is lit­tle soft­ware left that does not at least include some open source com­po­nents. Thus, under­stand­ing how open source projects work and how to uti­lize them is a crit­i­cal capa­bil­i­ty of soft­ware pro­duct com­pa­nies who wish to crowd-source some of their devel­op­ment work. 

Open source soft­ware projects can be split into com­mu­ni­ty open source and com­mer­cial open source soft­ware projects [11] [13]. Com­mu­ni­ty open source soft­ware is soft­ware that is owned by a com­mu­ni­ty, typ­i­cal­ly by way of dis­trib­ut­ed copy­right own­er­ship or by own­er­ship through a non-profit foun­da­tion. Com­mer­cial open source soft­ware devel­op­ment is curat­ed by a sin­gle com­pa­ny, which main­tains the own­er­ship of all rel­e­vant intel­lec­tu­al prop­er­ty. Accord­ing to Mick­os, com­mer­cial open source rarely receives and incor­po­rates code con­tri­bu­tions from their user com­mu­ni­ties [9], how­ev­er, com­mu­ni­ty open source does. 

Com­mu­ni­ty open source soft­ware projects rely on vol­un­teer work to a sig­nif­i­cant extent. Projects which are more mature and relied upon by com­pa­nies may gain com­mer­cial sup­port, which reduces reliance on vol­un­teers [15]. Com­mer­cial sup­port can take the form of direct finan­cial con­tri­bu­tions, which allows foun­da­tions to acquire employ­ees. Also, com­pa­nies may assign their own employ­ees to con­tribute to the project. Lead­ers of new and small com­mu­ni­ty open source projects can­not expect com­mer­cial sup­port, and must learn how to recruit and retain vol­un­teers if they want their project to grow. 

In this report we review best prac­tices of open source com­mu­ni­ty man­age­ment, specif­i­cal­ly, how to find, keep, and grow vol­un­teers. The report is based on a lit­er­a­ture review and obser­va­tion of exist­ing open source projects. We iden­ti­fy five stages of the open source vol­un­teer­ing process which we call the con­nect­ing, under­stand­ing, engag­ing, per­form­ing, and lead­ing stages. For each stage, we dis­cuss the best prac­tices of the actors of that stage. In addi­tion, we dis­cuss the under­ly­ing guid­ing prin­ci­ples that we found to be com­mon to all the prac­tices.

Thus, this report makes the fol­low­ing con­tri­bu­tions:

  • It defines guid­ing prin­ci­ples under­ly­ing the vol­un­teer­ing process; 
  • It presents a five-stage mod­el of the open source vol­un­teer­ing process; 
  • It col­lects and cat­a­logs best prac­tices applic­a­ble to each stage. 

The report is struc­tured as fol­lows. Sec­tion 2 presents the guid­ing prin­ci­ples, Sec­tion 3 intro­duces the five-stage process and dis­cuss­es its prop­er­ties. Sec­tion 4 walks through the stages in detail, dis­cussing best prac­tices and sup­port­ing tools. Relat­ed work as rel­e­vant to the dif­fer­ent sec­tions is dis­cussed in place. Sec­tion 5 con­cludes the report.

2. Guiding Principles of Open Source Projects

In review­ing the lit­er­a­ture (as ref­er­enced in place) and work­ing with open source com­mu­ni­ties as well as from pri­or work we iden­ti­fied the fol­low­ing three guid­ing prin­ci­ples project lead­ers need to under­stand for an effec­tive recruit­ing process: 

  • Recruit­ing is Invest­ment [7], [14]
  • Open Com­mu­ni­ca­tion [14], [7]
  • Open Col­lab­o­ra­tion [12], [14]

We dis­cuss the­se prin­ci­ples in turn. 

2.1 Recruiting is Investment

Accord­ing to Fogel, every inter­ac­tion with a user is a chance to recruit a new vol­un­teer [7]. At the same time, accord­ing to Fitz­patrick and Collins-Sussman, the scarcest resource that a project has is atten­tion and focus [6]. In com­bi­na­tion, this leads to the pri­ma­ry guid­ing prin­ci­ple of open source vol­un­teer recruit­ing:

  • Recruit­ing vol­un­teers is a project invest­ment.

Recruit­ing vol­un­teers is obvi­ous­ly nec­es­sary for a project to grow. How­ev­er, the time spent on recruit­ing takes atten­tion and focus away from actu­al soft­ware devel­op­ment. Spend­ing time on recruit­ing should there­fore be viewed as an invest­ment to be made wise­ly.

Invest­ments may or may not work out. The time spent on a poten­tial vol­un­teer may or may not be wast­ed. Thus, if time is spent on recruit­ing, it should be spent well, and it should be spent in a form com­men­su­rate with the like­li­hood of suc­cess, here, find­ing a new vol­un­teer. The best prac­tices of Sec­tion 4 all embed this prin­ci­ple.

2.2 Open Communication

Open source projects fol­low a par­tic­u­lar style of com­mu­ni­ca­tion which helps sup­port a dis­trib­ut­ed vol­un­teer com­mu­ni­ty. Fogel, for exam­ple, argues that com­mu­ni­ca­tion styles por­tray project mem­bers (who may nev­er have met in per­son) to each oth­er [7]. He argues for gen­er­al prin­ci­ples (all com­mu­ni­ca­tion should be pub­lic) and very speci­fic prin­ci­ples (no con­ver­sa­tions in the bug track­er). Using this and oth­er sources, we derived the fol­low­ing four fun­da­men­tal max­ims of open com­mu­ni­ca­tion that char­ac­ter­ize open source projects and the way project mem­bers com­mu­ni­cate with each oth­er and poten­tial vol­un­teers:

  • Pub­lic. All com­mu­ni­ca­tion should be pub­lic and not take place behind closed doors; any pri­vate side-communication is dis­cour­aged.
  • Writ­ten. All com­mu­ni­ca­tion should be in writ­ten form; if this is not pos­si­ble, any rel­e­vant com­mu­ni­ca­tion should be tran­scribed or sum­ma­rized in writ­ing.
  • Com­plete. Com­mu­ni­ca­tion should be com­pre­hen­sive and to the extent pos­si­ble, com­plete. Assump­tions are made explic­it and key con­clu­sions are sum­ma­rized.
  • Archived. All com­mu­ni­ca­tion should get archived for search and lat­er pub­lic review. Thus, pre­vi­ous con­ver­sa­tions are avail­able for pos­ter­i­ty.

Tak­en togeth­er, the­se max­ims cre­ate trans­paren­cy and dis­ci­pline com­mu­ni­ca­tion, lead­ing to more effec­tive dis­trib­ut­ed col­lab­o­ra­tion. Although not all com­mu­ni­ca­tion with­in a project will embody all four max­ims, a project which is moti­vat­ed to be trans­par­ent and grow its com­mu­ni­ty will make the accord­ing effort, for exam­ple, by tran­scrib­ing or sum­ma­riz­ing non-email forms of com­mu­ni­ca­tion in order to provide a pub­lic archive. 

Pub­lic com­mu­ni­ca­tion ensures that all mem­bers of the com­mu­ni­ty have the oppor­tu­ni­ty to par­tic­i­pate, which cre­ates buy-in and trust. Writ­ten com­mu­ni­ca­tion enables asyn­chro­nous, dis­trib­ut­ed work. Peo­ple who are less flu­ent in the lan­guage used for com­mu­ni­ca­tion also ben­e­fit from hav­ing addi­tion­al time to absorb the mean­ing [3], which makes the project acces­si­ble to a wider audi­ence. Com­plete com­mu­ni­ca­tion reduces oppor­tu­ni­ties for mis­un­der­stand­ing and ensures that the com­mu­ni­ty shares a com­mon under­stand­ing of objec­tives. Archiv­ing increas­es trans­paren­cy by ensur­ing that deci­sions can be under­stood in con­text.

Many of the­se con­cepts rein­force one anoth­er. Writ­ing enables archiv­ing, as cur­rent search tech­nol­o­gy is text-based. The need to derive mean­ing from archives encour­ages more com­plete com­mu­ni­ca­tion. Archives are more com­pre­hen­sive and com­pre­hen­si­ble if all con­ver­sa­tion is pub­lic.

2.3 Open Collaboration

No two open source projects fol­low the same soft­ware devel­op­ment process. How­ev­er, in pri­or work and by way of project reviews, we iden­ti­fied three under­ly­ing fun­da­men­tal com­po­nents of open source col­lab­o­ra­tion [12]. The­se three max­ims of open col­lab­o­ra­tion are: 

  • Egal­i­tar­i­an. Every­one may join a project, no prin­ci­pled or arti­fi­cial status-based bar­ri­ers to par­tic­i­pa­tion exist. 
  • Mer­i­to­crat­ic. Deci­sions are made based on the mer­its of the argu­ments, and sta­tus is deter­mined by the mer­its of a person’s con­tri­bu­tions.
  • Self-organizing. Process­es adapt to peo­ple rather than peo­ple to process­es.

Relat­ed work fre­quent­ly sub­sumes the first two max­ims under the sin­gle con­cept of mer­i­toc­ra­cy. We find it help­ful to dis­tin­guish between them: Open­ness in the con­text of egal­i­tar­i­an­ism means that all peo­ple have the oppor­tu­ni­ty to par­tic­i­pate, where­as open­ness in the con­text of mer­i­toc­ra­cy ensures that all work is eval­u­at­ed on the basis of its intrin­sic val­ue.

The­se con­cepts are in stark con­trast to tra­di­tion­al work inside com­pa­nies. Projects aren’t egal­i­tar­i­an: Employ­ees are assigned to work on them and can­not choose to work on oth­er projects. Deci­sions are not nec­es­sar­i­ly made on the basis of the mer­it of the argu­ments, but are ulti­mate­ly the choice of the per­son with the great­est pow­er. Final­ly, process­es in a large com­pa­ny are typ­i­cal­ly defined by a cen­tral depart­ment and employ­ees are expect­ed to adapt their work process­es to the com­pa­ny envi­ron­ment.

Open source projects are dif­fer­ent: It is rec­og­nized that any poten­tial vol­un­teer could become a valu­able resource. Thus, an effec­tive project process must be open to accept­ing vol­un­teers (egal­i­tar­i­an­ism), must rec­og­nize qual­i­ty regard­less of the source (mer­i­toc­ra­cy), and allow process­es to devel­op accord­ing to the needs of the com­mu­ni­ty (self-organizing).

The five stage process of open source vol­un­teer­ing described in the fol­low­ing Sec­tion is based on the three guid­ing prin­ci­ples of the open source vol­un­teer­ing process: recruit­ment is invest­ment, open com­mu­ni­ca­tion, and open col­lab­o­ra­tion.

3. The Five-Stage Volunteering Process

In [2], Behlen­dorf illus­trates a typ­i­cal exam­ple of how a devel­op­er might join a project, rise through the ranks, and become a project lead­er. The devel­op­er

  1. needs to solve a prob­lem,
  2. search­es web for appro­pri­ate soft­ware,
  3. finds a match­ing project, 
  4. checks out the project, 
  5. gives the project a try and is hap­py,
  6. finds a bug and reports it, 
  7. makes a first con­tri­bu­tion,
  8. engages in a con­ver­sa­tion,
  9. keeps con­tribut­ing,
  10. receives a vote of trust, and 
  11. ulti­mate­ly leads the project. 

By cor­re­lat­ing this 11-step process with Fogel’s work [7] and by align­ing it with the Onion mod­el of roles in open source soft­ware devel­op­ment [4], we were led to a sim­pler and denser five stage mod­el of the open source vol­un­teer­ing process than the one pro­posed by Behlen­dorf. This mod­el is shown in Fig­ure 1. 

# Stage Vol­un­teer View Vol­un­teer Role Name Project View
1 Con­nect­ing Find project Seek­er Mar­ket project
2 Under­stand­ing Under­stand project Vis­i­tor (Read­er) Explain project
3 Engag­ing Engage with project User Engage with user
4 Per­form­ing Work with­in project Con­trib­u­tor Work with con­trib­u­tor
5 Lead­ing Lead project Lead­er Enable career

Fig­ure 1: A Five-Stage Mod­el of the Open Source Vol­un­teer­ing Process

An inno­va­tion of this mod­el is the addi­tion of the two com­ple­men­tary views of vol­un­teer and project (lead­er), which lead to com­ple­men­tary but mutu­al­ly sup­port­ing best prac­tices and activ­i­ties. The stages are defined in the fol­low­ing way: 

  1. Stage 1: Con­nect­ing. In this stage, a poten­tial vol­un­teer stum­bles over a project by lucky chance or, after search­ing for some­thing like it, finds the project through a search engine. The project needs to pre­pare for this to hap­pen, which requires mar­ket­ing itself through appro­pri­ate chan­nels and at appro­pri­ate por­tals.
  2. Stage 2: Under­stand­ing. In this stage, once a poten­tial vol­un­teer is look­ing at a project’s web­site, the web­site needs to draw him or her in. Using a vari­ety of best prac­tices, the project helps the vis­i­tor quick­ly under­stand what the project is about and whether it should be of inter­est to them. 
  3. Stage 3: Engag­ing. In this stage, a poten­tial vol­un­teer is inspired to engage with the project, for instance by installing the soft­ware or join­ing a mail­ing list. The project strives to wel­come users to the com­mu­ni­ty and direct them toward the next stage by pro­vid­ing infor­ma­tion of sim­ple ways to vol­un­teer.
  4. Stage 4: Per­form­ing. In this stage, a vol­un­teer con­tributes to the project. The project com­mu­ni­ty needs to be recep­tive to ini­tial efforts by react­ing quick­ly to con­tri­bu­tions and cre­at­ing con­ver­sa­tions to improve qual­i­ty. The project needs to guide users towards becom­ing reg­u­lar con­trib­u­tors.
  5. Stage 5: Lead­ing. In this stage, the vol­un­teer accepts respon­si­bil­i­ty for the direc­tion of the project or com­mu­ni­ty. The project must have a mech­a­nism for iden­ti­fy­ing poten­tial lead­ers and mak­ing deci­sions on their pro­mo­tion to lead­er sta­tus as well as for com­mu­ni­cat­ing this clear­ly.

Not all vol­un­teers pass through all stages, but stages can only be tak­en one after anoth­er. Each sub­se­quent stage will be reached by few­er vol­un­teers. The best prac­tices described in the next Sec­tion sup­port each stage. For a project, they help increase vol­un­teer com­mit­ment. When recruit­ment is viewed as an invest­ment, best prac­tices are aligned with pro­mot­ing long-term involve­ment. For a vol­un­teer, best prac­tices advise on how to achieve goals, from find­ing a project that ful­fills a need to gain­ing recog­ni­tion with­in a project. We now describe each stage in detail, along with select­ed best prac­tices from each per­spec­tive and tools to sup­port them. 

4. Best Practices and Supporting Tools

A best prac­tice “is a broadly-accepted, typ­i­cal­ly informally-defined, method for achiev­ing a par­tic­u­lar goal that is con­sid­ered supe­ri­or to most oth­er known meth­ods” (author’s adap­ta­tion of the Wikipedia entry on “best prac­tice” [16]). Thus, a best prac­tice is a method reflect­ing the state-of-the-art as applic­a­ble in a par­tic­u­lar con­text.

The fol­low­ing best prac­tices have been derived from the respec­tive ref­er­ences, in par­tic­u­lar [7] [1] [8] [6] [2] [5]. They have been grouped accord­ing to the phas­es described in Sec­tion 3 and divid­ed into the two per­spec­tives described there: the volunteer’s view and the project leader’s view. They are based on the appli­ca­tion of the three prin­ci­ples of open source vol­un­teer­ing described ear­lier in Sec­tion 2. Due to the large num­ber of some­times mun­dane best prac­tices, not all are dis­cussed in detail. 

The prin­ci­ple which informs all best prac­tices from the project view is that of recruit­ment as an invest­ment. In a project, time is the scarcest resource, and recruit­ment takes time. Increas­ing the long-term return on time invest­ed [7]—or encour­ag­ing vol­un­teers to move to each suc­ces­sive phase—is there­fore the objec­tive of the project’s lead­er­ship. Open com­mu­ni­ca­tion and open col­lab­o­ra­tion are also reflect­ed in the best prac­tices; they are the under­ly­ing tenet that make open source projects work. 

A vol­un­teer is not a pas­sive sub­ject to be recruit­ed, but an indi­vid­u­al with objec­tives in mind. At each phase, a vol­un­teer wants to ensure max­i­mum val­ue for the invest­ment, which is where best prac­tices come into play. The vol­un­teer who is pre­pared will achieve bet­ter results than one who fails to con­sid­er the project’s needs. 

4.1 Stage 1: Connecting

Fig­ure 2 dis­plays all best prac­tices of Stage 1, the Con­nect­ing stage. Vol­un­teers can be sep­a­rat­ed into two cat­e­gories, those that stum­ble onto the project by luck, and those that search for a solu­tion to a prob­lem they have. Project best prac­tices can be split into active out­reach being per­formed and pas­sive inflow that needs to be pre­pared for. 

Vol­un­teer (Seek­er) View Project View
Stum­bling Active Out­reach
  • Stum­ble upon project 
  • Fol­low word-of-mouth 
  • Choose a good name 
  • Define rel­e­vant chan­nels
  • Use chan­nels con­sis­tent­ly
  • Announce vis­i­bly
  • Be mat­ter of fact 
Search­ing Pas­sive Inflow
  • Use gen­er­al search engine 
  • Search on open source por­tal
  • Reg­is­ter on all por­tals
  • Sup­port search engi­nes
  • Sup­port lucky chance 
    • Use por­tal fea­tures
    • Provide find­able sum­maries
    • Work towards por­tal met­rics

Fig­ure 2: Best prac­tices of Stage 1, the Con­nect­ing stage.

Two terms stick out among the project best prac­tices, chan­nel and por­tal:

  • An open source project chan­nel is a com­mu­ni­ca­tion chan­nel for a project to reach poten­tial­ly inter­est­ed par­ties, in par­tic­u­lar vol­un­teers. Exam­ples of such chan­nels are: 
    • Social media chan­nels like Face­book or Twit­ter
    • Tar­get­ed com­mu­ni­ca­tion chan­nels like Slash­dot or Hack­er News 
    • Speci­fic open source con­fer­ences like OSCON or ApacheCon 
  • An open source project por­tal is a por­tal web­site ded­i­cat­ed to open source projects. Exam­ples of such web­sites are: 
    • Project host­ing sites like Source­Forge or Github 
    • Meta-sites like Fresh­meat or Ohloh 

Chan­nels are most­ly used for active out­reach and when the project has a sto­ry to tell, for exam­ple, the ini­tial release. Por­tals are used for pas­sive inflow where searchers can find them when they are seek­ing a solu­tion.

A project should choose a good name that is easy to remem­ber and ide­al­ly indica­tive of the project’s pur­pose. As an alter­na­tive to descrip­tive names, whol­ly arti­fi­cial names may serve the project equal­ly well. Any com­mu­ni­ca­tion then should stick to that name and use it con­sis­tent­ly. The rel­e­vant chan­nels and por­tals (see above) need to uti­lized repeat­ed­ly, con­sis­tent­ly and pre­dictably. Any com­mu­ni­ca­tion should be matter-of-fact rather than hyperbole—projects are try­ing to cre­ate a long-term rep­u­ta­tion, not a short spike of atten­tion fol­lowed by dis­ap­point­ment over the hyper­bole. The most com­mon form of com­mu­ni­ca­tion is the announce­ment of new releas­es of the soft­ware, fol­lowed by announce­ments over major devel­op­ments in the project com­mu­ni­ty or spon­sor­ship.

4.2 Stage 2: Understanding

In the sec­ond stage, the empha­sis is on com­mu­ni­cat­ing the project’s pur­pose to a vol­un­teer who wants to quick­ly learn if the project answers his or her need. Fig­ure 3 lists rel­e­vant best prac­tices.

Var­i­ous pieces of infor­ma­tion need to be eas­i­ly acces­si­ble, both in terms of find­ing and under­stand­ing the infor­ma­tion. A first step is to have a clear mis­sion state­ment that spells out the project’s pur­pose and does so in a high­ly vis­i­ble place, for exam­ple, the front page of the project’s web­site on a soft­ware forge. Exam­ples and screen-shots should be eas­i­ly acces­si­ble to make it straight­for­ward for vis­i­tors to assess what the soft­ware does in prac­ti­cal and tan­gi­ble terms (short of down­load­ing and installing the soft­ware, which would be the next step). Words are only so good—examples and screen-shots some­times com­mu­ni­cate more clear­ly.

Vol­un­teer (Vis­i­tor) View Project View
Read­ing Up Explain Project
  • Read up on project
  • Have clear mis­sion state­ment
  • Provide exam­ples and screen-shots 
  • State license and terms 
  • Provide sim­ple down­loads
  • Show cur­rent and future releas­es
  • Show devel­op­ment sta­tus
  • Provide user doc­u­men­ta­tion
  • State whether vol­un­teers are wel­come
  • State rules of engage­ment

Fig­ure 3: Best prac­tices of Stage 2, the Under­stand­ing stage.

Many vis­i­tors will also want to know about relat­ed project infor­ma­tion like soft­ware licens­es or (assumed) qual­i­ty of the soft­ware (by way of devel­op­ment sta­tus). Thus, a project should dis­play promi­nent­ly which open source license it is using, what state of devel­op­ment it is cur­rent­ly in, and what future expect­ed devel­op­ments are, includ­ing upcom­ing releas­es and key new fea­tures and func­tion­al­i­ties. The vis­i­tor, who wants to try the soft­ware, may need user doc­u­men­ta­tion, which should there­fore be pro­vid­ed.

Vis­i­tors have ques­tions or may want to become vol­un­teers, and hence a project is well advised to spell whether vol­un­teers are wel­come and what the project rules are so that some­one con­sid­er­ing to par­tic­i­pate will now what they are get­ting into. 

4.3 Stage 3: Engaging

In the engage­ment stage, the empha­sis is on facil­i­tat­ing com­mu­ni­ca­tion between the project and the vol­un­teer. Fig­ure 4 lists rel­e­vant best prac­tices.

Vol­un­teer (User) View Project View
All Vol­un­teers Towards all Vol­un­teers
  • Do your home­work before ask­ing
    • Search archives
    • Read doc­u­men­ta­tion
  • Com­mu­ni­cate pru­dent­ly
    • Be mat­ter of fact 
    • Don’t jump to con­clu­sions
  • Show how to reach project 
  • Wel­come to com­mu­ni­ty
  • Stop any rude­ness
  • Avoid pri­vate dis­cus­sions
  • Accept ini­tial redun­dan­cy
  • Provide sim­ple tasks 
  • Provide incre­men­tal tasks 
  • Call out lurk­ers from the shad­ows
Soft­ware Devel­op­ers Towards Soft­ware Devel­op­ers
  • Respect project prac­tices
  • Respect project cul­ture
  • Accept guid­ance
  • Provide tool access 
  • Remove arbi­trary tool obsta­cles
  • Show require­ments list 
  • Provide devel­op­er guide­li­nes
  • Provide devel­op­er doc­u­men­ta­tion

Fig­ure 4: Best prac­tices of Stage 3, the Engag­ing stage.

It needs to be clear (and clear­ly dis­played) how cur­rent project mem­bers can be reached. At this stage, the project may only be per­ceived as an anony­mous enti­ty with no par­tic­u­lar face. Poten­tial vol­un­teers need start­ing points, for exam­ple, forums or mail­ing lists where they can ask ques­tions.

A first respon­se should be wel­com­ing of a new poten­tial vol­un­teer, and any pos­si­ble rude­ness, whether inci­den­tal or delib­er­ate, needs to be stopped imme­di­ate­ly. It is para­mount that any project mem­ber redi­rects any pri­vate­ly posed ques­tions to a pub­lic forum and avoids answer­ing ques­tions in pri­vate; this would be a high­ly inef­fi­cient use of their time. Vis­i­tors need to under­stand that they con­sume time and hence should do their home­work or should be guid­ed to do their home­work before ask­ing. Doing one’s home­work implies read­ing exist­ing mate­ri­als to avoid redun­dant ques­tions. Also, vis­i­tors have to learn to ask in pub­lic so that every­one can learn from their con­sid­er­a­tions and ques­tions. Com­mu­ni­ca­tion, both on the vis­i­tor and the project side, should be mat­ter of fact and con­tent focused, try­ing to help solve the prob­lem or ques­tion at hand. 

For more advanced vis­i­tors, or users of the soft­ware, it should be pos­si­ble to learn about sim­ple tasks that the project would ben­e­fit from. The project should spell out such tasks, even if writ­ing them down may cost near­ly as much time as per­form­ing them, because sim­ple tasks provide a mech­a­nism to engage vol­un­teers. Sim­i­lar­ly, there should be incre­men­tal tasks to be picked up, which will allow vol­un­teers to work with exist­ing devel­op­ers rather than alone. Incre­men­tal tasks also intro­duce vol­un­teers to exist­ing tech­ni­cal aspects of the project. 

A lot of things can go wrong when set­ting up a project for engag­ing poten­tial vol­un­teers, and appro­pri­ate atten­tion needs to be paid so that tools and project arti­facts like task and require­ments lists are acces­si­ble, and that devel­op­ers can find appro­pri­ate guide­li­nes and doc­u­men­ta­tion.

Under­ly­ing all the­se project best prac­tices is the guid­ing prin­ci­ple of mak­ing it as easy as pos­si­ble for a vol­un­teer to make a first con­tri­bu­tion. Get­ting to that first con­tri­bu­tion is the sin­gle most impor­tant hur­dle a project has to over­come. Thus, many of the best prac­tices work hand-in-hand to make that first con­tri­bu­tion hap­pen.

4.4 Stage 4: Performing

The per­for­mance stage is when the vol­un­teer con­tributes to the project. It can be sub­di­vid­ed into a first con­tri­bu­tion and lat­er more reg­u­lar con­tri­bu­tions. Fig­ure 5 lists appro­pri­ate best prac­tices for project lead­ers.

Vol­un­teer (Con­trib­u­tor) View Project View
Gen­er­al Prac­tices Gen­er­al Prac­tices
  • Con­tribute
  • Be component-oriented
  • Work from fea­tures
  • No dis­cus­sions in bug track­er
  • Decide using con­sen­sus
  • Vote as a last resort 
First Con­tri­bu­tions Towards First Con­tri­bu­tions
  • Con­tribute
  • React speed­i­ly, don’t sit on patch­es
  • Turn con­tri­bu­tions into con­ver­sa­tions
  • Prac­tice con­spic­u­ous code review 
  • Track con­tri­bu­tions, provide cred­it
  • Praise plen­ti­ful­ly, crit­i­cize specif­i­cal­ly
  • Pre­vent ter­ri­to­ri­al­i­ty
Reg­u­lar Con­tri­bu­tions Towards Reg­u­lar Con­tri­bu­tions
  • Con­tribute
  • Track inter­ests, assign accord­ing­ly
  • Dis­tin­guish inquiry from assign­ment
  • Share tech­ni­cal and man­age­ri­al tasks 
  • Follow-up on del­e­gat­ed assign­ments
  • Doc­u­ment prac­tices and tra­di­tions
  • Archive prac­tice descrip­tions

Fig­ure 5: Best prac­tices of Stage 4, the Per­form­ing stage.

A volunteer’s first con­tri­bu­tion is like dip­ping a toe into the water. Depend­ing on how the expe­ri­ence feels, the vol­un­teer may not come back. Thus, it is impor­tant to ensure that this first con­tri­bu­tion becomes a pos­i­tive expe­ri­ence. For one, a con­tri­bu­tion should be well received and react­ed to. Noth­ing is worse than no reac­tion, for exam­ple, by let­ting a patch sit idle. The appro­pri­ate reac­tion to a patch is to turn it into a con­ver­sa­tion, not only to say thanks, but also to encour­age fur­ther con­tri­bu­tions by point­ing the vol­un­teer to relat­ed issues. In all but the most sim­plest patch­es or con­tri­bu­tions, the vol­un­teer may have to be guid­ed to rework­ing the con­tri­bu­tions, for exam­ple, to ensure com­pli­ance with the project’s pro­gram­ming guide­li­nes. Code review of a patch sub­mis­sion is a gen­er­al best prac­tice, but also shows the vol­un­teer that their con­tri­bu­tion is being tak­en seri­ous, even if it leads to a request to fix a prob­lem with the sub­mis­sion. Final­ly, after a suc­cess­ful con­tri­bu­tion, it is crit­i­cal to pay cred­it to who cred­it is due and list the vol­un­teer as a con­trib­u­tor to the project. 

Vol­un­teers, who have become reg­u­lar con­trib­u­tors, may then be will­ing to pick up oth­er tasks out­side their orig­i­nal inter­ests. Still, project lead­ers should track and play to vol­un­teer inter­ests when ask­ing them for help, for exam­ple, to work on a par­tic­u­lar fea­ture. Vol­un­teers, who have bought into the project are fre­quent­ly will­ing to pick up work that they orig­i­nal­ly did not join the project for. This includes unloved tasks like project doc­u­men­ta­tion and is not restrict­ed to tech­ni­cal tasks alone. 

A project lead­er who asked a con­trib­u­tor to per­form some work and received a com­mit­ment needs to ful­fill a man­age­ri­al role now. For exam­ple, if the con­trib­u­tor is not pro­vid­ing the promised fea­ture, the project lead­er may have to inquire about pro­gress, nudg­ing the con­trib­u­tor along (and mak­ing men­tal notes as to whether this was a good request that matched the vol­un­teers inter­ests).

Some­times, a project may run into dif­fi­cult peo­ple. “Dif­fi­cult” or even “poi­so­nous” peo­ple, accord­ing to Fitz­patrick and Collins-Sussman, may waste a project’s time or split and even ruin a project [6]. Best prac­tices to pre­pare for the prob­lem are to

  1. build a healthy com­mu­ni­ty and 
  2. doc­u­ment all deci­sions.

It is nec­es­sary then to detect the prob­lem: Dif­fi­cult peo­ple typ­i­cal­ly don’t show respect, miss social cues, are over­ly emo­tion­al, and mak­ing sweep­ing claims not based on any data. Best prac­tices to han­dle the prob­lem are to

  1. not engage them, 
  2. ignore them if pos­si­ble,
  3. remove them from the project if nec­es­sary.

Gen­er­al engi­neer­ing man­age­ment advice applies as well. The sys­tem soft­ware archi­tec­ture needs to match its social struc­ture, which typ­i­cal­ly implies a well-componentized struc­ture so that devel­op­ers can work inde­pen­dent­ly of each oth­er and in a dis­trib­ut­ed fash­ion. The require­ments and open tasks in con­trast should be feature-oriented, as com­plet­ing a fea­ture is a major moti­va­tion for a devel­op­er because it pro­vides mean­ing to the work being per­formed.

Unlike in tra­di­tion­al (non-open) con­texts, how­ev­er, the prin­ci­ples of open com­mu­ni­ca­tion and open col­lab­o­ra­tion need to be main­tained. This requires appro­pri­ate consensus-oriented and merit-based dis­cus­sion as to deci­sions to be tak­en. Vot­ing to make a deci­sion is a last resort to resolve a con­flict and should be used rarely. 

4.5 Stage 5: Leading

In the final phase, the vol­un­teer becomes a project lead­er and takes respon­si­bil­i­ty for the best prac­tices of the project view for the ear­lier phas­es. Fig­ure 6 shows some of the best prac­tices that apply at this lev­el.

Vol­un­teer View Project View
Gen­er­al Prac­tices
  • Take respon­si­bil­i­ty
  • Praise oth­er con­trib­u­tors
  • Acknowl­edge con­tri­bu­tions
  • Sup­port oth­ers towards their man­ager
  • Provide tokens of appre­ci­a­tion
  • Define com­mu­ni­ty career 
  • Define roles and posi­tions
  • Decide pro­mo­tion pri­vate­ly
  • Announce pro­mo­tion clear­ly

Fig­ure 6: Best prac­tices of Stage 5, the Lead­ing stage.

At this stage, a project lead­er is basi­cal­ly a man­ager, but with­out the pow­er found inside tra­di­tion­al orga­ni­za­tions. He or she has to rely on the pow­er of per­sua­sion and good­will that con­trib­u­tors have devel­oped towards the project. With increas­ing com­mer­cial­iza­tion and paid-for par­tic­i­pa­tion in open source, some of the­se chal­lenges become less seri­ous, and devel­op­ers may need less intrin­sic moti­va­tion. Still it remains good prac­tice to per­son­al­ly moti­vate devel­op­ers through their work beyond the pos­si­ble salary that an employ­er may be pay­ing for their open source work. 

The pow­er of lead­er­ship rests on set­ting a good exam­ple by tak­ing respon­si­bil­i­ty and act­ing accord­ing­ly, by prais­ing oth­er people’s work and acknowl­edg­ing their con­tri­bu­tions. Addi­tion­al actions may be nec­es­sary to help con­trib­u­tors out­side the project, for exam­ple, if they are per­form­ing open source work on company-time with­out the employ­er hav­ing a par­tic­u­lar inter­est in the project. Then, the open source project lead­er may have to help moti­vate why the developer’s work ulti­mate­ly ben­e­fits his or her employ­er.

The open source project itself needs man­age­ment in that con­trib­u­tors find the work for­mal­ly acknowl­edged in the form of tra­di­tion­al cred­its. Con­trib­u­tors are also hav­ing a form of open source career. Tak­ing steps in this career, most notably from con­trib­u­tor to com­mit­ter, may be touchy sub­jects, and are one of the few dis­cus­sions that the exist­ing project lead­ers may have to decide pri­vate­ly and not in the pub­lic eye. This is jus­ti­fied, because such a dis­cus­sion is typ­i­cal­ly more about the social aspects of work­ing with the to-be-promoted per­son rather than his or her tech­ni­cal capa­bil­i­ties. In case of a pos­i­tive deci­sion, the pro­mo­tion needs to be announced pub­licly and doc­u­ment­ed accord­ing­ly so that every­one in the project knows. 

5. Conclusions

This report first iden­ti­fied the three guid­ing prin­ci­ples of open source projects. Vol­un­teers are the lifeblood of an open source project, and an effec­tive recruit­ing process con­sid­ers all three prin­ci­ples.

First, recruit­ing is an invest­ment: time and effort are invest­ed in order to yield long-term results. Sec­ond, open com­mu­ni­ca­tion facil­i­tates the vol­un­teer process by cre­at­ing trans­paren­cy. Third, open col­lab­o­ra­tion opens the recruit­ment process to any poten­tial vol­un­teer and allows them to con­tribute to their fullest extent. 

A mod­el of five phas­es of engage­ment is pre­sent­ed. This mod­el looks at the dif­fer­ent lev­els of vol­un­teer com­mit­ment from both the per­spec­tive of the vol­un­teer and of the project. 

The three vol­un­teer­ing prin­ci­ples are used to advance a num­ber of best prac­tices which are tied to the five stages of engage­ment. At each phase—connecting, under­stand­ing, engag­ing, per­form­ing and leading—there are objec­tives and best prac­tices for both the vol­un­teer and the project, as rep­re­sent­ed by its lead­er­ship. The best prac­tices are derived from exist­ing lit­er­a­ture and obser­va­tion.


I would like to thank Ann Bar­comb for help­ful com­ments that improved the report. 


  1. Jono Bacon. The Art of the Com­mu­ni­ty, Sec­ond Edi­tion. O’Reilly: 2012. 
  2. Bri­an Behlen­dorf (as inter­viewed by Andrew Bin­stock). “How to Con­tribute to Open Source Projects.” Dr. Dobbs: June 21st, 2011. Avail­able from
  3. Erran Carmel and Paul Tija. Off­shoring Infor­ma­tion Tech­nol­o­gy: Sourcing and Out­sourcing to a Glob­al Work­force. Cam­bridge Uni­ver­si­ty Press: 2006. 
  4. Kev­in Crow­ston, James How­ison (2011). “The Social Struc­ture of Free and Open Source Soft­ware Devel­op­ment.” First Mon­day vol. 10, no. 2. Avail­able from
  5. Bertrand Delac­re­taz. “Open Source Col­lab­o­ra­tion Tools are Good for You!” Talk pre­sent­ed at Open­Ex­po, 2009. Avail­able from
  6. Bri­an Fitz­patrick and Ben Collins-Sussman. “How Open Source Projects Sur­vive Poi­so­nous Peo­ple.” Talk pre­sent­ed at Google I/O, 2008. Avail­able from
  7. Karl Fogel. Pro­duc­ing Open Source Soft­ware. O’Reilly: 2005. 
  8. Ron Gold­man, Richard Gabriel. Inno­va­tion Hap­pens Else­where. Else­vier: 2005. 
  9. Marten Mick­os. “Open for busi­ness: Build­ing suc­cess­ful com­merce around open source.” Talk held at PARC Forum, 2010-04-08. Avail­able from, sum­ma­rized at
  10. Kumyio Nakako­ji, Yasuhi­ro Yamamo­to, Yoshiyuki Nishi­naka, Kouichi Kishi­da, Yun Wen. “Evo­lu­tion Pat­terns of Open-Source Soft­ware Sys­tems and Com­mu­ni­ties.” In Pro­ceed­ings of Inter­na­tion­al Work­shop on Prin­ci­ples of Soft­ware Evo­lu­tion. ACM: 2002. Page 76–85.
  11. Dirk Riehle. “The Eco­nom­ic Moti­va­tion of Open Source.” IEEE Com­put­er vol. 40, no. 4 (April 2007). Page 25–32.
  12. Dirk Riehle, John Ellen­berg­er, Tamir Mena­hem, Boris Mikhailovski, Yuri Natch­etoi, Barak Naveh, and Thomas Oden­wald. “Open Col­lab­o­ra­tion with­in Cor­po­ra­tions Using Soft­ware Forges.” IEEE Soft­ware vol. 26, no. 2 (March/April 2009). Page 52–58.
  13. Dirk Riehle. “The Eco­nom­ic Case for Open Source Foun­da­tions.” IEEE Com­put­er vol. 43, no. 1 (Jan­u­ary 2010). Page 86–90.
  14. Dirk Riehle. “The Open Source Knowl­edge Shar­ing and Vol­un­teer­ing Process.” Talk at the Gesellschaft für Wis­sens­man­age­ment. Erlan­gen, Ger­many, 2011-07-14. 
  15. Dirk Riehle, Philipp Riemer, Carsten Kolas­sa, and Michael Schmidt. “Paid vs. Vol­un­teer Work in Open Source.” In Pro­ceed­ings of the 47th Hawaii Inter­na­tion­al Con­fer­ence on Sys­tem Sci­ence (HICSS 2014). IEEE Press: 2014. 
  16. Wikipedia. Def­i­n­i­tion of Best Prac­tice. Avail­able from Accessed 2013-07-11. 

2 thoughts on “The Five Stages of Open Source Volunteering

  1. James

    Regard­ing your state­ments about meta-sites:

    Meta-sites like Fresh­meat or Ohloh”

    Please note that Fresh­meat has been renamed to Freecode and Ohloh has been renamed to Open­Hub.


Leave a Reply