Open source athletes
First Monday

Open source athletes by Stefan Gorling



Abstract
The open source development model has often been treated by academic research as a new and unique model of production, fundamentally differing from previous known and accepted economic models. This paper explores a possible metaphor between open source and athletics as a way to increase our understanding of the open source phenomenon.

Open source development has a great similarity of amateur and professional athletics. Properties such as the importance of a community, sportsmanship and fair play are important in both areas. By comparing open source developers (OSD) with athletes, we see that many commonly regarded unique features of OSD may already be existent in other parts of our economy. A greater understanding and previous research of business models, coaching and motivation in athletics might therefore provide useful models of explanation in the field of open source research as well.

Contents

Introduction
Open source development and sports
Profiting from the game: Business models in open source and sports
Play and motivation
Conclusion

 


 

Introduction

The purpose of this paper is to introduce and exemplify some of the similarities between open source development (OSD) and sports. I will touch a number of areas briefly in order to establish that we might gain increased understanding by using this as a perspective when we discuss OSD. The arguments presented below will not always meet the scientific level of proof — consider this paper an inspiration for further studies.

In order to simplify for me as well as the reader, I will hereby sin, I will sometimes refer to members of an open source community as “hackers.” This will raise some eyebrows, but it is only a naming convention not a contribution to the hacker vs. cracker debate. When I refer to a hacker, I refer to an individual who is a contributor to an open source project (OSP).

I will also talk about amateurs, which does not refer to the skill of certain individuals, it merely indicates that they are not receiving money for their efforts, at least not as their primarily source of income. When discussing sportsmen, I have chosen to refer to them as athletes, independent of their specific sport. There might be better terms, but those work for me.

When I studied how the open source community has evolved from a group of individuals developing software as an hobby into an environment where professionals work and large commercial interests affect the rules (Görling, 2003), I found that there were great resemblances with the evolution of professionalism in sports. Even though hardly any of the inhabitants in the communities around open source would look upon themselves as athletes, they are individuals, pursuing something for the pure excitement of it, and they join together to form teams in order to make software better, even more exciting.

Not only are their motivations comparable with those of modern athletes, but they also have a great culture of sportsmanship. The whole community is built up by a number of rules, aiming to secure the success of the team as well as giving credit to an individual for their work.

The change we today see the start of in the open source community might be very similar to the change in the nature of sports over the last century.

 

++++++++++

Open source development and sports

Even though a comparison between computer geeks and athletes might seem far fetched, open source development could be described as a form of athletics.

OSD is filled with the same kind of tensions and cooperation as team sports. The definition of open source developers lacks homogeneity, preventing comparisons with a specific sport, but there are many forms of competition in the communities. One might argue that at their core athletic competition (sports) provides a measure of performance with other athletes in a quest for achieving excellence (based on standards and records).

There is not one, but many ways to compete in software development. You compete either as an individual or as a team. Individual competition exists both in formal competitions, such as TopCoder.com (http://www.topcoder.com/), or in informal competition where you compete on the best implementation on a certain feature in a larger project.

As a software developer you are also able to compete as a team in a larger project. Belonging and contributing to a larger project is often regarded more prestigious than running your own small–scale project. As in a football team you have competition both between the other players within the team as well as between other similar projects.

Individual success could be formally measured in the number of features or rows of code committed to the project and team success could be measured by the number of users dedicated to your software.

Programming competitions are growing in popularity and there are several competitions where individuals and teams can take part. Competing in software development is especially popular among computer science students. Many teams are formed and affiliated with a certain university and there are courses in “programming under pressure.” Winning the World Championships (ICPC, 2004) is very prestigious for a university and could be used to attract new students.

These programming teams often resemble teams in sports. There are different roles for the participants such as algorithm experts, designers, developers, etc. There is often a coach and there might be several sponsors contributing funds and products in exchange for PR. I have not yet been able to find any professional team which make a living solely from competing in programming, but as there are many contests with prize sums as large as US$50,000, this might not be far away.

Sportsmanship and fair play

Both athletes and hackers share a common set of rules in order for the game to be played well. The following list of characteristics comes from the National Federation of State High School Associations (as promoted by the Wake County Public School System on their Web site [WCPSS, 2003]) but could as well come from a community site on open source software ethics:

  • Play fair, take loss or defeat without complaint, or victory without gloating

  • Treat others as you wish to be treated

  • Respect others and one’s self — Impose self–control, be courteous, and gracefully accept results of one’s actions

  • Display ethical behaviour by being good (character) and doing right (action)

  • Be a good citizen.

Open source communities are all about fair play and being a good citizen. There is a common agreement that the best implementation should be used and that you should gracefully accept that your solution is not selected. You have to be a good citizen and respect others when communicating in the project development.

Sportsmanship and fair play are the toughest things to teach in sports. At the hobby level, team members themselves acts as judges, deciding whether rules were followed or broken, whether the ball was in or out. The reactions of the other players create the verdict. Sportsmanship could be described as a framework for rule–setting where there are no judges.

In professional sports there are professional, independent judges since economic stakes influence notions of “fair play.” Given that these stakes are too high, impartial judges are necessary. Different athletes are represented by different organizations which have invested in them and their success. Those organizations have agreed to these judges (that is, officials, umpires, referees) as a way of settling their difficulties essentially out of court.

The sportsmanship of the hacker community is upheld by a culture with little acceptance of those that disrespect the rules of the community, but this largely affects only the members of the community. For commercial companies outside of the community informal regulation is not very effective. Therefore the open source community has agreed — legally — to complement the more informal ideas of sportsmanship and fair play — not primarily to regulate the behaviour among peers but to protect notions of “sportsmanship” towards commercial interests.

The importance of a community

Open source development is a team effort. It is possible to develop open software as a hobby without a community, but the risk for losing interest is high in the absence of colleagues and friends. If you manage to build a community around your project, there are other individuals with other motives who may carry on the work when your need is fulfilled. We tend to be willing to put in much more effort if there is an interest from other parties — someone ready to give you an ego boost every now and then. People do many things solely to show off, simply because someone told them that they couldn’t it.

The existence of a functional community is a single–point–of–failure for sports as well as open source development. Both athletes and hackers can play alone, but most of them prefer to belong to some kind of community. The community responds to the social needs of individuals — friends having much in common and sharing the same set of ethical rules. Both athletes and hackers sometimes stay in a community, not primarily for the sport itself, but for social events around it, and are willing to work on uninteresting tasks in order to preserve both social order as well as the community itself. For example, in youth sports there ae a variety of extra–curricular activities to raise funds, such as selling lottery tickets. In software development communities, Linus Torvalds added support for memory–to–disk paging [1] solely for someone else.

Open source developers, like athletes, form teams. Even if the sport is not team based, individuals often affiliate themselves with an organization founded on a similar interest. Competition appears in the form of the ACM International Collegiate Programming Contest (http://icpc.baylor.edu/icpc/).

A common pattern within open source communities is that people join together and form teams called foundations. These foundations acts as formal teams, hiring developers in the same way that professional football teams were once formed first into clubs, then into commercial entities.

What separates OSD from modern sports is the mixture of professional and amateur players, with professionals and amateurs often play in the same team. Research has shown that over two–thirds of the development on the Linux kernel was carried out by professionals, with the other third provided by amateurs (Görling, 2003).

This development might be seen as a temporary stage in the transition of amateur leagues. The same scenario occurs in the Swedish league for women’s soccer where only a few of the players are being paid. In this case, it is seen as a temporary stage in the process of professionalization.

There is some evidence that different leagues are beginning to evolve in software communities. Amateurs are able to create their projects, learn about sportsmanship and the rules of the game in these projects. Beginners join teams, create products, and gain experience and credit which can be used for recruitment in major leagues, such as the Linux Kernel or other high–profile open source projects.

The ability to fork

There is a basic rule of amateur sports — if you don’t like how the other players treat you, or if they don’t like you, you’re always free to switch teams, or take some of your players and form your own team.

In professional sports this option has somewhat been eliminated by professional contracts, locking a given player to a certain team. This is a common effect of specialization. If you pursue a hobby, you own the way you do it. If you’re professional, you’ve sold your freedom to switch teams.

The same principle applies to open source development. If you are programming as a hobby, you are free to change projects, fork a given project, or simply stop developing at all, at any time you wish. But when you get paid for programming, you are committed to being part of a community and a specific assigned project, whether you actually would do it on your free time or not.

With a few exceptions, the pros of today were the amateurs of yesterday. At some point in their life, they made the decision to turn their hobby into work. And at some point, they discover the wisdom of their decision.

Recruitment

One area where hackers could learn a lot from sports is how to engage younger participants. Many sports have very pronounced methods for increasing the interest of their sport among young peole. Open source development, like some sports such as golf, requires an initiator, someone who can teach you about the game. There are some new initiatives to create a formalized structure to educate newcomers about the game and its values. One example is the “Kernel Newbies” project (http://kernelnewbies.org/) which teaches programmers on how the Linux Kernel works.

Only a few years ago, computers were simplistic toys. Personal computers of the seventies and eighties made it relatively easy to program. Given that today’s software is much more complex, there might be a need for a more formalized way to inspire future talent rather than having them play computer games.

Coaching

Even the leadership models of OSP resemble those of sports. Each project has a coach (project maintainer) with no formal authority, and therefore no real power to force anyone to do specific tasks. If the player (developer) doesn’t like the leader, he is free to leave the project at any time, or even start a new project with another leader. As the leader of an OSP has no formal power, he can only survive by serving the best interests of the team by making appropriate decisions at the right time.

 

++++++++++

Profiting from the game: Business models in open source and sports

In order to illustrate how this metaphor might be helpful, I will describe three basic business models used by companies which try to profit from open source products and relate these to business models for sports. There are a number of different ways for companies to profit from the efforts of developer communities.

  • Services for the players, the communities and the games;
  • repackaging and distribution; and,
  • brands, trademarks and spin–offs.

Services for players, communities and games

The most basic model is basic retailing. Every community needs a number of basic services to function well. Open source developers needs hosting services, development tools, community Web sites in order to function as a group and be able to develop software efficiently (Cygnus Solutions, BitKeeper, Open Source Technology group). Athletes need specialzed clothes, equipment, and arenas (Adidas, Nike, Top Flite).

Repackaging and distribution

Another way to profit from communities is simply to repackage and distribute what the team is doing well so that it is available to a wider public. In sports and in open source projects, there is a large difference between the number of active participators and the number of individuals interested in or benefiting from the sport or project. In sports there is a small core of players pursuing a game with an audience enjoy the event itself. Open source shares the same attributes with a core development group, representing the main players, and a larger number of contributing users who use the software and occasionally fix bugs. There is a larger number of potential users who could benefit from the software — if it was only packaged in the right way.

 

A model of potential users in sports and open source

Figure 1: A model of potential users in sports and open source.

 

The gap between core and potential users is a profitable place to position a business. A number of companies are working on packaging and distributing software/games, such like Eurosport and Red Hat.

Brands, trademarks and spin–offs

Finally, in a world where trademarks are increasingly important, companies invest in games and players in order to be associate their trademarks and brands with specific athletes and sports. This strategy is now gaining momentum in the world of open source. The most famous programmers are being recruited by companies in order to build a brand both within the community as well as outside it. Hiring an established name is a way of assuring the community that you understand the rules and that you will embrace them. It is also a way to show your customers that you have the knowledge to deliver the best possible solution (that you are the winning team).

 

++++++++++

Play and motivation

There have been a number of efforts to explain why individuals engage in open source development. Many observations provide a variety of reasons, ranging from religious motives to communism and altruism. I argue that most of those explicit motives are the efforts of many to create rational explanations for their behavior.

As humans we have a need to feel that we behave in a rational manner. If we are asked for a reason for pursuing anything, we try to create one. This rationalization is evident when pursuing a hobby. Many things which we do for a hobby seems radically irrational when examined from different perspectives. For example, golf players tend to dislike being described as people chasing a ball toward a hole with a stick for an entire day, even though this might to some be a rationalized description. Yet, for some, there are individuals who enjoy chasing that ball. It is amazing what they are willing to do in order to be able to chase it. They buy expensive equipment and queues for hours in order to be able to do it. There are many other hobbies which are even harder to explain, flintknapping being one of my favourite examples [2].

If you ask an amateur why they participate in a given sport, they might give you various answers ranging from fun to exercise. Golf players are often said to be after exercise, fresh air and nature, and yet we find them going around in mini-cars on a huge lawn instead of taking a walk in the forest (yes, some golf players tend to take a walk in the forest, but they often rather not talk about it).

The problem with this sort of rationalization is that we, as human beings, are not rational.

The first time we try out a specific athletic activity, we seldom make objective evaluations over participating in a given sport. We simply ask ourselves if we might enjoy it — or not. The human man is not the economic man. The fact that we might enjoy doing a thing does not mean that we seek to pursue it as a career, nor that we have rational reasons for doing it.

When the Boston Consulting Group (2002) surveyed a group of hackers about their motives for programming, their main motives were fun, skill and freedom. Athletes of all stripes would provide the same sort of answers over their motives.

The professionalization of the game

The concept of fun is fundamental when it comes to open source. Huizinga summarizes play as

“It is an activity which proceeds within certain limits of time and space, in a visible order, according to rules freely accepted, and outside the sphere of necessity or material utility.” [3]

This definition of play could best be illustrated in its purest form with the play of children. The same definition could be used to illustrate what all of us are looking for in our lives. We want to be able to act according to rules freely accepted, outside the sphere of necessity or material utility. An increasing number of individuals are interested in a profession where they can play, combining their source of income with play. Huinzinga concludes that:

“First and foremost, then, all play is a voluntary activity. Play to order is no longer play: it could at best be but a forcible imitation of it. By this quality of freedom alone, play marks itself off from the course of the natural process.” [4]

If we consider the properties of play, we soon realize that, using those assumptions, professional play cannot be regarded as play. Receiving money for our work enables us to play “according to rules freely accepted,” our salary forces us to accept a certain set of rules. This does not prohibit individuals to sometimes feel that they are having fun at work, even that they are playing, but someday, when the sun shines and they rather do something else, it probably won’t be play at all.

Open source communities might actually enable you to take part in a specfic programming community, while not breaking the rules of play. It is carried out with freely accepted rules, and we are free to leave at any time we prefer, at the time you shut your computer down, or stop reading a specific newsgroup, you are back in reality.

Even though scholars will continue to develop various models to describe the rationale of open source, the real reason for programming on a hobby basis is the same reason that we pursue any hobby. We enjoy it. It is an activity which we have freely accepted; it is outside the sphere of necessity.

Open source communities

Putnam (2000) argued in Bowling Alone that most reciprocity is descending. It is interesting to note that open source, as a reciprocate activity, is flourishing in an era where other social communities are withering.

One of the reasons why some communities are failing is a lack of recruitment of young members; open source culture has been able to easily recruit new members. However most active developers were recruited in the 1990s, so it would be premature to assume that this trend will continue in the long term.

In society in general, there are indications that some organizations have encountered difficulties in retaining members for longer periods. At the same time there is an increasing interest in organizations such as Reclaim the Streets! (http://rts.gn.apc.org/) or Association pour la Taxation des Transactions pour l’Aide aux Citoyens (ATTAC, http://www.attac.org/), dedicated to specific issues.

Without listing all of the factors involved in the process, one cannot ignore the fact that society is transforming from traditional, long–term, trust-related societies into more, short–term, transactional relations.

A transactional status system

The status system of open source communities is far more transactional than more traditional civic associations. We are no longer interested in investing many years of hard, unpaid, work in order to gain social status. Doing voluntary work without a guarantee of social status is a risk greater than we will accept. In open source communities one gains reputation for what you actually do — your transactions adjust your status.

Money as a secondary motivator

Keeping money out of the system, or at least not as the primary motivator, open source enables individuals in all stages of life to participate. What is somewhat unique is that money is hardly a central issue in the same way as in amateur and professional sports, where various participation fees and competition prizes are common, embedded elements of the game. The initial financial investment requires participants to have access to some hardware and software. Hence participants are free to enter and leave at a low transaction cost, hence risk is reduced. As we are becoming more risk averse, that is afraid of long–term commitment, this situation is definitely attractive.

Loosely knit

Smith and Kollock (1999) argue that a community is built up by persons sharing the same values. Even though communities traditionally have been built upon long–term, trust–based relations this might not be necessary. Relationships are created in all forms of communication, and a community could be built as long as there is a group of persons sharing the same values, communicating with each other.

One might begin to question whether open source communities really are strong enough to count as social relationships. Development efforts could be carried out as simply transactions so that software is developed in the absence of social relations. Is open source development really adept at nurturing social activities?

Smith and Kollock state that most friends we have — and hence most social relations we have — are only valid in a narrowly. We might have some friends at work, some at school, some neighbours. All of these are narrow in the sense that we only turn to them in certain situations and seldom mix them. However following any discussions on developer lists will reveal in fact socialization in these communities.

Communication is not strictly transactional — there are greetings and chatting even though it only takes place between the lines. For instance, Linus Torvalds announced a new version of the Linux Kernel, shortly before Thanksgiving, and signed off with:

“Please don’t even bother sending me patches, because I’ll be stuffing my face away from email over the next few days. And after that it will be up to Andrew to say how to go on from here. Mmmm. Turkey.” (KernelTrap, 2003)

 

++++++++++

Conclusion

In the last few years, much has been written on open source, its principles, its organization and its motivation, but little of this literature correlates athletics and open source development. Comparing programming communities with athletic communities could be beneficial for a more fundamental understanding of both communities. This metaphor may also be useful in explaining open source to those with little knowledge of programming. Indeed this discussion may ultimately help to place open source communities into their proper cultural context. End of article

 

About the author

Stefan Görling is a doctoral researcher at the department for Industrial Technology and Management at the Royal Institute of Technology (KTH), Stockholm. His main field of research is in issues on entrepreneurial activity and creativity, particularly in technology–intensive ventures. He has previously published research on new and innovative entrepreneurs profiting from spam and computer parasites on the Internet.
E–mail: stefan [dot] gorling [at] indek [dot] kth [dot] se

 

Notes

1. Torvalds and Diamond, 2001, p. 198.

2. See http://flintknapping.com/.

3. Huizinga, 1950, p. 132.

4. Huizinga, 1950, p. 7.

 

References

Boston Consulting Group, 2002. “OSTG Hacker Survey,” at http://www.ostg.com/bcg/.

Stefan Görling, 2003. “A critical approach to open source software,” Masters thesis, Royal Institute of Technology (KTH), Stockholm, at http://opensource.mit.edu/papers/gorling.pdf.

Johan Huizinga, 1950.Homo Ludens: A study of the play element in culture. New York: Roy Publishers.

KernelTrap, 2003. “Linux: 2.6.0–test11, ‘Beaver in Detox’,” at http://www.kerneltrap.org/node/view/1684.

Robert D. Putnam, 2000. Bowling alone: The collapse and revival of American community. New York: Simon & Schuster.

Marc A. Smith and Peter Kollock, 1999. Communities in cyberspace. London: Routledge.

Linus Torvalds and David Diamond, 2001. Just for fun: The story of an accidential revolutionary. New York: HarperBusiness.

Wake County Public School System (WCPSS), 2003. “Sportsmanship Education,” http://www.wcpss.net/athletics/sportsmanship/.

 


 

Editorial history

Paper received 24 August 2006; accepted 16 February 2007.


Copyright ©2007, First Monday.

Copyright ©2007, Stefan Görling.

Open source athletes by Stefan Görling
First Monday, volume 12, number 4 (April 2007),
URL: http://firstmonday.org/issues/issue12_4/gorling/index.html





A Great Cities Initiative of the University of Illinois at Chicago University Library.

© First Monday, 1995-2017. ISSN 1396-0466.