Leadership in Open Source Software Development:

Past, Present and Future

By Dr. Russ Wright

Abstract

This paper explores the past, present and future of leadership and governance within Open Source Software (OSS) development projects. This paper also explores the current factors for successful leadership and governance of OSS development. As background, this paper explores the beginnings of the “hacker” culture that became the current geek and OSS culture. The future implications for leadership in regards to the Open Innovation model are also explored. The conclusion is that the OSS development model is morphing and changing so quickly that research cannot keep up with the change.

Leadership in Open Source Software Development

The nature of geek work is cerebral, most of the effort takes place inside the head of the geek, who uses their smarts to find solutions to problems. Typical leadership methods, designed for people who work on something external to themselves is not going to work on geeks. (Glen, 2003) How is it possible to lead these people? Before an answer is offered consider these addition factors: The people who do this work are volunteers, they are also spread over the globe and might not ever meet in person. How can a development project with these seemingly insurmountable factors actually work?

What defines OSS?

There are two basic camps that occupy the Open Source Software definition. The more radical of the two camps, holds to the belief that closed source software is dangerous and harmful and holds firmly to the belief that software should be open for the public good. (Stallman, 2001) There are others, perhaps with a more moderate philosophy, is that closing the source is a defect, as it prevents public inspection and that makes the program inferior. They desire open software to remedy the quality of the programs and make them more secure. (Perens, 2005). Other recent research contends that “OSS ‘hackers’ conceive of themselves as a movement to correct the failure of existing institutions (both industry and academia) to produce software adequately. (de Laat, 2007) By opening the source code of a software application, the developers were able to make changes to the programs as they pleased, create a whole new development methodology and build whole new communities around projects. As a result, a new term was needed to manage the licensing, ownership and copyright issues that blossomed along with the movement. Thus the term Open Source Software (OSS) was created by Raymond and Perens to define the situation.

Defining Leadership Challenges in OSS Development Projects

Leadership, or more precisely governance, which encompasses the leadership and the structure of the organization, in the OSS development environment must take on some different strategies to work. The volunteer, not motivated by the reward of a paycheck, must be motivated by other factors. Some recent research showed that the average volunteer software developer spends about 14 to 18 hour in a week working for free on OSS projects. These developers are mostly full time employees at commercial software companies, yet contribute for free. (Lakhani & Wolf, 2007) Thus, the leader must not only appeal to these other motivations, but also put in place a structure that cultivates the rewards that will motivate the volunteer.

The existing research into the leadership of OSS development communities created multiple definitions, each coming from different perspectives and does not provide a single clear encompassing explanation. For example: To provide rules, formal and informal that help identify developer identity, and help assign people to tasks. (Crowston, Li, Wei, Eseryel, & Howison, 2007) Another definition given: To control outcomes, people and communication. (Lattemann & Stieglitz, 2005) Yet another: To provide the normal methods of exchange using the commonly held values structure and the belief in sharing code with others. (Shah, 2006) Thus, none of these definitions fully define the role of leadership within an open source project.

The reason it is difficult to create a single definition for leadership or governance within an OSS community is because the communities and their purposes are widely varied. Some OSS projects do little more than build a single simple program, others become organizations, with a simple legal shell to provide a holding place for the assets and allow the project to take donations. At the extreme, some are non-profit foundations with committees and managed releases and possibly employees on a payroll. Other recent research attempted to create a definition which stated: “Thus, OSS governance can be defined as the means of achieving the direction, control, and coordination of wholly or partially autonomous individuals and organizations on behalf of an OSS development project to which they jointly contribute.” (Markus, 2007, p. 152) Although purposefully vague, this definition does provide a good starting point for defining the role of leadership in OSS development projects.

 

The Markus (2007) definition is good because it does not seem in conflict with traditional software development leadership responsibilities, and only highlights those additional aspects unique to OSS development. Her research revealed three particular goals of OSS development leadership and structure: (1) Keeping developers motivated, (2) solving coordination problems, and (3) cultivating a climate where developers will want to participate. These three goals are explored below.

The Motivation Dilemma

In traditional software development the developer is hired to do a job to create some product and receives compensation in the form of a paycheck for the effort. The developer might also take the job because they are interested in learning about the particular area of programming and want to advance their skills or they are motivated to solve the problem because it intrigues them. These factors fall into two different categories. According to Glen (2003) the software developer can be motivated by extrinsic factors, most often the paycheck, or intrinsic factors such as the desire to learn. He further explained that most of the factors will be intrinsic over the extrinsic. This idea is support by the research of Roberts, Hann and Slaughter (2006) who discovered in OSS development projects that even when extrinsic motivations exist, such as a paycheck, they do not crowd out the intrinsic motivators. Thus the developers who work on OSS projects, more often than not, can only rely on intrinsic factors and the leadership of the project must identify and build on those factors to keep the developers interested in the project.

Development Coordination Problems

In typical OSS projects the developers are spread out over the globe and this can present special problems for the leadership of the project especially when coordinating the interdependence of pieces of the software program. Traditional development leadership would assign tasks to specific individuals and organize the workers to performs certain tasks best fitted to their skills. (Glen, 2003) A study of virtual teams by Kayworth and Leinder (2001) discovered that leadership of virtual teams is fraught with difficulties because the solutions to the problems are much fewer because of the great distance between members. This problem of assignment and coordination does not seems to be as much an issue in OSS development projects. A recent study by Crowston et al, (2007) showed evidence that the most common method used in OSS development is a self-assignment process where the OSS developers would do the work by choice. One example given in the research showed an email where a developer called “dibs” on a particular part of the project because he wanted to learn how to make it work. The research further showed that instead of a hierarchy in assigning tasks, the developers will politely ask or just take on the task and do the work. Thus, the leadership of OSS projects do not seem to have the same issue, at least of assigning tasks and coordinating interdependencies as the developers seem motivated to pick up the tasks themselves.

Cultivating The Climate

The developers that participate in OSS development project come from two basic sources. A recent study defined two distinct categories of OSS developers as need-driven and hobbyist. (Shah, 2006) The need-driven participants consciously made the choice to use an OSS product, rather than a commercial solution so they could view and change the code to meet their own needs and solve a particular issue for a work-related purpose. The hobbyist programmer viewed participation in a particular OSS development project as a hobby activity and described the work as fun and challenging. Thus, each group has a different set of motivations and the leadership must be aware of these differences if they want to cultivate participation and contribution. Having a voice within the community is a potential solution to the motivation dilemma.

Because the OSS projects have little if any extrinsic motivators, such as a paycheck, to offer the leadership must capitalize on the intrinsic motivators available to them. A recent study by Manville and Ober (2003) explored the potential of using the voice of democracy as motivator. The study explained a situation where a developer might consider two different jobs, which have different working conditions and different pay scales. Some developers might always consider the paycheck the most important factor and choose the job with higher pay. Other developers might choose to work at a lower paying job because of greater opportunity to shape the direction of the organization. Thus the ability to have a voice in the decision making process might be a positive motivator for participation within a project.

A Brief History Of OSS Developer Culture And Ideology

To understand these struggles in leading an OSS development project requires some background. The history of OSS development is a tangle of political and personal motivations that evolved over forty years from the early computer programmers of the first mainframes all the way to the current personal computer users. After several attempts to untangle hype from fact, this author found it near impossible to determine the real facts and history of the Open Source Software movement. Below is a brief history, amalgamated from multiple sources into a single time-line. The history provided here only includes information that can be corroborated from at least one other source and is limited to details that reflect the transformation of the original computer hacker culture into the Free and Open Source software development culture of today.

The Big Iron

To fully understand the culture that permeates the OSS development world, will require some background on the origins of the hacker culture that become the OSS developer culture. According to Raymond (1999) the first group to begin the OSS developer culture began in 1961 when Massachusetts Institute of Technology (MIT) acquired a Digital Equipment Corporation PDP-1. This is often called the beginning of the “Big Iron” batch processing computers. In 1969 the addition of ARPAnet, the forerunner of the Internet built by the Defense Department as an experimental digital communications network, brought these programmers together allowing them to collaborate via electronic discussion groups despite being spread across the US. The computing culture flourished across ARPAnet particularly in the computer science department of colleges and universities who all used DEC PDP computers.

The birth of collaborative development started with a project at the MIT labs in 1967. MIT bought a PDP-10, yet the team rejected the existing operating system and built their own. According to Raymond (1999) they built their own operating system because they wanted to work their own way. This point is important because it shows the first real example of OSS developer attitude when a group of developers started a project because they want to solve a need not met by existing programs. This attitude is echoed by Perens (2005) when he stated: “Open source is an indication of an unfulfilled need.” Thus, the current Open Source Software developer mentality was influenced by the actions of MIT in 1967 when the existing software did not meet the needs and the group developers decided to make their own operating system that did things their way.

The Unix Gurus

The second group who influenced the current Open Source Software developer culture started in a very different way. Raymond (1999) explained that Ken Thompson working at Bell Labs in New Jersey resurrected parts of the failed Multics operating system and combined it with his own ideas and created a new operating system to run on a scavenged DEC PDP-7. While still in the very early stages of creating Unix, another developer named Dennis Ritchie created a development language called C to run on Thompson’s fledgling Unix operating system. Raymond (1999) explained that two major factors propelled this OS into popularity. First, this OS could run on essentially unaltered on several platforms and second, computer hardware was getting cheaper and faster and the operating system did not need to eek out every possible ounce of power from the hardware. Thus, Thompson’s Unix and Ritchie’s C language started a change in development, that allowed developers to take and move source code with them to any project running on multiple platforms. This portability, the ability to take and reuse software for other projects is part of the Open Source Software developer mindset today.

Commercial Destruction

A major solidifying factor for the Open Source developer culture came about through the commercialization and subsequent destruction of both the Big Iron and Unix cultures. According to Levy (2002) several startup companies lured away the talent from the MIT Big Iron labs and started rival fractured groups who were once good friends. A few years later similar attempts to commercialize Unix started enormous infighting and knocked them out of the market. According to Raymond (1999) “The proprietary-Unix players proved so ponderous, so blind, and so inept at marketing that Microsoft was able to grab away a large part of their market with the shockingly inferior technology of its Windows operating system.” (p. 164) Thus the infighting and the commercialization attempts caused many years of efforts to create a free and open operating system to flounder.

One of the most influential figures of the Free Software ideology is Richard Stallman who was a developer during the time when the commercialization of some of the MIT lab technologies saw the fracturing and destruction of the Big Iron and the Unix cultures. According to Levy (2002) Stallman was so depressed by the schism in the labs that he would tell strangers he met that his wife had died. This fracturing obviously colored his perceptions of software ownership and continues to affect the OSS developer culture.

In 1982 Stallman founded the Free Software Foundation, which holds the philosophy that software should have essential user freedoms anmd maintains the following definition of free software:

Free software is a matter of the users’ freedom to run, copy, distribute, study, change and improve the software. More precisely, it means that the program’s users have the four essential freedoms:

The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help your neighbor (freedom 2).
The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

According to Raymond (1999) Stallman’s idea of a free clone of Unix, which later became GNU/Linux, and his stubborn adherence to a free and open operating system epitomized the OSS developer culture. Thus Stallman, influenced by witnessing the destruction of computing cultures by commercialization forwarded through his creation of the Free Software Foundation another aspect of the Open Source developer culture.

Stallman began the construction of a Unix clone in 1983, that would be free and open. The original project was called the GNU (Gnu’s Not Unix) operating system. The project moved along slowly developing many tools and really floundered when AT&T sued over Unix rights in 1992. Stallman wanted to make sure that his software would stay publicly available and created a regulatory framework that came to be known as the GNU Public License (GPL). (“The GNU General Public License,” 2007) The GPL allows the developer to use, modify and redistribute the modified program, with one very important rule. The new code created from the original code must carry the same license. Thus this self perpetuating licensing scheme kept the source code always in the public domain. Around the same time a Helsinki University student named Linus Torvalds began developing a free Unix kernel for 386 machines using the Free Software Foundation’s toolkit. His initial, rapid success attracted many Internet hackers to help him develop Linux, a full-featured Unix with entirely free and re-distributable sources.

The Birth Of The OSS Development Method.

The OSS development methodology underwent a significant change when Linus Torvalds started developing his Linux kernel. The application development methods used reflected a significant culture shift from the previous development style. Raymond (1999), explained the difference in the development style by comparing the typical commercial development style of the time to building a cathedral and the development style of Linux to a marketplace bazaar. The cathedral style of software development was typified by a small group of experts working away in isolation with few code releases. The bazaar was a much more open style of development typified by many developers contributing updates continuously and many and often releases of the code. From the late 90′s through the early part of 2003 OSS development saw an enormous explosion using the Torvald’s model of development.

The Early Leadership Problems

Here is where the paths of the Free Software Foundation and the Open Source Initiative really began to diverge on philosophy. Raymond (1999) explained that shortly after a presentation of his paper on Torvald’s development model, Netscape announced that they would try this model and open the source of their browser. He further explained that over the next several days, in meetings with many influential figures, the decision was made to create a definition of Open Source Software through an organization called the Open Source Initiative. Raymond (1999) Explained: “What we realized, under the pressure of the Netscape release, was that FSF’s actual position didn’t matter. Only the fact that its evangelism had backfired (associating `free software’ with these negative stereotypes in the minds of the trade press and the corporate world) actually mattered.” (p. 256) Thus, a conscious decision was made to create a definition that would be more appealing to the business person as the definitions of the FSF did not translate well to business.

Over the next few years a great injustice was done to Stallman. As previously mentioned, Stallman had a large chunk of an operating system completed, but lacked a kernel and Torvald’s Linux kernel filled that gap. Often developers refer to an operating system by it’s kernel, despite the fact that many other pieces exist to make it an operating system. Perens (2005) notes: “Although Stallman did a great deal of the work that made Linux possible, Torvalds’ team of kernel contributors was not closely allied with Stallman, and announcements of Linux were not attributed to FSF.” Thus the considerable work of Stallman was not credited in the Linux announcements creating a division within the community that still exists today.

These major events shaped the culture that is the OSS community today. From the Big Iron era the early developers demonstrated the desire to meet a need not met by the existing operating system. This desire was carried forward into the Unix and C microcomputer era where tools and languages become portable and could be carried to other jobs so developers did not have to start over on each new assignment. Then the birth of the personal computer, and the explosion of the Internet brought together these developers from around the planet to work together to create software, GNU/Linux for example, that introduced a new way of creating software, and all the new challenges of leading these developers.

Major Intrinsic Motivation Factors In The Current OSS Development Culture

Like all development projects, regardless if the project is open-source or not, one of the major jobs of the leadership is to keep the team motivated. According to Glen (2003) the leadership must set a tone for the work environment to cultivate motivation. The unique qualities of an open-source project require the leadership of the project to take on some different attributes than their commercial counterpart. A recent study by O’Mahoney (2007) defined five specific intrinsic motivation traits of OSS development that manage and motivate the developers: (1) Independence, (2) Pluralism, (3) Representation, (4) Decentralized decision-making, and (5) Autonomous participation. Each of these traits are interrelated to each other and build a cohesive model of the motivations of the OSS volunteer developer. Thus, these traits are the basis of a community managed OSS project and represent the primary motivations for volunteer involvement. Each of these traits are explored in detail below as they relate to OSS development practices and other research.

Independence

For a mature OSS project, independence is natural, as the gained experiences of the community will form their own culture. Independence, according to O’Mahoney (2007) is defined as “A community that is independent does not rely upon the resources from any one organization, but is supported by a diverse body of participants.” (p. 144) This seems to resonate with Glen (2003) where he explains that the culture of a community will grow over time and establish shared patterns of interaction and will limit the ability of any one entity to control the group. Thus, independence seems a natural part of an OSS project as leadership cannot exert control but only nurture the environment.

This issue of project control and leadership came to a head with the development of the Linux Kernel. An article by Lemos (2002) explained that the developers who worked with Linus Torvalds on the Linux kernel were frustrated by the lack of response and tight control Torvalds was exerting over the development process. Changes and bug fixes would be submitted only to be ignored or flat out rejected without explanation which angered the developers. This created a delicate situation for Torvalds as the developers could easily fork the project, taking a set of the existing code, walking away from the existing Linux kernel project and starting a new project of their own. To resolve the problem Torvalds appointed several new people, he called lieutenants, who took over different segments of the development and code integration responsibilities. Torvalds had to give up some control to keep control of the project. Thus the kernel development project was establishing patterns of interaction that went beyond the control of the Torvalds.

Pluralism

The intrinsic motivator of pluralism has two dimensions, that partially overlap. The first part of the definition has to do with the governance of the project. For a project to recruit and retain talented developers, no one organization may own or control too much of the project and stifle other voices. According to research by West and O’Mahoney (2008), project with sponsors have a special problem as talented developers, which the project desires, will want freedom to act and share their thoughts. These developers will test the ability share and become vocal and critical of the project leadership if their voice is not heard and respected. Thus, the leadership must be cautious to not let any one sponsor dominate the project or talented developers will not want to participate.

The second part of pluralism deals directly with the voice of the developer. Because the work done in the development of a software programs comes from the creative mind of the developer, there can be multiple solutions to the same problem. Some solutions will be better that others, but all must be heard. O’Mahoney (2007) defined pluralism as: “A pluralistic community allows many approaches, methods, theories or points of view to be legitimate or plausible in pursuing a course of action” (p. 146) This also resonates with Glen (2003) who explained that one of the important roles for the leadership of a project is to create an environment that is safe for the presentation of ideas and that freedom of speech exists within the community. Thus the intrinsic motivator for the OSS developer is the freedom to present ideas that they know will be heard and considered as part of the solution.

Representation

The developers must also have a voice in the direction of the project. The definition of representation provided by O’Mahoney (2007), was a system of democratic representation within the project. However, the researcher does differentiate that the authority of the representative is limited to making decisions on the project and not in control over other members. The Glen (2003) research seemed to agree with this position as he stated, “everyone should feel that what they have to say is valued and becomes part of the discussion about how to proceed” (p. 127). Thus, even if the voice is representative and not a pure democracy, the members must feel that their voice impacts the direction of the project.

Decentralized Decision Making

To understand the organization of OSS development requires an understanding of the social structure, often called a social network. In the research by Wasserman and Faust (1998) they defined the structure within a social network as a grouping of units who depend upon each other and who are connected by relationships. In an OSS development project, where the participants are scattered about the globe and interact and connect with each other over the Internet, these units might be the groups of developers, testers and users. The relationships might be the direct discussions between two developers via a conversation or the bonds of trust formed between the users and developers. This social network is how the groups of people share knowledge and solve problems.

In OSS development the structure of the social network, usually comes in two distinct styles. The first style is centralized or group centralization, which Wasserman and Faust (1998) explained and modeled as equivalent to a solar system with a star in the middle and planets in orbit about them. The model they created of group centralization provides a simple measurement of the inequities of the team members based on the differences on actions and the patterns of interaction. This is the model initially used to create the Linux kernel as Linus Torvalds acted as the star and hundreds of developers worked though him suggesting changes which he accepted or rejected. (Raymond, 1999) The second style, as defined by Wasserman and Faust (1998), is core-peripheral which exhibits a central dense interconnected core surrounded by a halo of unconnected peripheral participants. Decentralized decision-making according to O’Mahoney (2007) is defined as a model where some of the decision making rights are distributed to the community members. The decision making rights generally deal with or fall into three distinct categoris of (1)code, (2)sub project and (3)community wide issues. This is the development model used on the FreeBSD operating system where some 300 core developers all have the ability to add and update the source-code at the same time. (Jørgensen, 2007) Thus, the collaboration and decision making process is influenced by the style social structure within the OSS development project and can affect how well a project team performs and the perception of belonging and satisfaction each member of the team experiences.

Autonomous Participation

Developers working on OSS projects will often desire to stake a claim on a particular part of the program and work on that part of the code. The research by O’Mahoney (2007) defined autonomous participation as one of the most important factors where developers are attracted to projects by the opportunity to learn, solve problems and improve their skills. This seems to agree with earlier research by Hackman and Oldham (1980) where their Job Characteristic Model (JCM) defined autonomy as a precondition for high motivation potential that multiplies the other intrinsic motivators. Glen (2003) also discussed the importance of autonomy:

With a solid understanding of the environment, they are able to make their own decisions about day-to-day matters without having to check with the boss constantly. For geeks, who generally have a strong independent streak, autonomy fosters motivation.(p. 110)

Therefore the ability to operate freely within a particular area of the code is a large motivating factor and the existence of autonomy will be a deciding factor for an OSS developer to join a project.

 

The Future of OSS Leadership: Harnessing Innovation

The OSS development model is currently jumping over to physical products such as beer and bread, and into other disciplines such as biotechnology and government policies. This new development process for physical products is often called Open Innovation. (Chesbrough & Garman, 2009) The research by de Laat (2007) made a bold proclamation about the flexibility of the OSS development model when he suggested that this model is the only known model of development that can be applied across products and is not restricted software alone. He tried to find an example of the closed source software development model that can be used for physical products and was unsuccessful in finding any examples. Thus the OSS development model, renamed Open Innovation for physical products is unique in the ability to be used in other industries. This concept is still relatively new to researchers and there is much territory still unexplored.

There is not much current research on how the leadership or governance will be affected by the shift of the OSS development model to other physical product industries. Most of the research continues to demonstrate the need to provide extrinsic motivators but also maintain a focus on the intrinsic motivators. (Chesbrough & Garman (2009), Dahlander, (2008); Grönlund, Sjödin, & Frishammar, 2010)

Most of the current research on Open Innovation looks at the for-profit companies and how they will need to shift their thinking about corporate boundaries. The companies will have to accept that the boundaries of their organization, once firmly defined will now have to be permeable and allow for interactive and distributed innovation where the resources, ideas and people move in and out of organizations constantly. (Laursen & Salter, 2006) This means that employees will need to experience those same intrinsic motivators as defined by O’Mahoney (2007) as their affiliations with a company will be much looser and not tied to the extrinsic motivation of a paycheck.

The research by Chesbrough & Garman offers an example of the Phillips company who, seeing a failure in their research model, opened up their R&D facility and created a open campus where now some 7000 researchers from multiple organizations share knowledge about products they create. The authors explained how this style of leadership prevented lay-offs and prevented the “high emotional and economic costs of severance while boosting morale for remaining and departing workers alike ” (p. 75). Thus the current research still reflects the regular needs of leadership as defined in Glen (2003), but also recognizes the advantages of embracing an Open Innovation model.

Changing Fast

All the research uncovered by this author had a common thread of exasperation among the researchers. The OSS development process is changing and morphing quickly. So quickly in fact, that the research cannot keep up. The research into the motivators of OSS developers by O’Mahoney (2007) explicitly stated that the rapid evolution occurring in the OSS development process as new hybrid models appear made defining the responsibilities of leaders and the structure of governance difficult to define. The leadership of the future version of an OSS development project, or Open Innovation product, will require a cyclic return to the list of extrinsic and intrinsic motivating factors to determine how well they are meeting the needs of their open communities.

References