Please note: This is the original of a copy-edited article that appeared in IEEE Computer in May of 2015. See here for the official publication, including a PDF.
Dirk Riehle, email@example.com, https://dirkriehle.com
Professur für Open-Source-Software, Computer Science Department
Friedrich-Alexander Universität Erlangen-Nürnberg
Open source software development is changing the labor market for software developers. Benefits of participation in open source projects can be increased salaries and improved job security. Three forms of competitive advantage have emerged: verifiable technical skills, peer-certified competencies and positional power. These competitive advantages strengthen a developer’s negotiation power towards a prospective employer. Software developers, hiring managers, and personnel departments of companies relying on open source in their software development need to understand this new reality to effectively hire developers and work with associated open source projects.
Open source; inner source; open source foundations; open source committer; software developer career; software developer competencies; software economics; IT labor economics; software labor market; IT labor market; software industry, IT industry
Table of Contents
2. The Open Source Developer Career
3. Signals of Open Source Status
5. A New Software Developer Labor Market?
Erich Gamma is a 2011 winner of the ACM software systems award, which he received for his work on the open source Eclipse platform. When reflecting on hiring software developers, he had this to say to say about the importance of open source work:
“[…] when I received the first job application with a link to a code contribution to an open source project, I immediately followed the link, reviewed the code, invited the candidate for an interview round, and eventually made an offer. A link to a code contribution to an open source project is a great differentiator in a job application, in particular when you have to select among a large number of applications.”
Open source software development has long become commercial. By conservative estimates, more than 60% of a recent release of the Linux Kernel was developed by software developers on company time . Another study, looking at when software development work is being performed, found that about 50% of all code contributions are being performed Monday to Friday, 9am to 5pm, suggesting paid work . This article describes the impact that the increased commercialization of open source is having on software developer careers.
The vast majority of well-working open source projects are community-owned open source projects  as opposed to vendor-owned open source projects. Examples of community projects are the Apache web server, the Firefox web browser, and any number of less well-known projects. Community open source software is embedded in nearly all commercially relevant software today, whether it is open or closed software. Thus, most software products today build on community open source software like the Apache web technology stack.
The importance of open source for innovation and the software industry cannot be underestimated: These days, it takes little money for a start-up to get a first prototype off the ground as most software and services it needs are readily available for free. This is demonstrated by the rapid growth of Sonatype’s Central Repository for Java open source components, which served nearly 8 billion open source components requests in 2012. With this dependence on open source software, companies increasingly need and want to influence the direction that this software is taking. Software developers in important positions of economically relevant open source projects are highly sought after.
This article introduces the concept of an open source software developer career and analyzes its implications. It finds that open source software developers with appropriate status can enjoy higher salaries, higher job security, and a richer job experience. The benefits that open source software developers experience over traditional software developers follow from three key signals: verifiable skills, peer-certified competencies, and positional power. At the same time, the article suggests that open source levels the playing field and reduces barriers to labor market entry, making life more difficult for software developers without any particular open source competence or position.
An open source career does not have to be independent of a traditional career. More often than not, it enhances a traditional corporate career and provides new opportunities to the developer.
This article makes the following contributions:
- It summarizes well-known models of open source career stages and simplifies them without loosing expressive power;
- It extends prior work on the relevant economic signals that open source activities create: verifiable skills, peer-certified competencies, and positional power;
- It suggests a new effect created by open source, reduced barriers to entering the developer labor market, and it discusses its possible implications.
The article is based on practitioner interviews we held in 2011-12 . The article also supports its arguments by building on the appropriate research literature. The arguments are illustrated by quotations from open source practitioners. Quotations are provided in-line and were confirmed by email by the author of this article.
The article is structured as follows. Section 2 reviews open source career models and their unique and distinguishing characteristics. Section 3 discusses the economic value of open source development work and associated status. Related work, to the extent available, is mixed into the respective sections. Section 4 speculates about further implications on the labor market and Section 5 concludes the paper.
2. The Open Source Developer Career
In a traditional software developer career, a developer, upon entering the labor market, may find employment at some company. A mature company defines a career ladder for the developer, where a step forward on that ladder typically implies increasing seniority, power, and salary for the developer. The developer may then embark on taking steps on this ladder in the course of his or her professional life. Next to having a technical career, the developer may switch into an engineering management, product management, or other career.
Quietly, open source software has defined its own career ladder for software developers. Here, the steps or stages on the career ladder are defined based on the status the developer enjoys in one or more open source projects. A traditional corporate and an open source career are not mutually exclusive. If done right, they support each other.
2.1 The Basic Open Source Career
In its basic form, a developer may first be a user-consumer, then a contributor, and finally a committer to an open source project, see Figure 1.
Figure 1. A simple career model (left), mapped into from the Onion Model (middle),
detailed by Behlendorf’s project immigration illustration (right).
- A user-consumer is someone who uses the software (either as an end-user or a developer, who builds on the software),
- a contributor is someone who makes a contribution, for example, provides a bug report or submits some patch (code), and
- a committer is someone who decides about other people’s contributions for inclusion in the project.
User-consumer, contributor, and committer are roles that people play, and they accumulate. Typically, a committer is also a contributor and a user, and a contributor is also a user.
Another model that has been used to describe the open source career is the Onion Model . The Onion Model is ultimately a project immigration model, which captures how people move from being unrelated into the periphery into the core of the project, similarly to having a career with the project. Behlendorf illustrates such a process in multiple steps  and Jensen and Scacci describe the model as a complex role migration process . The Onion Model is structurally equivalent to the minimal career model proposed by the article and repeated here. For example, roles like bug reporter, bug fixer, peripheral developer and active developer (without commit rights) are subsumed by the contributor role.
For the purposes of analyzing the career ladder, this article focuses on formal status within the project and the associated power, specifically the power to determine content, scope, and direction of the project as the defining criteria for career stages.
In open source projects, anyone can be a user. The software is free to be used.
Anyone, who makes a contribution to a project, for example, by reporting a bug or submitting a patch, can become a contributor. Someone becomes a contributor if the contribution is accepted by the project. This is not guaranteed; many patches submissions or pull requests (code contributions) are rejected because they don’t fit the project . Achieving contributor status is an implicit promotion with little ado; nobody really takes notice except for the contributor. Both roles, user and contributor, come with little power. In particular, both user and contributors may only ask that the project may make particular choices, for example, add functionality or choose particular supporting technology.
This is different for the third role, the committer role. Committers are typically project leaders. “Committers” are named this way, because achieving this status traditionally meant that the “commit bit” was being set to true for their user account in the configuration management system (code repository) of the project. With a commit bit set to true, the then-committer can make changes to the code base without having to ask anyone for permission. Thus, the commit bit, being equivalent to having write rights, is a signifier of power. Users and contributors cannot write to the code repository; their commit bit has not been set. All they can do is read, they cannot write. A committer decides whether to include a contributor’s patch submissions or pull request into the project: quality assurance and power rolled into one.
Moving from contributor to committer status is an important step in the career of an open source software developer. Most mature projects don’t provide commit status lightly; it is only provided to people after they have proved their loyalty to the project, typically by prolonged activity as a contributor. The decision to award someone committer status is considered an important decision; significant deliberation goes into it. Typically, the existing set of committers discusses a proposed new committer’s merits and ultimately votes on whether to make him or her one of their own. For example, the Apache Software Foundation or the Eclipse Foundation have codified the committer election process to a great extent, implying the importance of this decision. Once the decision has been made, it is announced publicly, sometimes with great fanfare.
The advent of decentralized configuration management systems and associated services, most notably GitHub’s GitHub and Atlassian’s Bitbucket services, has been changing the collaboration patterns in software development projects. It is also sharpening the definition of what it means to be a committer, away from the arcane “someone with the commit bit set” to something best described as “the trusted source (code repository) for a project”. The traditional contributor-to-committer career step, however, remains an important event in a project, in particular in those projects that are run by open source foundations, see below.
Thus, the committers are the leaders of a particular project and they determine its direction. They perform important quality assurance work and they have significant power in rallying contributors around the project goals and to motivate them to pick up development work.
2.2 The Extended Open Source Career
The increasing commercialization of open source has extended the open source career beyond the committer status in a given project. Specifically, open source foundations as means of how commercially relevant community open source software is being developed have added stages and associated status.
Open source foundations were created to ensure the stability of economically relevant open source projects, that they are clean in terms of intellectual property, and that they evolve in a collaboratively negotiated way . They also protect developers and projects from legal challenges.
In open source foundations, developers with committer status can join project management committees, become their leader, and even become foundation members . Figure 2 illustrates these additional stages.
Figure 2: Illustration of an extended career model within an open source foundation.
Before the open source foundations arrived, open source projects were independent of each other and no formal body of authority existed to coordinate them. Open source foundations arrived to coordinate multiple previously independent projects and to start new projects, because of the interdependencies between the projects. The Apache Software Foundation, the Eclipse Foundation, and the Mozilla Foundation all coordinate many different projects under their hoods to ensure that these projects work together well to form one or more viable software platforms.
Justin Erenkrantz, a former president of the Apache Software Foundation (ASF), remarks:
“At the ASF, members of the Project Management Committee are recruited from the project contributors. As the recognized stewards of the project, all PMC members (including the appointed chair) wield significant power over the project through the power of the veto. […]”
With multiple projects in need of coordination, additional career steps were created. Foundations first split the traditional committer role into two: The original committer role, in which a developer reviews contributions and puts them into the code repository, and a management role, in which a developer participates in determining the roadmap of the project. The management role is being played as a member of the project’s management committee, of which a developer can become the leader; sometimes there are several leaders.
The details of these final steps in an open source career vary by foundation, because the number of people who can take them is limited. What they signify, however, is the increasing power and influence of the person taking them. While in the basic career model a developer in the final committer stage may determine a single project’s direction, in the extended career model, a developer in the final foundation member stage may not only help determine a single project’s direction, but that of a whole industry platform.
3. Signals of Open Source Status
The activities of an open source software developer signal his or her competencies and status to prospective employers. From this, three forms of competitive advantage when looking for a job emerge:
- Verifiable claims to technical skills
- Peer-certified social and technical competencies
- Position of power for a given project
The following sections look at these advantages in turn.
3.1 Verifiable Claims to Technical Skills
An open source software developer performs public work, for everyone to see. This creates the following signals:
- Demonstrated technical skills independently of a particular project. Simply by working in the public eye, a developer is showing their skills and is documenting them for whoever may want to take a look . This is in contrast to work on closed source which nobody outside the employing company can see.
- Demonstrated technical skills for a particular project. In addition to general publicly performed work, the developer is demonstrating their skills for a specific project at hand. Not only is a developer generally competent, they are specifically and demonstrably competent for the project at hand.
A hiring manager can go to the project’s website and see for themselves how good a particular developer really is. This is not possible for a traditional software developer whose technical work is hidden behind prior employers’ firewalls.
Chris DiBona, Director of Google’s Open Source Programs, has this to say:
“Open source software is strategic to Google, and naturally we hire a great number of open source developers. Someone who demonstrates their ability by contributing to open source projects shows that they are able to code in the real world in ways other developers can not readily match. It’s the ultimate referral.”
A host of websites and services have sprung up that make assessing a developer’s reputation and public open source work easy: For example, Black Duck Software’s ohloh.net provides a comprehensive assessment of a software developer’s open source activities and how other developers relate to him or her.
3.2 Peer-Certified Social and Technical Competencies
A well-working open source project of non-trivial size validates a developer’s competencies by making him or her one of their own. The project is “peer-certifying” a developer.
- Peer-certified technical skills for a specific project and independently of it. The demonstrated technical skills, whether for a specific project or independent of it, become particularly valuable if the work is accepted for incorporation into an existing project. (This is the step from user to contributor.)
Now, the developer is not only performing public work, but other developers, the existing committers of the project, have evaluated the work as being good enough for inclusion in the project. Existing committers have a long-term interest in the project and typically only accept contributions if they meet their quality standards.
Thus, a developer who finds their work accepted into an open source project thereby receives a seal of approval (“peer certification”) of their competence by a group of other developers, the committers, who care deeply about the quality of this work.
- Peer-certified social skills to work in a team and get along with people. If a contributor receives a vote of trust and is promoted to committer status, the existing team of committers certify that the developer can work in a team and that they would like him or her to join them.
If they would find the person to be disagreeable, they would not promote him or her, as the consequences for the project could be dire. Thus, achieving committer status in a non-trivial project is a measure of a developer’s social skills to get a long and work effectively in a team.
- Peer-certified leadership skills. A developer who becomes a committer or better yet a member of a project management committee signals that they are seen as a leader of the project. The existing committers trust him or her to lead other people and inspire them to keep working on the project.
Robert O’Callahan, a distinguished engineer at the Mozilla corporation, comments:
“Open source contributors tend to believe in and practice the values that characterize successful open source projects, such as community, meritocracy and transparent government. Hiring those people strengthens those values within your corporate culture.”
If you would like to learn more about inner source and how it can improve firm-internal software development, please see this article about Inner Source in Product-Line Engineering or take a look at our services.
Thus, hiring open source developers can also be a means for changing to or strengthening corporate values of open collaborative software development. Such open collaborative development is not only applicable to open source software development but also to firm-internal software development, where it can help tear down development silos (called “inner source” then) .
3.3 Position of Power and Influence
In addition to demonstrating competencies and finding them validated by a peer group, achieving status in open source projects creates additional benefits.
- Position of power and influence. With committer status or beyond, a developer receives significant formal power. Not only can they put code into the project without peer review, they can influence tone, content, and direction of the project. Committers set the strategic charter of a project, including architecture decisions.
Such power and influence can be used in many ways. It can be used positively by leading and inspiring in a collaborative way and it can be used strategically and commercially, for example, by keeping the competition out of the open source project by rejecting them for committer status.
- Visibility to community and beyond. With the committer status comes visibility and outreach ability to the project community and other interested parties. The committer may become a voice of the project. He or she may get invited to publish about the project or speak at conferences.
4. Economic Value of Signals
These signals about software development competencies as well as project power and influences can be picked up easily by companies, as all these signals are public. They change the negotiation power between job seeker and prospective employer.
In hiring situations for developer positions at companies, open source software developers have an advantage over developers without publicly displayed work. The signals mentioned above can lead to
- a higher salary,
- higher job security, and
- a richer job experience.
Of these benefits, the higher salary has been empirically validated for Apache Software foundation committers by Hahn et al. , though Bitzer et al. found no such increase when looking at a broad array of mostly non-commercially-relevant open source projects .
4.1 Value of Verifiable Claims
A higher salary is a consequence of the reduced uncertainty in job interviews. A hiring manager or engineering manager, who can look at sustained public open source work of a job applicant, can gain higher certainty as to that person’s technical skills. This increased certainty reduces the uncertainty discount that is present in all salary negotiations.
Marten Mickos, CEO of Eucalyptus (and former CEO of MySQL), points out:
“From a software vendor’s perspective, open source work on a developer’s resume is a definitive plus. It shows that the developer has a genuine passion for writing software and a level of self-confidence that’s useful to us. […] If the developer even contributed to our [open source] products, it increases their chance of being successful at our company: Ramp-up time will be shorter and we know they are likely to be a better fit than an unknown developer. All of this leads us to prefer open source developers when hiring.”
If the technical skills of the developer are for a project that has commercial value for the employer, the developer’s negotiation position improves accordingly.
This value accrues to anyone, be he or she a contributor, committer, or PMC member. It is also by far the most common value extracted from open source work.
4.2 Value of Peer Certification
Anyone with committer or PMC member status also gets peer-certified for their work, making their technical and social skills even more believable, further reducing the hiring risk and improving the negotiation position.
Rachel Chalmers of Ignition Partners, a Silicon-Valley-based boutique venture capital firm, finds the following value in the public work that open source software developers perform:
“When we look at a start-up, we look at the GitHub repositories, we look at Ohloh.net. We drill down to the level of individual developers. It informs our investment decision. That fact alone gives open source software developers significant leverage when negotiating their position, salary, and benefits with start-ups.”
4.3 Value of Position of Power
If a developer has committer status in an open source project that is commercially relevant for the employer, for example, because the employer’s products build on the project, then the employer can buy several things by employing the developer:
- Visibility into what’s coming. A committer is actively engaged in leading the project and thus has unique insight into where it is headed. This is of strategic importance for a company whose products build on the project or a full (foundation-managed) platform.
- Influence on the project. The committer is in a position to perform key work him or herself, to channel the company’s work into the project, and to lead and inspire outside developers to contribute in alignment with the employer’s strategic goals.
- Increased employer attractiveness. The committer’s reputation attracts other developers who want to work with him. Thus, his or her employer appears as more attractive than others and may be sought after by other competent developers.
- Goodwill with the community. The committer’s visibility to the community shines a positive light on his or her employer. Paying the developer to work on the open source project creates goodwill with the community.
- Competence by association. By employing the committer, the company acquires competence in the project. The trust in the company’s products and services increases to the extent that they are related to the open source project. This helps marketing and sales of these services and products.
This increased insight, influence and visibility are commercially relevant for the company and hence afford the developer an improved negotiation position when it comes to salary and other job conditions.
Kai-Uwe Maetzel, back then an IBM employee and elected director of the Eclipse Foundation (2005-2007) already remarked in 2003:
“Companies want to secure their influence on the Eclipse platform, and one way of doing so is by employing committers to Eclipse projects. Increasingly, I see regular developers being hired with the goal of ‘making them committer’ within a few months.”
When reminded of his remark for this article, Maetzel, who has since left IBM to found his own company, Thinking Owl, added:
“My contributions to the Eclipse project (2000-2007) resulted in a high visibility in the Eclipse affine developer community. Pretty much every offer I received during these years from potential employers explicitly referred to my reputation in the Eclipse project.”
Committers to open source projects of commercial relevance to an employer are likely to have higher job security as well. In hard times, the economic value of the committer position may be the one advantage that the committer has over another non-committer employees that may keep him or her from getting fired.
Committers also have a richer job experience. The job requirements are broader than those of a regular developer. Not only is the developer expected to perform well within the company, he or she also may also be expected to keep working on the open source project, creating added work context, requirements, and experience.
5. A New Software Developer Labor Market?
A contributor position in an open source project is valuable, but it is not scarce. Many people can become contributors and build a public reputation and an open source resume. A committer position is more scarce and leads to higher reputation and recognition. At the high-end are committers who are also members of project management committees (PMC). As a project matures and growth slows, it becomes more and more difficult to join the ranks of committers and PMC members, simply because fewer such people are needed.
The labor market for developing with and building on open source components has little or no barriers to entry: The open source software is readily available and typically many free educational materials exist. Thus everyone who wishes to join this labor market can do so without running into financial or educational barriers.
Richard Seibt, president of the Open Source Business Foundation, points out:
“With diminishing barriers to entry, everyone can contribute to open source and earn a living. Both software vendors and IT user firms are increasingly turning to open source foundations as a means for organizing software development. This provides ample employment opportunity for software developers who are skilled in open source development.”
In contrast, closed source software protects the wealthy: To join the labor market for developing with closed source software, a developer typically needs to purchase a license and participate in commercial trainings. Sometimes, access is only possible through a mediating employer. No or few such complications exist for open source software.
In addition, open source and associated web services has facilitated the growth of end-user programmers: People without formal computer science education who are able to perform lightweight programming tasks using scripting languages and performing web design. These people are entering the labor market and are providing additional competition for traditional developers.
As more and more software products build on open source components, the importance of these components is only increasing. With no or little barriers to entering the labor market for these components, wealthy software developers may face more competition from less wealthy and less skilled developers. Such competition was previously not possible due to the barriers to entering the labor market for the then-dominant closed source software.
Based on these observations, the author of this article speculates that the software development labor market may split into two parts: Those who hold a position of power in important open source projects and those who don’t. Those with important positions will be better off while those who don’t have such a position will be worse off than before due to increased global competition.
This possibly emerging two-class society is at least in theory independent of where a developer grew up, because the Internet affords access to open source software to everyone. As a practical matter, wealthy Western developers got a head-start: They created the ecosystem and are accustomed to its collaboration values. They also have the spare time and resources to get started working on open source. In related work we show that Asian countries provide only a small percentage of open source software . It may take a generation of Asian software developers to overcome this Western head-start.
This article shows that participating in and leading open source projects has tangible benefits for software developers. A second career ladder is being created and taking steps on it makes developers more attractive to employers. Consequences can be a higher salary, higher job security, and a richer job experience. In related work, we discuss the competencies needed to become a successful open source software developer .
These benefits accrue from verifiable skills, peer-certified competencies and positions of power that open source projects afford developers. The first two benefits can accrue to anyone who is active in open source, the third benefit typically requires being active in foundation-managed open source projects, as these are the industry platforms that employers are focusing on most.
The significance of these findings is heightened by the observation that with increasing use of open source software in products, the overall developer labor market is becoming more competitive. Previously, closed source software afforded wealthy Western developers some protection from low-wage countries, but this protection is fading away to the extent that readily available open source software is replacing closed source software.
I would like to thank Ann Barcomb, Hannes Dohrn, Kai-Uwe Maetzel, Michael Maximilien and Robert O’Callahan for helping me improve this article. I also would like to thank Rachel Chalmers, Chris DiBona, Justin Erenkrantz, Kai-Uwe Maetzel, Marten Mickos, Robert O’Callahan and Richard Seibt for timely provision of quotes to illustrate the impact of open source on the software developer career.
 Binstock, A. (2011). “How to Contribute to Open Source Projects.” Available from http://drdobbs.com/open-source/231000080
 Bitzer, J., et al. (2010). “Returns to Open Source Engagement: An Empirical Test of the Signaling Hypothesis.” Oldenburg Working Papers, V-321-10. University of Oldenburg: 2010.
 Corbet, J. et al. (2012). “Linux Kernel Development – How fast it is going, who is doing it, what they are doing, and who is sponsoring it?”, 2012. Available from http://go.linuxfoundation.org/who-writes-linux-2012
 Crowston, K, and J. Howison (2011). “The Social Structure of Free and Open Source Software Development.” First Monday, vol. 10, no. 2.
 Dinkelacker, J., et al. (2002). Progressive open source. In Proceedings of the 24th International Conference on Software Engineering (pp. 177-184). ACM.
 Hann, I.H., et al. (2002). “Why do developers contribute to open source projects? First evidence of economic incentives.” 2nd Workshop on Open Source Software Engineering, Orlando, FL. 2002.
 Jensen, C. and W. Scacchi (2007). “Role Migration and Advancement Processes in OSSD Projects: A Comparative Case Study.” 29th International Conference on Software Engineering (ICSE 2007). IEEE Press, 2007, 364-375.
 Kimmelmann, N. (2014). “A Career in Open Source? Relevant Competencies for Open Source Software Developers.” it – Information Technology, vol. 55, no. 5.
 Lerner, J. and J. Tirole (2002). “Some Simple Economics of Open Source.” Journal of Industrial Economics, vol. 50, no. 2, pp. 197-234.
 Riehle, D., et al. (2014). “Paid vs. Volunteer Work in Open Source.” In Proceedings of the 47th Hawaii International Conference on System Science (HICSS 2014). IEEE Press, 2014.
 Riehle, D. (2007). “The Economic Motivation of Open Source: Stakeholder Perspectives.” IEEE Computer vol. 40, no. 4 (April 2007), 25-32.
 Riehle, D. (2010). The Economic Case for Open Source Foundations. IEEE Computer vol. 43, no. 1 (January 2010), 86-90.
 Weißgerber, P., et al. (2008). “Small patches get in!” In Proceedings of the 2008 International Working Conference on Mining Software Repositories, 67-76.
Prof. Dr. Dirk Riehle, M.B.A., is the Professor of Open Source Software at the Friedrich-Alexander University of Erlangen-Nürnberg. Before joining academia, Riehle led the Open Source Research Group at SAP Labs, LLC, in Palo Alto, California (Silicon Valley). Riehle founded the Wiki Symposium, and more recently, the Open Symposium, now the joint international conference on open collaboration. He was also the lead architect of the first UML virtual machine. He is interested in open source and inner source software engineering, agile software development methods, complexity science and human collaboration, and software system architecture, design, and implementation. Prof. Riehle holds a Ph.D. in computer science from ETH Zürich and an M.B.A. from Stanford Graduate School of Business. He is a member of the ACM, the IEEE, and the GI (German Informatics Society), among others. He welcomes email at firstname.lastname@example.org, blogs at https://dirkriehle.com, and tweets as @dirkriehle.