The Open Source Software Developer Career and Its Benefits

Please note: This is the orig­i­nal of a copy-edited arti­cle that appeared in IEEE Com­put­er in May of 2015. See here for the offi­cial pub­li­ca­tion, includ­ing a PDF.

Dirk Riehle,,
Pro­fes­sur für Open-Source-Software, Com­put­er Sci­ence Depart­ment
Friedrich-Alexander Uni­ver­sität Erlangen-Nürnberg


Open source soft­ware devel­op­ment is chang­ing the labor mar­ket for soft­ware devel­op­ers. Ben­e­fits of par­tic­i­pa­tion in open source projects can be increased salaries and improved job secu­ri­ty. Three forms of com­pet­i­tive advan­tage have emerged: ver­i­fi­able tech­ni­cal skills, peer-certified com­pe­ten­cies and posi­tion­al pow­er. The­se com­pet­i­tive advan­tages strength­en a developer’s nego­ti­a­tion pow­er towards a prospec­tive employ­er. Soft­ware devel­op­ers, hir­ing man­agers, and per­son­nel depart­ments of com­pa­nies rely­ing on open source in their soft­ware devel­op­ment need to under­stand this new real­i­ty to effec­tive­ly hire devel­op­ers and work with asso­ci­at­ed open source projects.


Open source; inner source; open source foun­da­tions; open source com­mit­ter; soft­ware devel­op­er career; soft­ware devel­op­er com­pe­ten­cies; soft­ware eco­nom­ics; IT labor eco­nom­ics; soft­ware labor mar­ket; IT labor mar­ket; soft­ware indus­try, IT indus­try

Table of Contents

1. Intro­duc­tion
2. The Open Source Devel­op­er Career
3. Sig­nals of Open Source Sta­tus
4. Eco­nom­ic Val­ue of Sig­nals
5. A New Soft­ware Devel­op­er Labor Mar­ket?
6. Con­clu­sions

1. Introduction

Erich Gam­ma is a 2011 win­ner of the ACM soft­ware sys­tems award, which he received for his work on the open source Eclipse plat­form. When reflect­ing on hir­ing soft­ware devel­op­ers, he had this to say to say about the impor­tance of open source work:

[…] when I received the first job appli­ca­tion with a link to a code con­tri­bu­tion to an open source project, I imme­di­ate­ly fol­lowed the link, reviewed the code, invit­ed the can­di­date for an inter­view round, and even­tu­al­ly made an offer. A link to a code con­tri­bu­tion to an open source project is a great dif­fer­en­tia­tor in a job appli­ca­tion, in par­tic­u­lar when you have to select among a large num­ber of appli­ca­tions.”

Open source soft­ware devel­op­ment has long become com­mer­cial. By con­ser­v­a­tive esti­mates, more than 60% of a recent release of the Lin­ux Ker­nel was devel­oped by soft­ware devel­op­ers on com­pa­ny time [3]. Anoth­er study, look­ing at when soft­ware devel­op­ment work is being per­formed, found that about 50% of all code con­tri­bu­tions are being per­formed Mon­day to Fri­day, 9am to 5pm, sug­gest­ing paid work [10]. This arti­cle describes the impact that the increased com­mer­cial­iza­tion of open source is hav­ing on soft­ware devel­op­er careers.

The vast major­i­ty of well-working open source projects are community-owned open source projects [11] as opposed to vendor-owned open source projects. Exam­ples of com­mu­ni­ty projects are the Apache web server, the Fire­fox web browser, and any num­ber of less well-known projects. Com­mu­ni­ty open source soft­ware is embed­ded in near­ly all com­mer­cial­ly rel­e­vant soft­ware today, whether it is open or closed soft­ware. Thus, most soft­ware prod­ucts today build on com­mu­ni­ty open source soft­ware like the Apache web tech­nol­o­gy stack.

The impor­tance of open source for inno­va­tion and the soft­ware indus­try can­not be under­es­ti­mat­ed: The­se days, it takes lit­tle mon­ey for a start-up to get a first pro­to­type off the ground as most soft­ware and ser­vices it needs are read­i­ly avail­able for free. This is demon­strat­ed by the rapid growth of Sonatype’s Cen­tral Repos­i­to­ry for Java open source com­po­nents, which served near­ly 8 bil­lion open source com­po­nents requests in 2012. With this depen­dence on open source soft­ware, com­pa­nies increas­ing­ly need and want to influ­ence the direc­tion that this soft­ware is tak­ing. Soft­ware devel­op­ers in impor­tant posi­tions of eco­nom­i­cal­ly rel­e­vant open source projects are high­ly sought after.

This arti­cle intro­duces the con­cept of an open source soft­ware devel­op­er career and ana­lyzes its impli­ca­tions. It finds that open source soft­ware devel­op­ers with appro­pri­ate sta­tus can enjoy high­er salaries, high­er job secu­ri­ty, and a richer job expe­ri­ence. The ben­e­fits that open source soft­ware devel­op­ers expe­ri­ence over tra­di­tion­al soft­ware devel­op­ers fol­low from three key sig­nals: ver­i­fi­able skills, peer-certified com­pe­ten­cies, and posi­tion­al pow­er. At the same time, the arti­cle sug­gests that open source lev­els the play­ing field and reduces bar­ri­ers to labor mar­ket entry, mak­ing life more dif­fi­cult for soft­ware devel­op­ers with­out any par­tic­u­lar open source com­pe­tence or posi­tion.

An open source career does not have to be inde­pen­dent of a tra­di­tion­al career. More often than not, it enhances a tra­di­tion­al cor­po­rate career and pro­vides new oppor­tu­ni­ties to the devel­op­er.

This arti­cle makes the fol­low­ing con­tri­bu­tions:

  • It sum­ma­rizes well-known mod­els of open source career stages and sim­pli­fies them with­out loos­ing expres­sive pow­er;
  • It extends pri­or work on the rel­e­vant eco­nom­ic sig­nals that open source activ­i­ties cre­ate: ver­i­fi­able skills, peer-certified com­pe­ten­cies, and posi­tion­al pow­er;
  • It sug­gests a new effect cre­at­ed by open source, reduced bar­ri­ers to enter­ing the devel­op­er labor mar­ket, and it dis­cuss­es its pos­si­ble impli­ca­tions.

The arti­cle is based on prac­ti­tion­er inter­views we held in 2011-12 [8]. The arti­cle also sup­ports its argu­ments by build­ing on the appro­pri­ate research lit­er­a­ture. The argu­ments are illus­trat­ed by quo­ta­tions from open source prac­ti­tion­ers. Quo­ta­tions are pro­vid­ed in-line and were con­firmed by email by the author of this arti­cle.

The arti­cle is struc­tured as fol­lows. Sec­tion 2 reviews open source career mod­els and their unique and dis­tin­guish­ing char­ac­ter­is­tics. Sec­tion 3 dis­cuss­es the eco­nom­ic val­ue of open source devel­op­ment work and asso­ci­at­ed sta­tus. Relat­ed work, to the extent avail­able, is mixed into the respec­tive sec­tions. Sec­tion 4 spec­u­lates about fur­ther impli­ca­tions on the labor mar­ket and Sec­tion 5 con­cludes the paper.

2. The Open Source Developer Career

In a tra­di­tion­al soft­ware devel­op­er career, a devel­op­er, upon enter­ing the labor mar­ket, may find employ­ment at some com­pa­ny. A mature com­pa­ny defines a career lad­der for the devel­op­er, where a step for­ward on that lad­der typ­i­cal­ly implies increas­ing senior­i­ty, pow­er, and salary for the devel­op­er. The devel­op­er may then embark on tak­ing steps on this lad­der in the course of his or her pro­fes­sion­al life. Next to hav­ing a tech­ni­cal career, the devel­op­er may switch into an engi­neer­ing man­age­ment, pro­duct man­age­ment, or oth­er career.

Qui­et­ly, open source soft­ware has defined its own career lad­der for soft­ware devel­op­ers. Here, the steps or stages on the career lad­der are defined based on the sta­tus the devel­op­er enjoys in one or more open source projects. A tra­di­tion­al cor­po­rate and an open source career are not mutu­al­ly exclu­sive. If done right, they sup­port each oth­er.

2.1 The Basic Open Source Career

In its basic form, a devel­op­er may first be a user-consumer, then a con­trib­u­tor, and final­ly a com­mit­ter to an open source project, see Fig­ure 1.

Fig­ure 1. A sim­ple career mod­el (left), mapped into from the Onion Mod­el (mid­dle),
detailed by Behlendorf’s project immi­gra­tion illus­tra­tion (right).
  • A user-consumer is some­one who uses the soft­ware (either as an end-user or a devel­op­er, who builds on the soft­ware),
  • a con­trib­u­tor is some­one who makes a con­tri­bu­tion, for exam­ple, pro­vides a bug report or sub­mits some patch (code), and
  • a com­mit­ter is some­one who decides about oth­er people’s con­tri­bu­tions for inclu­sion in the project.

User-consumer, con­trib­u­tor, and com­mit­ter are roles that peo­ple play, and they accu­mu­late. Typ­i­cal­ly, a com­mit­ter is also a con­trib­u­tor and a user, and a con­trib­u­tor is also a user.

Anoth­er mod­el that has been used to describe the open source career is the Onion Mod­el [4]. The Onion Mod­el is ulti­mate­ly a project immi­gra­tion mod­el, which cap­tures how peo­ple move from being unre­lat­ed into the periph­ery into the core of the project, sim­i­lar­ly to hav­ing a career with the project. Behlen­dorf illus­trates such a process in mul­ti­ple steps [1] and Jensen and Scac­ci describe the mod­el as a com­plex role migra­tion process [7]. The Onion Mod­el is struc­tural­ly equiv­a­lent to the min­i­mal career mod­el pro­posed by the arti­cle and repeat­ed here. For exam­ple, roles like bug reporter, bug fix­er, periph­er­al devel­op­er and active devel­op­er (with­out com­mit rights) are sub­sumed by the con­trib­u­tor role.

For the pur­pos­es of ana­lyz­ing the career lad­der, this arti­cle focus­es on for­mal sta­tus with­in the project and the asso­ci­at­ed pow­er, specif­i­cal­ly the pow­er to deter­mine con­tent, scope, and direc­tion of the project as the defin­ing cri­te­ria for career stages.

In open source projects, any­one can be a user. The soft­ware is free to be used.

Any­one, who makes a con­tri­bu­tion to a project, for exam­ple, by report­ing a bug or sub­mit­ting a patch, can become a con­trib­u­tor. Some­one becomes a con­trib­u­tor if the con­tri­bu­tion is accept­ed by the project. This is not guar­an­teed; many patch­es sub­mis­sions or pull requests (code con­tri­bu­tions) are reject­ed because they don’t fit the project [13]. Achiev­ing con­trib­u­tor sta­tus is an implic­it pro­mo­tion with lit­tle ado; nobody real­ly takes notice except for the con­trib­u­tor. Both roles, user and con­trib­u­tor, come with lit­tle pow­er. In par­tic­u­lar, both user and con­trib­u­tors may only ask that the project may make par­tic­u­lar choic­es, for exam­ple, add func­tion­al­i­ty or choose par­tic­u­lar sup­port­ing tech­nol­o­gy.

This is dif­fer­ent for the third role, the com­mit­ter role. Com­mit­ters are typ­i­cal­ly project lead­ers. “Com­mit­ters” are named this way, because achiev­ing this sta­tus tra­di­tion­al­ly meant that the “com­mit bit” was being set to true for their user account in the con­fig­u­ra­tion man­age­ment sys­tem (code repos­i­to­ry) of the project. With a com­mit bit set to true, the then-committer can make changes to the code base with­out hav­ing to ask any­one for per­mis­sion. Thus, the com­mit bit, being equiv­a­lent to hav­ing write rights, is a sig­ni­fier of pow­er. Users and con­trib­u­tors can­not write to the code repos­i­to­ry; their com­mit bit has not been set. All they can do is read, they can­not write. A com­mit­ter decides whether to include a contributor’s patch sub­mis­sions or pull request into the project: qual­i­ty assur­ance and pow­er rolled into one.

Mov­ing from con­trib­u­tor to com­mit­ter sta­tus is an impor­tant step in the career of an open source soft­ware devel­op­er. Most mature projects don’t provide com­mit sta­tus light­ly; it is only pro­vid­ed to peo­ple after they have proved their loy­al­ty to the project, typ­i­cal­ly by pro­longed activ­i­ty as a con­trib­u­tor. The deci­sion to award some­one com­mit­ter sta­tus is con­sid­ered an impor­tant deci­sion; sig­nif­i­cant delib­er­a­tion goes into it. Typ­i­cal­ly, the exist­ing set of com­mit­ters dis­cuss­es a pro­posed new committer’s mer­its and ulti­mate­ly votes on whether to make him or her one of their own. For exam­ple, the Apache Soft­ware Foun­da­tion or the Eclipse Foun­da­tion have cod­i­fied the com­mit­ter elec­tion process to a great extent, imply­ing the impor­tance of this deci­sion. Once the deci­sion has been made, it is announced pub­licly, some­times with great fan­fare.

The advent of decen­tral­ized con­fig­u­ra­tion man­age­ment sys­tems and asso­ci­at­ed ser­vices, most notably GitHub’s GitHub and Atlassian’s Bit­buck­et ser­vices, has been chang­ing the col­lab­o­ra­tion pat­terns in soft­ware devel­op­ment projects. It is also sharp­en­ing the def­i­n­i­tion of what it means to be a com­mit­ter, away from the arcane “some­one with the com­mit bit set” to some­thing best described as “the trust­ed source (code repos­i­to­ry) for a project”. The tra­di­tion­al contributor-to-committer career step, how­ev­er, remains an impor­tant event in a project, in par­tic­u­lar in those projects that are run by open source foun­da­tions, see below.

Thus, the com­mit­ters are the lead­ers of a par­tic­u­lar project and they deter­mine its direc­tion. They per­form impor­tant qual­i­ty assur­ance work and they have sig­nif­i­cant pow­er in ral­ly­ing con­trib­u­tors around the project goals and to moti­vate them to pick up devel­op­ment work.

2.2 The Extended Open Source Career

The increas­ing com­mer­cial­iza­tion of open source has extend­ed the open source career beyond the com­mit­ter sta­tus in a given project. Specif­i­cal­ly, open source foun­da­tions as means of how com­mer­cial­ly rel­e­vant com­mu­ni­ty open source soft­ware is being devel­oped have added stages and asso­ci­at­ed sta­tus.

Open source foun­da­tions were cre­at­ed to ensure the sta­bil­i­ty of eco­nom­i­cal­ly rel­e­vant open source projects, that they are clean in terms of intel­lec­tu­al prop­er­ty, and that they evolve in a col­lab­o­ra­tive­ly nego­ti­at­ed way [12]. They also pro­tect devel­op­ers and projects from legal chal­lenges.

In open source foun­da­tions, devel­op­ers with com­mit­ter sta­tus can join project man­age­ment com­mit­tees, become their lead­er, and even become foun­da­tion mem­bers [7]. Fig­ure 2 illus­trates the­se addi­tion­al stages.

Fig­ure 2: Illus­tra­tion of an extend­ed career mod­el with­in an open source foun­da­tion.

Before the open source foun­da­tions arrived, open source projects were inde­pen­dent of each oth­er and no for­mal body of author­i­ty exist­ed to coor­di­nate them. Open source foun­da­tions arrived to coor­di­nate mul­ti­ple pre­vi­ous­ly inde­pen­dent projects and to start new projects, because of the inter­de­pen­den­cies between the projects. The Apache Soft­ware Foun­da­tion, the Eclipse Foun­da­tion, and the Mozil­la Foun­da­tion all coor­di­nate many dif­fer­ent projects under their hoods to ensure that the­se projects work togeth­er well to form one or more viable soft­ware plat­forms.

Justin Erenkrantz, a for­mer pres­i­dent of the Apache Soft­ware Foun­da­tion (ASF), remarks:

At the ASF, mem­bers of the Project Man­age­ment Com­mit­tee are recruit­ed from the project con­trib­u­tors. As the rec­og­nized stew­ards of the project, all PMC mem­bers (includ­ing the appoint­ed chair) wield sig­nif­i­cant pow­er over the project through the pow­er of the veto. […]”

With mul­ti­ple projects in need of coor­di­na­tion, addi­tion­al career steps were cre­at­ed. Foun­da­tions first split the tra­di­tion­al com­mit­ter role into two: The orig­i­nal com­mit­ter role, in which a devel­op­er reviews con­tri­bu­tions and puts them into the code repos­i­to­ry, and a man­age­ment role, in which a devel­op­er par­tic­i­pates in deter­min­ing the roadmap of the project. The man­age­ment role is being played as a mem­ber of the project’s man­age­ment com­mit­tee, of which a devel­op­er can become the lead­er; some­times there are sev­er­al lead­ers.

The details of the­se final steps in an open source career vary by foun­da­tion, because the num­ber of peo­ple who can take them is lim­it­ed. What they sig­ni­fy, how­ev­er, is the increas­ing pow­er and influ­ence of the per­son tak­ing them. While in the basic career mod­el a devel­op­er in the final com­mit­ter stage may deter­mine a sin­gle project’s direc­tion, in the extend­ed career mod­el, a devel­op­er in the final foun­da­tion mem­ber stage may not only help deter­mine a sin­gle project’s direc­tion, but that of a whole indus­try plat­form.

3. Signals of Open Source Status

The activ­i­ties of an open source soft­ware devel­op­er sig­nal his or her com­pe­ten­cies and sta­tus to prospec­tive employ­ers. From this, three forms of com­pet­i­tive advan­tage when look­ing for a job emerge:

  • Ver­i­fi­able claims to tech­ni­cal skills
  • Peer-certified social and tech­ni­cal com­pe­ten­cies
  • Posi­tion of pow­er for a given project

The fol­low­ing sec­tions look at the­se advan­tages in turn.

3.1 Verifiable Claims to Technical Skills

An open source soft­ware devel­op­er per­forms pub­lic work, for every­one to see. This cre­ates the fol­low­ing sig­nals:

  1. Demon­strat­ed tech­ni­cal skills inde­pen­dent­ly of a par­tic­u­lar project. Sim­ply by work­ing in the pub­lic eye, a devel­op­er is show­ing their skills and is doc­u­ment­ing them for who­ev­er may want to take a look [9]. This is in con­trast to work on closed source which nobody out­side the employ­ing com­pa­ny can see.
  2. Demon­strat­ed tech­ni­cal skills for a par­tic­u­lar project. In addi­tion to gen­er­al pub­licly per­formed work, the devel­op­er is demon­strat­ing their skills for a speci­fic project at hand. Not only is a devel­op­er gen­er­al­ly com­pe­tent, they are specif­i­cal­ly and demon­stra­bly com­pe­tent for the project at hand.

A hir­ing man­ager can go to the project’s web­site and see for them­selves how good a par­tic­u­lar devel­op­er real­ly is. This is not pos­si­ble for a tra­di­tion­al soft­ware devel­op­er whose tech­ni­cal work is hid­den behind pri­or employ­ers’ fire­walls.

Chris DiBona, Direc­tor of Google’s Open Source Pro­grams, has this to say:

Open source soft­ware is strate­gic to Google, and nat­u­ral­ly we hire a great num­ber of open source devel­op­ers. Some­one who demon­strates their abil­i­ty by con­tribut­ing to open source projects shows that they are able to code in the real world in ways oth­er devel­op­ers can not read­i­ly match. It’s the ulti­mate refer­ral.”

A host of web­sites and ser­vices have sprung up that make assess­ing a developer’s rep­u­ta­tion and pub­lic open source work easy: For exam­ple, Black Duck Software’s pro­vides a com­pre­hen­sive assess­ment of a soft­ware developer’s open source activ­i­ties and how oth­er devel­op­ers relate to him or her.

3.2 Peer-Certified Social and Technical Competencies

A well-working open source project of non-trivial size val­i­dates a developer’s com­pe­ten­cies by mak­ing him or her one of their own. The project is “peer-certifying” a devel­op­er.

  1. Peer-certified tech­ni­cal skills for a speci­fic project and inde­pen­dent­ly of it. The demon­strat­ed tech­ni­cal skills, whether for a speci­fic project or inde­pen­dent of it, become par­tic­u­lar­ly valu­able if the work is accept­ed for incor­po­ra­tion into an exist­ing project. (This is the step from user to con­trib­u­tor.)

Now, the devel­op­er is not only per­form­ing pub­lic work, but oth­er devel­op­ers, the exist­ing com­mit­ters of the project, have eval­u­at­ed the work as being good enough for inclu­sion in the project. Exist­ing com­mit­ters have a long-term inter­est in the project and typ­i­cal­ly only accept con­tri­bu­tions if they meet their qual­i­ty stan­dards.

Thus, a devel­op­er who finds their work accept­ed into an open source project there­by receives a seal of approval (“peer cer­ti­fi­ca­tion”) of their com­pe­tence by a group of oth­er devel­op­ers, the com­mit­ters, who care deeply about the qual­i­ty of this work.

  1. Peer-certified social skills to work in a team and get along with peo­ple. If a con­trib­u­tor receives a vote of trust and is pro­mot­ed to com­mit­ter sta­tus, the exist­ing team of com­mit­ters cer­ti­fy that the devel­op­er can work in a team and that they would like him or her to join them.

If they would find the per­son to be dis­agree­able, they would not pro­mote him or her, as the con­se­quences for the project could be dire. Thus, achiev­ing com­mit­ter sta­tus in a non-trivial project is a mea­sure of a developer’s social skills to get a long and work effec­tive­ly in a team.

  1. Peer-certified lead­er­ship skills. A devel­op­er who becomes a com­mit­ter or bet­ter yet a mem­ber of a project man­age­ment com­mit­tee sig­nals that they are seen as a lead­er of the project. The exist­ing com­mit­ters trust him or her to lead oth­er peo­ple and inspire them to keep work­ing on the project.

Robert O’Callahan, a dis­tin­guished engi­neer at the Mozil­la cor­po­ra­tion, com­ments:

Open source con­trib­u­tors tend to believe in and prac­tice the val­ues that char­ac­ter­ize suc­cess­ful open source projects, such as com­mu­ni­ty, mer­i­toc­ra­cy and trans­par­ent gov­ern­ment. Hir­ing those peo­ple strength­ens those val­ues with­in your cor­po­rate cul­ture.”

Thus, hir­ing open source devel­op­ers can also be a means for chang­ing to or strength­en­ing cor­po­rate val­ues of open col­lab­o­ra­tive soft­ware devel­op­ment. Such open col­lab­o­ra­tive devel­op­ment is not only applic­a­ble to open source soft­ware devel­op­ment but also to firm-internal soft­ware devel­op­ment, where it can help tear down devel­op­ment silos (called “inner source” then) [5].

3.3 Position of Power and Influence

In addi­tion to demon­strat­ing com­pe­ten­cies and find­ing them val­i­dat­ed by a peer group, achiev­ing sta­tus in open source projects cre­ates addi­tion­al ben­e­fits.

  1. Posi­tion of pow­er and influ­ence. With com­mit­ter sta­tus or beyond, a devel­op­er receives sig­nif­i­cant for­mal pow­er. Not only can they put code into the project with­out peer review, they can influ­ence tone, con­tent, and direc­tion of the project. Com­mit­ters set the strate­gic char­ter of a project, includ­ing archi­tec­ture deci­sions.

Such pow­er and influ­ence can be used in many ways. It can be used pos­i­tive­ly by lead­ing and inspir­ing in a col­lab­o­ra­tive way and it can be used strate­gi­cal­ly and com­mer­cial­ly, for exam­ple, by keep­ing the com­pe­ti­tion out of the open source project by reject­ing them for com­mit­ter sta­tus.

  1. Vis­i­bil­i­ty to com­mu­ni­ty and beyond. With the com­mit­ter sta­tus comes vis­i­bil­i­ty and out­reach abil­i­ty to the project com­mu­ni­ty and oth­er inter­est­ed par­ties. The com­mit­ter may become a voice of the project. He or she may get invit­ed to pub­lish about the project or speak at con­fer­ences.

4. Economic Value of Signals

The­se sig­nals about soft­ware devel­op­ment com­pe­ten­cies as well as project pow­er and influ­ences can be picked up eas­i­ly by com­pa­nies, as all the­se sig­nals are pub­lic. They change the nego­ti­a­tion pow­er between job seek­er and prospec­tive employ­er.

In hir­ing sit­u­a­tions for devel­op­er posi­tions at com­pa­nies, open source soft­ware devel­op­ers have an advan­tage over devel­op­ers with­out pub­licly dis­played work. The sig­nals men­tioned above can lead to

  • a high­er salary,
  • high­er job secu­ri­ty, and
  • a richer job expe­ri­ence.

Of the­se ben­e­fits, the high­er salary has been empir­i­cal­ly val­i­dat­ed for Apache Soft­ware foun­da­tion com­mit­ters by Hahn et al. [6], though Bitzer et al. found no such increase when look­ing at a broad array of most­ly non-commercially-relevant open source projects [2].

4.1 Value of Verifiable Claims

A high­er salary is a con­se­quence of the reduced uncer­tain­ty in job inter­views. A hir­ing man­ager or engi­neer­ing man­ager, who can look at sus­tained pub­lic open source work of a job appli­cant, can gain high­er cer­tain­ty as to that person’s tech­ni­cal skills. This increased cer­tain­ty reduces the uncer­tain­ty dis­count that is present in all salary nego­ti­a­tions.

Marten Mick­os, CEO of Euca­lyp­tus (and for­mer CEO of MySQL), points out:

From a soft­ware vendor’s per­spec­tive, open source work on a developer’s resume is a defin­i­tive plus. It shows that the devel­op­er has a gen­uine pas­sion for writ­ing soft­ware and a lev­el of self-confidence that’s use­ful to us. […] If the devel­op­er even con­tribut­ed to our [open source] prod­ucts, it increas­es their chance of being suc­cess­ful at our com­pa­ny: Ramp-up time will be short­er and we know they are like­ly to be a bet­ter fit than an unknown devel­op­er. All of this leads us to prefer open source devel­op­ers when hir­ing.”

If the tech­ni­cal skills of the devel­op­er are for a project that has com­mer­cial val­ue for the employ­er, the developer’s nego­ti­a­tion posi­tion improves accord­ing­ly.

This val­ue accrues to any­one, be he or she a con­trib­u­tor, com­mit­ter, or PMC mem­ber. It is also by far the most com­mon val­ue extract­ed from open source work.

4.2 Value of Peer Certification

Any­one with com­mit­ter or PMC mem­ber sta­tus also gets peer-certified for their work, mak­ing their tech­ni­cal and social skills even more believ­able, fur­ther reduc­ing the hir­ing risk and improv­ing the nego­ti­a­tion posi­tion.

Rachel Chalmers of Igni­tion Part­ners, a Silicon-Valley-based bou­tique ven­ture cap­i­tal firm, finds the fol­low­ing val­ue in the pub­lic work that open source soft­ware devel­op­ers per­form:

When we look at a start-up, we look at the GitHub repos­i­to­ries, we look at We drill down to the lev­el of indi­vid­u­al devel­op­ers. It informs our invest­ment deci­sion. That fact alone gives open source soft­ware devel­op­ers sig­nif­i­cant lever­age when nego­ti­at­ing their posi­tion, salary, and ben­e­fits with start-ups.”

4.3 Value of Position of Power

If a devel­op­er has com­mit­ter sta­tus in an open source project that is com­mer­cial­ly rel­e­vant for the employ­er, for exam­ple, because the employer’s prod­ucts build on the project, then the employ­er can buy sev­er­al things by employ­ing the devel­op­er:

  1. Vis­i­bil­i­ty into what’s com­ing. A com­mit­ter is active­ly engaged in lead­ing the project and thus has unique insight into where it is head­ed. This is of strate­gic impor­tance for a com­pa­ny whose prod­ucts build on the project or a full (foundation-managed) plat­form.
  2. Influ­ence on the project. The com­mit­ter is in a posi­tion to per­form key work him or her­self, to chan­nel the company’s work into the project, and to lead and inspire out­side devel­op­ers to con­tribute in align­ment with the employer’s strate­gic goals.
  3. Increased employ­er attrac­tive­ness. The committer’s rep­u­ta­tion attracts oth­er devel­op­ers who want to work with him. Thus, his or her employ­er appears as more attrac­tive than oth­ers and may be sought after by oth­er com­pe­tent devel­op­ers.
  4. Good­will with the com­mu­ni­ty. The committer’s vis­i­bil­i­ty to the com­mu­ni­ty shi­nes a pos­i­tive light on his or her employ­er. Pay­ing the devel­op­er to work on the open source project cre­ates good­will with the com­mu­ni­ty.
  5. Com­pe­tence by asso­ci­a­tion. By employ­ing the com­mit­ter, the com­pa­ny acquires com­pe­tence in the project. The trust in the company’s prod­ucts and ser­vices increas­es to the extent that they are relat­ed to the open source project. This helps mar­ket­ing and sales of the­se ser­vices and prod­ucts.

This increased insight, influ­ence and vis­i­bil­i­ty are com­mer­cial­ly rel­e­vant for the com­pa­ny and hence afford the devel­op­er an improved nego­ti­a­tion posi­tion when it comes to salary and oth­er job con­di­tions.

Kai-Uwe Maet­zel, back then an IBM employ­ee and elect­ed direc­tor of the Eclipse Foun­da­tion (2005–2007) already remarked in 2003:

Com­pa­nies want to secure their influ­ence on the Eclipse plat­form, and one way of doing so is by employ­ing com­mit­ters to Eclipse projects. Increas­ing­ly, I see reg­u­lar devel­op­ers being hired with the goal of ‘mak­ing them com­mit­ter’ with­in a few months.”

When remind­ed of his remark for this arti­cle, Maet­zel, who has since left IBM to found his own com­pa­ny, Think­ing Owl, added:

My con­tri­bu­tions to the Eclipse project (2000–2007) result­ed in a high vis­i­bil­i­ty in the Eclipse affine devel­op­er com­mu­ni­ty. Pret­ty much every offer I received dur­ing the­se years from poten­tial employ­ers explic­it­ly referred to my rep­u­ta­tion in the Eclipse project.”

Com­mit­ters to open source projects of com­mer­cial rel­e­vance to an employ­er are like­ly to have high­er job secu­ri­ty as well. In hard times, the eco­nom­ic val­ue of the com­mit­ter posi­tion may be the one advan­tage that the com­mit­ter has over anoth­er non-committer employ­ees that may keep him or her from get­ting fired.

Com­mit­ters also have a richer job expe­ri­ence. The job require­ments are broad­er than those of a reg­u­lar devel­op­er. Not only is the devel­op­er expect­ed to per­form well with­in the com­pa­ny, he or she also may also be expect­ed to keep work­ing on the open source project, cre­at­ing added work con­text, require­ments, and expe­ri­ence.

5. A New Software Developer Labor Market?

A con­trib­u­tor posi­tion in an open source project is valu­able, but it is not scarce. Many peo­ple can become con­trib­u­tors and build a pub­lic rep­u­ta­tion and an open source resume. A com­mit­ter posi­tion is more scarce and leads to high­er rep­u­ta­tion and recog­ni­tion. At the high-end are com­mit­ters who are also mem­bers of project man­age­ment com­mit­tees (PMC). As a project matures and growth slows, it becomes more and more dif­fi­cult to join the ranks of com­mit­ters and PMC mem­bers, sim­ply because few­er such peo­ple are need­ed.

The labor mar­ket for devel­op­ing with and build­ing on open source com­po­nents has lit­tle or no bar­ri­ers to entry: The open source soft­ware is read­i­ly avail­able and typ­i­cal­ly many free edu­ca­tion­al mate­ri­als exist. Thus every­one who wish­es to join this labor mar­ket can do so with­out run­ning into finan­cial or edu­ca­tion­al bar­ri­ers.

Richard Seibt, pres­i­dent of the Open Source Busi­ness Foun­da­tion, points out:

With dimin­ish­ing bar­ri­ers to entry, every­one can con­tribute to open source and earn a liv­ing. Both soft­ware ven­dors and IT user firms are increas­ing­ly turn­ing to open source foun­da­tions as a means for orga­niz­ing soft­ware devel­op­ment. This pro­vides ample employ­ment oppor­tu­ni­ty for soft­ware devel­op­ers who are skilled in open source devel­op­ment.”

In con­trast, closed source soft­ware pro­tects the wealthy: To join the labor mar­ket for devel­op­ing with closed source soft­ware, a devel­op­er typ­i­cal­ly needs to pur­chase a license and par­tic­i­pate in com­mer­cial train­ings. Some­times, access is only pos­si­ble through a medi­at­ing employ­er. No or few such com­pli­ca­tions exist for open source soft­ware.

In addi­tion, open source and asso­ci­at­ed web ser­vices has facil­i­tat­ed the growth of end-user pro­gram­mers: Peo­ple with­out for­mal com­put­er sci­ence edu­ca­tion who are able to per­form light­weight pro­gram­ming tasks using script­ing lan­guages and per­form­ing web design. The­se peo­ple are enter­ing the labor mar­ket and are pro­vid­ing addi­tion­al com­pe­ti­tion for tra­di­tion­al devel­op­ers.

As more and more soft­ware prod­ucts build on open source com­po­nents, the impor­tance of the­se com­po­nents is only increas­ing. With no or lit­tle bar­ri­ers to enter­ing the labor mar­ket for the­se com­po­nents, wealthy soft­ware devel­op­ers may face more com­pe­ti­tion from less wealthy and less skilled devel­op­ers. Such com­pe­ti­tion was pre­vi­ous­ly not pos­si­ble due to the bar­ri­ers to enter­ing the labor mar­ket for the then-dominant closed source soft­ware.

Based on the­se obser­va­tions, the author of this arti­cle spec­u­lates that the soft­ware devel­op­ment labor mar­ket may split into two parts: Those who hold a posi­tion of pow­er in impor­tant open source projects and those who don’t. Those with impor­tant posi­tions will be bet­ter off while those who don’t have such a posi­tion will be worse off than before due to increased glob­al com­pe­ti­tion.

This pos­si­bly emerg­ing two-class soci­ety is at least in the­o­ry inde­pen­dent of where a devel­op­er grew up, because the Inter­net affords access to open source soft­ware to every­one. As a prac­ti­cal mat­ter, wealthy West­ern devel­op­ers got a head-start: They cre­at­ed the ecosys­tem and are accus­tomed to its col­lab­o­ra­tion val­ues. They also have the spare time and resources to get start­ed work­ing on open source. In relat­ed work we show that Asian coun­tries provide only a small per­cent­age of open source soft­ware [10]. It may take a gen­er­a­tion of Asian soft­ware devel­op­ers to over­come this West­ern head-start.

6. Conclusions

This arti­cle shows that par­tic­i­pat­ing in and lead­ing open source projects has tan­gi­ble ben­e­fits for soft­ware devel­op­ers. A sec­ond career lad­der is being cre­at­ed and tak­ing steps on it makes devel­op­ers more attrac­tive to employ­ers. Con­se­quences can be a high­er salary, high­er job secu­ri­ty, and a richer job expe­ri­ence. In relat­ed work, we dis­cuss the com­pe­ten­cies need­ed to become a suc­cess­ful open source soft­ware devel­op­er [8].

The­se ben­e­fits accrue from ver­i­fi­able skills, peer-certified com­pe­ten­cies and posi­tions of pow­er that open source projects afford devel­op­ers. The first two ben­e­fits can accrue to any­one who is active in open source, the third ben­e­fit typ­i­cal­ly requires being active in foundation-managed open source projects, as the­se are the indus­try plat­forms that employ­ers are focus­ing on most.

The sig­nif­i­cance of the­se find­ings is height­ened by the obser­va­tion that with increas­ing use of open source soft­ware in prod­ucts, the over­all devel­op­er labor mar­ket is becom­ing more com­pet­i­tive. Pre­vi­ous­ly, closed source soft­ware afford­ed wealthy West­ern devel­op­ers some pro­tec­tion from low-wage coun­tries, but this pro­tec­tion is fad­ing away to the extent that read­i­ly avail­able open source soft­ware is replac­ing closed source soft­ware.


I would like to thank Ann Bar­comb, Han­nes Dohrn, Kai-Uwe Maet­zel, Michael Max­im­i­lien and Robert O’Callahan for help­ing me improve this arti­cle. I also would like to thank Rachel Chalmers, Chris DiBona, Justin Erenkrantz, Kai-Uwe Maet­zel, Marten Mick­os, Robert O’Callahan and Richard Seibt for time­ly pro­vi­sion of quotes to illus­trate the impact of open source on the soft­ware devel­op­er career.


[1] Bin­stock, A. (2011). “How to Con­tribute to Open Source Projects.” Avail­able from
[2] Bitzer, J., et al. (2010). “Returns to Open Source Engage­ment: An Empir­i­cal Test of the Sig­nal­ing Hypoth­e­sis.” Old­en­burg Work­ing Papers, V-321–10. Uni­ver­si­ty of Old­en­burg: 2010.
[3] Cor­bet, J. et al. (2012). “Lin­ux Ker­nel Devel­op­ment – How fast it is going, who is doing it, what they are doing, and who is spon­sor­ing it?”, 2012. Avail­able from
[4] Crow­ston, K, and J. How­ison (2011). “The Social Struc­ture of Free and Open Source Soft­ware Devel­op­ment.” First Mon­day, vol. 10, no. 2.
[5] Dinkelack­er, J., et al. (2002). Pro­gres­sive open source. In Pro­ceed­ings of the 24th Inter­na­tion­al Con­fer­ence on Soft­ware Engi­neer­ing (pp. 177–184). ACM.
[6] Hann, I.H., et al. (2002). “Why do devel­op­ers con­tribute to open source projects? First evi­dence of eco­nom­ic incen­tives.” 2nd Work­shop on Open Source Soft­ware Engi­neer­ing, Orlan­do, FL. 2002.
[7] Jensen, C. and W. Scac­chi (2007). “Role Migra­tion and Advance­ment Process­es in OSSD Projects: A Com­par­a­tive Case Study.” 29th Inter­na­tion­al Con­fer­ence on Soft­ware Engi­neer­ing (ICSE 2007). IEEE Press, 2007, 364–375.
[8] Kim­mel­mann, N. (2014). “A Career in Open Source? Rel­e­vant Com­pe­ten­cies for Open Source Soft­ware Devel­op­ers.” it — Infor­ma­tion Tech­nol­o­gy, vol. 55, no. 5.
[9] Lern­er, J. and J. Tirole (2002). “Some Sim­ple Eco­nom­ics of Open Source.” Jour­nal of Indus­tri­al Eco­nom­ics, vol. 50, no. 2, pp. 197–234.
[10] Riehle, D., et al. (2014). “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.
[11] Riehle, D. (2007). “The Eco­nom­ic Moti­va­tion of Open Source: Stake­hold­er Per­spec­tives.” IEEE Com­put­er vol. 40, no. 4 (April 2007), 25–32.
[12] Riehle, D. (2010). The Eco­nom­ic Case for Open Source Foun­da­tions. IEEE Com­put­er vol. 43, no. 1 (Jan­u­ary 2010), 86–90.
[13] Weißger­ber, P., et al. (2008). “Small patch­es get in!” In Pro­ceed­ings of the 2008 Inter­na­tion­al Work­ing Con­fer­ence on Min­ing Soft­ware Repos­i­to­ries, 67–76.


Prof. Dr. Dirk Riehle, M.B.A., is the Pro­fes­sor of Open Source Soft­ware at the Friedrich-Alexander Uni­ver­si­ty of Erlangen-Nürnberg. Before join­ing acad­e­mia, Riehle led the Open Source Research Group at SAP Labs, LLC, in Palo Alto, Cal­i­for­nia (Sil­i­con Val­ley). Riehle found­ed the Wiki Sym­po­sium, and more recent­ly, the Open Sym­po­sium, now the joint inter­na­tion­al con­fer­ence on open col­lab­o­ra­tion. He was also the lead archi­tect of the first UML vir­tu­al machine. He is inter­est­ed in open source and inner source soft­ware engi­neer­ing, agile soft­ware devel­op­ment meth­ods, com­plex­i­ty sci­ence and human col­lab­o­ra­tion, and soft­ware sys­tem archi­tec­ture, design, and imple­men­ta­tion. Prof. Riehle holds a Ph.D. in com­put­er sci­ence from ETH Zürich and an M.B.A. from Stan­ford Grad­u­ate School of Busi­ness. He is a mem­ber of the ACM, the IEEE, and the GI (Ger­man Infor­mat­ics Soci­ety), among oth­ers. He wel­comes email at, blogs at, and tweets as @dirkriehle.

2 thoughts on “The Open Source Software Developer Career and Its Benefits

  1. Rahul Mishra

    Open Source has its ben­e­fits and con­se­quences…
    I am a soft­ware devel­op­er, but i aspire to be a suc­cess­ful open source devel­op­er.
    Can you sug­gest some­thing, where to start? which sites to fol­low? whom to refer?

  2. Mohammad

    Start by con­tribut­ing to exist­ing projects. Just search on the inter­net to see which one is of your inter­est. Self Moti­va­tion should be there so try to find a good rea­son to moti­vates you along the way to work on that project. Con­tri­bu­tion can be sim­ply learn­ing the soft­ware and post­ing ques­tions into the mail­ing list and lat­er on you will learn “col­lab­o­ra­tion”. Then start going to the next lev­el, Local­ize soft­ware, Or sug­gest a new fea­ture… If you can go up to that lev­el you don’t need me to tell you what to do next. You already know the next step. Good luck.


Leave a Reply