PAOLO MAGRASSI CREATIVE NON-COMMERCIAL SHARE ALIKE

Free and Open-Source Software is not an Emerging Property but Rather the Result of Studied Design

Paolo Magrassi, [email protected]

Version 2.1 November 2010

Abstract: Free and software (FOSS) is considered by many, along with , the proof of an ongoing paradigm shift from hierarchically-managed and market-driven production of knowledge to heterarchical, collaborative and commons-based production styles. In such perspective, it has become common place to refer to FOSS as a manifestation of collective intelligence where deliv- erables and artefacts emerge by virtue of mere cooperation, with no need for supervising leadership. The paper argues that this assumption is based on limited understanding of the software development process, and may lead to wrong conclusions as to the potential of peer production. The development of a less than trivial piece of software, irrespective of whether it be FOSS or proprietary, is a complex cooperative effort requiring the participation of many (often thousands of) individuals. A subset of the participants always play the role of leading system and subsystem designers, determining architecture and functionality; the rest of the people work “underneath” them in a logical, functional sense. While new and powerful forces, including FOSS, are clearly at work in the post-industrial, networked econ- omy, the currently ingenuous stage of research in the field of collective intelligence and networked cooperation must give way to a deeper level of consciousness, which requires an understanding of the software development process.

Key words: Open source – FOSS – software process – collective intelligence – Wikipedia

1. Introduction facts –which was characteristic of the indus- trial era. One of the most intriguing aspects of the post- industrial society is the phenomenal ease and According to a growing number of authors, the the steeply decreasing cost of human collabo- combination of and dematerial- ration, thanks to the , the world-wide ization may give raise to a radically new econ- web and a number of tools sitting upon them, omy typified by a combination of the following such as wikis, social networks, peer-to-peer (in varying degrees and slightly different exchanges, and mobile devices. This com- shades depending on the individual views): pounds with another mega trend, which had • A culture of collaboration, sharing and manifested itself earlier (Drucker 1983), i.e. openness will grow rapidly and in the long the increasing importance of information and term possibly even replace the current at- knowledge manipulation as opposed to a main mosphere, dominated by exclusivity, clo- focus on the transformation of physical arte- sure, individualism and asymmetry (Bau- wens 2005, Baldwin 2009);

Software Is Studied Design 1 PAOLO MAGRASSI NON-COMMERCIAL SHARE ALIKE

• People work will be motivated less by Authors who have attempted to set the stage monetary or tangible compensation and for such a theory include, but are not limited more by personal affirmation, voluntari- to, Eric von Hippel (von Hippel 2005), Don ness, ludic payoffs, and willingness to par- Tapscott (Tapscott 2006, Tapscott 1997), ticipate in attractive or important ventures (Benkler 2006), Jonathan Zit- (Kane 2003, von Hippel 2003, Schroer train (Zittrain 2008), (Lessig 2009); 2008). Rather than attempting an exhausting, and hardly exhaustive, review of scientific pa- • Enterprises need not be stable constituen- pers published on the subject, reference to the cies lasting years or decades, kept together above books, all best sellers revered in many by hard pacts difficult to modify: they will intellectual circles, universities, research cen- form opportunistically (Berkman 2009) on tres and symposia, will suffice to provide an a project basis (Tapscott 2006), and any account of the ongoing efforts aimed at defin- person may be working for any number of ing the bottom-up forces that are shaping the them at any given time; post-industrial knowledge economy. • Enterprise organization will be less and One thing that those publications have in less based on designation, co-optation and common, regardless of their different flavours hierarchy: participation, self- and approaches to describing or advocating a determination and heterarchy prevail world of sharing and peer-production, is the (Lerner 2005, Fairtlough 2005); assumption that free and open source software • A much larger number of individuals than (FOSS) emerges as the product of a collective today will actively participate with direct intelligence phenomenon with no need for top- personal involvement in both the rule of down coordination and oversight. In Benkler’s society and the management of enterprises words, for example: (Lévy 1994); “Free software offers a glimpse at a more basic • A careful exploitation of collective intelli- and radical challenge. It suggests that the net- gence may lead to a world of prosperity worked environment makes possible a new and peace (Lévy 1994, Tovey 2008, Bald- modality of organizing production: radically win 2009). decentralized, collaborative, and non- proprietary; based on sharing resources and This enticing vision, in all of its variants, is outputs among widely distributed, loosely certainly not without merits and does hint to connected individuals who cooperate with issues that are at the core of the internet- each other without relying on either market enabled society, its future and the formidable signals or managerial commands.” (Benkler opportunities it purports. However the vision 2006, p. 60) “Based on our usual assumptions is still looking for admission in the official eco- about volunteer projects and decentralized nomic circles, due to the lack of a theory show- production processes that have no managers, ing how a cooperative, open, “sharing” econ- this was a model that could not succeed. But it omy could deliver at sustainable levels of pro- did” (Benkler 2006, p. 66). duction and growth (GDP).

Software Is Studied Design 2 PAOLO MAGRASSI CREATIVE COMMONS NON-COMMERCIAL SHARE ALIKE

We contend that this interpretation is flawed every seven developers work as employees or because spontaneous participation does not contractors of ordinary businesses. remove the need for leadership in software These numbers will not surprise senior soft- development. We will show that large software ware people: every experienced person who products, whether FOSS or proprietary, are all has performed software development or pro- distributed and cooperative in nature, and do ject management in less than trivial projects require top-down controls. thinks that a system of 11+ million LOC’s like, 2. Free and open-source software devel- e.g., Kernel in its 2.6.30 version opment: some metrics (Christianson 2008, Bos 2007, Leemhuis 2009), can not be built by thousands of devel- Useful sources concerning both FOSS devel- opers “without relying on managerial com- opment metrics and the FOSS methodology mands”. and process model can be found within the FOSS community itself. In fact, as we saw, 86% of Linux Kernel devel- opers, the core of FOSS, work for a pay in the Concerning development metrics, for example, ranks of a company, with all the usual manage- Kroah-Hartman (2008) provides us with rela- rial controls. But this is not even the point. If a tively recent data. According to this source, in team of entirely independent and autonomous the 2005-2007 time frame the Linux Kernel developers, working for free in their spare was attended to by approximately 3,700 indi- time, wanted to cooperate to the building of a viduals (not all simultaneously), 86% of which software system, whether FOSS or proprietary, were employed or contracted by enterprises they would still have to submit to the require- and 14% were moonlighters working for free. ments of design and coordination, as we will This statistic tells us two things. The first is see in sections 3 and 4. that the total of Linux Kernel developers 3 The software development process amounted on average to about 1,200 people on any given year between 2005 and 2007. It Software is a labour intensive activity. Statis- should be noted that 1,200 developers per tics vary greatly, but according to accurate re- year, some of which (as a minimum, presuma- views (Magrassi 1996) each “function point” of bly the 14% freelancers) working only part- software needs between 0.5 and 2 person-days time, is not a particularly large number by of work across the full first-cycle of a product software development standards. For example, (from conception to first user acceptance test): on average each of the top 25 banks in the this implies that a software written in C, like world mobilizes a development staff of at least Linux, requires in the neighbourhood of 1 per- that size every year, developing roughly 2 mil- son-day to get 15 working LOC’s done (the lion lines of code (LOC’s) of software (Gartner number of LOC’s per function point depends, 2009). among other things, on the programming lan- guage under consideration). The second thing that the Kroah-Hartman (2008) statistic tells us is that the spontane- A large software system, such as an operating ous, entirely autonomous participants in Linux system like Linux or a full-scale business ap- Kernel development are a minority: six in plication like a bank’s information system (in

Software Is Studied Design 3 PAOLO MAGRASSI CREATIVE COMMONS NON-COMMERCIAL SHARE ALIKE

order of magnitude, about the size of the Linux tine 1979, De Marco 1979). Integration favours Kernel today) amounts to millions of LOC’s: coherence, consistency and performance, therefore, in order to be delivered within a rea- while modularity eases maintainability, in- sonable time frame, it can only be built by creases robustness and resilience, and allows many hundreds, when not thousands of pro- for smoother division of work. fessionals. The two goals, however, are conflicting, and 3.1 Integration vs. modularity only suboptimal solutions can be aimed at. This is a fact that escapes the attention of most This requires coordination, otherwise the sys- non-software authors in the peer-production tem as a whole turns out incoherent. Worse and networked economy literature, including yet: unlike a system such as Wikipedia, which those –such as (Baldwin 2005)– who recog- can have low coherence but still perform de- nize the importance of modularity in software cently, a software must be integrated. In development (although they seem to think of it Wikipedia, an article may be very good even if as an exclusive prerogative of FOSS). some of the links departing from it point to badly written or inaccurate articles. Over time, Modern software architectures, conceived spe- those articles will presumably be strengthened cifically for highly-distributed and web-based and the overall “system” (the collection of all systems, try to confront the harsh reality of interconnected articles) will be better: in the software modules interdependence in various meantime though, it will have worked correctly ways. Service-based architectures, for exam- in at least some of its parts. But a collection of ple, strive to make systems as loosely-coupled software programs can stop working if any of as possible, in order to limit the negative ef- the programs is bad. fects of missing modules and corrupted links. Direct references made by programs to one One can consult a correct and informative en- another are reduced by maintaining directories cyclopaedia entry on “William Shakespeare” of “services” (programs). When a program even if the related (and linked to) entries on needs a service it will issue a request by simply “Stratford-upon-Avon”, “Christopher Mar- naming the service; the caller program (“con- lowe” and “Titus Andronicus” are missing or sumer”) needs not be linked in the same com- incorrect. However, one cannot run an order puter memory as the service’s (“provider”), entry program if the related inventory- and and the service may reside anywhere in the customer-management programs are not internet. working or inexistent. In software terminol- ogy, this is expressed by saying that Wikipedia 3.2 Needs for top-down supervision is a loosely-coupled system, while software is This approach, however, still leaves two issues tightly-coupled. open. Maximizing integration (which requires cou- To begin with, it only removes the lighter mu- pling) and modularity (which requires mutual tual-dependency problems: it does unbundle independence) at the same time has been the software and hardware, and it does encourage holy grail of software development since the modularity; however, when a programmer sets 1960’s (Böhm 1966, Dijkstra 1968, Constan- out to write a [consumer] program, they will

Software Is Studied Design 4 PAOLO MAGRASSI CREATIVE COMMONS NON-COMMERCIAL SHARE ALIKE

still need to know what provider programs do, #include and which parameters they must be passed, in int main(void) order to make any use of their services. This { requires stability of provider programs’ speci- printf("hello, world\n"); fications: a goal that conflicts with the fact that return 0; many programs are providers and consumers } at the same time. It follows that modularity is difficult to achieve without top-down coordi- from which the profane reader gets a grasp of nation, especially when the needed service be- how complicated it can get to instruct a com- longs in a subsystem very far from the one that puter to do such exoteric things as inventory the programmer is working on. management or shop-floor components as- sembly. At these levels of precision, required in Secondly, service-based architectures (like any the Linux Kernel like in any other software, architecture, for that matter) require stiff co- little can be left to improvisation. It is chal- ordination in building directories and keeping lenging to cooperate on the creation of even a a coherent nomenclature for all implied ob- single program, amounting to a few hundreds jects, such as programs and data sets. This is lines of code: a comma or a bracket omitted or definitely a goal requiring top-down supervi- removed by programmer “B” may make the sion. It does not matter whether such supervi- program obscure to programmer “A” and gen- sion is carried out by individuals or commit- erate a complete misunderstanding on the side tees, since in either case people ought to be of the computer (compiler). named and assigned to the coordination task: entities at a higher level than the individual Implementation details are extremely impor- programmer need to exist and exert their pow- tant in computer programming (“coding”), and ers if the software is to behave coherently. sometimes they make it impossible to comply with a given design specification, creating 3.3 Feedback loops feedback loops that reflect backwards from Furthermore, while it can be relatively easy to subsequent to antecedent implementation state in plain English the general, global pur- stages of the project: design decisions (includ- pose of a software (e.g.: “A new production ing the naming conventions we alluded to management system using RFID tags for com- above) must be modified due to issues brought ponents tracking and assembly”, or “Adding up at coding time and unimagined before. iPhone support to Linux”), precision becomes This fact, referred to in software engineering paramount as the development project pro- by saying that the development process has the ceeds, because most computers notoriously shape of a spiral (Boehm 1986), clashes with need detailed instructions to perform even the wish of assigning to each participant de- elementary tasks. The Linux Kernel, for exam- veloper a clear and defined task once for all ple, is written mainly in C, a programming and then simply waiting for his deliverable. language much closer to hardware assembly Furthermore, and more importantly, it makes than to human language. The C instructions it particularly challenging to coordinate mutu- for printing “hello, world” on a computer ally-invoking programs. screen look as follows

Software Is Studied Design 5 PAOLO MAGRASSI CREATIVE COMMONS NON-COMMERCIAL SHARE ALIKE

3.4 The need for top-down design It should by now be clear how the need for hi- erarchical layers of system design imposes it- Consider programmer John writing program self: a few designers (or maybe one Linus Tor- P1 and programmer Mary writing P2. If they valds) at the top, then some sub-designers un- are coding, it means that some prior decision derneath, then sub-sub-designers, and so on. has been made that there will be a program No meaningful piece of software, much less called P1 performing certain functions, and a one of millions LOC’s, has ever come together program called P2 performing other functions: as a working computer program without some this is called system design, or sub-system de- “higher-level” intelligence controlling the sys- sign in case P1 and P2 participate in a larger tem’s overall integration. piece of software. System design decisions, in this case, might have been taken by John and The modules attended to by individual pro- Mary cooperatively, “with no managerial grammers may only work together if one entity commands”. But what about the design of a above (person, team, committee, but in any system like Linux Kernel, counting programs case a defined subset of the entire develop- by the thousands and dozens of different sub- ment team) takes care of the overall design systems each requiring its own design, mod- and integration. Tales of Lego-like software ules split and coordination with other subsys- componentry assembly, while attractive and tems? suggestive, belong in the realm of software- tool vendors marketing and are inexistent in The structure of a large and complicated sys- the software engineering literature. In fact, the tem can, with some simplification, be depicted systems software domain, i.e. that of Linux as an upturned tree, from a root module (e.g., Kernel, is a very fortunate situation in that “Linux”) all the way to leaves corresponding to sense: because of the relative requirements elementary modules/programs needing no stability, some decent degree of modularity further split. Pjk, with 1≤ j ≥ M and 1≤ k ≥ N, is can be achieved. But in business applications the generic program module being attended to software, for example, modularization is still by programmer Ai, with 1≤ i ≥ R. R is the total little more than a dream. number of programmers available and MxN is the dimension of the hierarchical graph repre- 4 Organizational models in software de- senting the system structure. M is the breadth velopment, FOSS or not and N the depth: j is the number of peer mod- While explicit FOSS design supervision goes ules to P (all needing to be coordinated, i.e., jk overlooked in the software-naïve literature, co-designed, along with it), while k measures where coherence and design are considered as its degree of seniority; the lower is k, the larger properties emerging out of a “complex system” the number of modules underneath, because of individuals, it is of course a very well known we are moving towards the root. It is easy to fact in the FOSS community. see that while a leaf module PjN may only need 2 people to be designed, a very high-level Al Viro 1.9% module may require hundreds of co-designers David S. Miller 1.8% (all individuals who will program the modules Adrian Bunk 1.7% underneath), which is obviously unrealistic.

Software Is Studied Design 6 PAOLO MAGRASSI CREATIVE COMMONS NON-COMMERCIAL SHARE ALIKE

Ralf Baechle 1.6% In proprietary contexts, the people above often happen to be higher-ranked in a company hi- Andrew Morton 1.5% erarchy. But conceptually (and apart from the Andy Kleen 1,2% fact that, as we saw, the majority of FOSS de- Takashi Iwai 1.2% velopers do work in the ranks of enterprises) this difference is irrelevant to the present dis- Tejun Heo 1.1% cussion: whatever their hierarchical positions, Russel King 1.1% software designers do make decisions that the rest of the people must conform to. Steven Hemminger 1.1% Eric S. Raymond, one of the most authoritative

FOSS gurus (his 1999 book “The Cathedral and Table 1: The top ten Linux Kernel developers the Bazaar” had received 4,370 citations in in 2005-2007. Source (Kroah-Hartman 2008) Google Scholar by April, 2010, although per-

haps it is not as thoroughly read as it is readily Kroah-Hartman (2008) again provides us with quoted), describes the FOSS design issue in some information: relatively few individuals Raymonds (2000a): determine and even produce directly a sub- “The trivial case is that in which the project stantial amount of the work. In 2005-2007, for has a single owner/maintainer. […] The sim- example, the ten persons listed in Table 1 pro- plest non-trivial case is when a project has duced 14% of everything that was done in multiple co-maintainers working under a sin- Linux Kernel. The top 30 individuals produced gle “benevolent dictator” who owns the pro- 30%. These are the people who, along with ject. Custom favours this mode for group pro- Torvalds, made the top design decisions. (The jects; it has been shown to work on projects as vast majority of the other 3700 people or so large as the Linux kernel or Emacs. […] mainly –although not exclusively– did bug As benevolent-dictator projects add more par- fixing: an activity, according to Raymonds ticipants, they tend to develop two tiers of con- (1999), at which “crowds” excel). tributors; ordinary contributors and co- This does not mean that design proposals can- developers. A typical path to becoming a co- not be made by anyone else; it does not mean developer is taking responsibility for a major that Torvalds et al. exert managerial controls subsystem of the project. Another is to take the such as assigning tasks to specific people; it role of “lord high fixer”, characterizing and does not mean that participants cannot often fixing many bugs. […] A co-developer who ac- pick their preferred tasks from a to-do list; it cepts maintenance responsibility for a given does not negate that many design decisions are subsystem generally gets to control both the made by committee rather than by an individ- implementation of that subsystem and its in- ual alone (exactly as it happens with proprie- terfaces with the rest of the project, subject tary software products): but it does say that only to correction by the project leader (acting most Linux (or any other FOSS product) pro- as architect). […] grammers submit to design decisions made by someone “above”.

Software Is Studied Design 7 PAOLO MAGRASSI CREATIVE COMMONS NON-COMMERCIAL SHARE ALIKE

By custom, the “dictator” or project leader in a various sorts, all without hierarchical connec- project with co-developers is expected to con- tions to system designers/architects. sult with those co-developers on key decisions. All large software development projects, […] whether FOSS or not, are attended to by geo- Some very large projects discard the `benevo- graphically distributed teams, as is typical of lent dictator” model entirely. One way to do the very intricate ramifications of “global” this is turn the co-developers into a voting business organizations today. Business soft- committee (as with Apache). Another is rotat- ware applications, for example, are typically ing dictatorship, in which control is occasion- developed (by vendors and/or user enterprises ally passed from one member to another and/or professional services organizations) by within a circle of senior co-developers; the Perl teams working for dozens of different legal developers organize themselves this way. Such entities and dispersed across two or more con- complicated arrangements are widely consid- tinents. It is not uncommon to find, in such ered unstable and difficult.” teams, a minority of free-lance, self-employed professionals. All the people involved, in any [ © Eric Steven Raymond 1998] case, are accustomed to having two lines if re-

porting, quite often distinct: one thing is the The picture is clear. FOSS development is hierarchical manager (the boss), another thing based on one of two organizational models: the is the project supervisor or subsystem archi- benevolent dictator or the design committee, tect. and the former model creates less problems. Bottom-up participation isn’t FOSS-exclusive, This is hardly any different from proprietary- either: in all software development contexts, software development. individual developers can make design or or- 5. Conclusions ganizational proposals that extend beyond the scope of their formal assignment, and this is The development of a less than trivial piece of precisely the way most people progress from software, irrespective of whether it be FOSS or programmer to higher-level roles. This escala- proprietary, is a complex cooperative effort tion sometimes entails the climbing of the en- requiring the participation of up to thousands terprise hierarchy as well, but even this is not of individuals. A subset of the participants obvious: many corporations allow for “profes- must play the role of system and subsystem sional” career paths with little hierarchical im- designers, determining the systems’ architec- plications but still rewarding for the individ- ture and functionality, and the rest of the peo- ual. ple work “underneath” them in a logical, func- tional sense. 5.1 What is typical of FOSS?

This submission needs not also be hierarchi- And this is the point. What really characterizes cal: the same applies frequently to proprietary- FOSS, from a human resources viewpoint, is software development as well, where ample that a significant, although smaller than is use is made of contractors and outsourcers of usually believed (the 14% of the Kroah- Hartman statistic, in the case of Linux), num-

Software Is Studied Design 8 PAOLO MAGRASSI CREATIVE COMMONS NON-COMMERCIAL SHARE ALIKE

ber of people participate spontaneously and 6 Further research without pay. Designers set guidelines and Spontaneous/voluntary participation of con- maintain to-do lists: some developers sponta- tributors and the new intellectual property neously pluck from those. scheme, i.e. the quintessence of FOSS, are The literature on the motivations for partici- formidable drivers of change and innovation in pating to FOSS projects is vast. From, for ex- the post-industrial economy, with conse- ample, Kane (2003), von Hippel (2003), Ray- quences and implications extending far beyond monds (2000b), and Schroer (2009) we learn the reach of software. Economists, sociologists, that FOSS developers are motivated by the jurists, political scientists, psychologists are willingness to participate in an attractive and finding and will increasingly find in “open con- important challenge, by the fact that their tent” a myriad of research motivations. names will appear on the list of software and In the case of software, the naïve notion of sys- projects owners, by a genuine sense of sharing temic emergence should be abandoned and, to and participation, by homo ludens payoffs, and investigate further what makes the FOSS pro- sometimes by the urge to contrast dominant duction model different, research should be software players and “monopolies” like Micro- carried out on, among other things, the follow- soft (a urge carefully cultivated and fomented ing: by Microsoft’s adversaries, including IBM, Red Hat, Intel, Novell, Sun/Oracle, Hp and many • What are the relationships and the inter- others, who are the employers of that 86% de- play between hierarchical and functional velopers working on Linux as well as of those dependencies in software development or- working on all other FOSS products, and are ganizations? the “hidden” market forces behind such prod- • Is it easier in FOSS (than in proprietary- ucts). software development) to achieve

The second fact that separates FOSS from pro- [sub]system designer status irrespective of prietary software is, of course, the novel own- one’s hierarchical position? ership models reflected by the original General • Do bottom-up design proposals occur Public Licence and the many others that have more frequently in FOSS than in proprie- been developed from it since its inception in tary-software development? 1989. • Are FOSS products more modular than 5.2 What is not in FOSS, and in proprie- proprietary products, when both are con- tary software either sidered at the same level of abstraction The notion of a coherent and performing sys- with respect to hardware architecture? tem emerging from a crowd of spontaneous Finally, concerning an issue which this paper contributors without top-down direction and only touched upon quickly but is strictly con- supervision is unfounded: it does not corre- nected to the division of labour discussion, spond to the way software of any kind is de- there is a need to study what, if any, are the signed and built. market drivers behind FOSS products. Most of the literature we have referred to seems to as-

Software Is Studied Design 9 PAOLO MAGRASSI CREATIVE COMMONS NON-COMMERCIAL SHARE ALIKE

sume, and often explicitely states, that FOSS Boehm, B. (1986) “A Spiral Model of Software products are built by “loosely connected indi- Development and Enhancement”, ACM SIG- viduals who cooperate with each other without SOFT Software Engineering Notes, 11(4):14- relying on […] market signals” (Benkler 2006, 24, August 1986 page 60). The role played in FOSS by the many Bos, H. (2007) “If you cannot beat them, sue ordinary businesses (sometimes huge software them!”, Landelijk Architectuur Congres, NBC or hardware vendors) who directly or indi- Nieuwegein, 21-22 November 2007 rectly employ most of the developers must be Christianson, C. and Harguess, J. (2008) understood better. This will provide a sharper “Linux, Linus and Netville – The birth of open insight into the dynamics of peer production, source”, Department of Electrical and Com- the culture of sharing, and collective intelli- puter Engineering, The University of Texas at gence. Austin

Constantine, L. and Yourdon, E. (1979) Struc- References tured Design, Prentice Hall. Baldwin. C. and Clark, K. (2005) “The Archi- De Marco, T. (1979) Structured Analysis and tecture of Participation: Does Code Architec- System Specification. Prentice Hall ture Mitigate Free Riding in the Open Source Dijkstra, E. W. (1968) "Letters to the editor: go Development Model?”, Management Science to statement considered harmful". Communi- 52(7):1116-1127 cations of the ACM 11 (3): 147–148 Baldwin, C. and von Hippel, E. (2009) “Model- Drucker, P. (1983) Concept of the Corpora- ing a Paradigm Shift: From Producer Innova- tion, p. xvii, 1983 edition tion to User and Open Collaborative Innova- tion”, MIT Sloan School of Management Fairtlough, G. (2005) The Three Ways of Get- Working Paper # 4764-09, November 2009 ting Things Done: Hierarchy, Heterarchy and Responsible Autonomy in Organizations, Tri- Bauwens, M. (2005) “The political economy of archy Press peer production”, Ctheory.Net 1000 Days of Theory. Accessed 2010.05.08. Website: Gartner (2009) Personal communications of http://www.ctheory.net/articles.aspx?id=499 the author with Gartner’s (www.gartner.com) Measurement business unit Benkler, Y. (2006) , Yale University Press Kane, P. (2003) The Play Ethic: A Manifesto For a Different Way of Living, Macmillan Berkman Center for Internet & Society, (2009) , Kroah-Hartman, G., Corbet, J. and McPherson http://cyber.law.harvard.edu/node/5373 A. (2008) “Linux Kernel Development (April 2008). How Fast it is Going, Who is Doing It, Böhm, C. and Jacopini, G. (1966) "Flow dia- What They are Doing, and Who is Sponsoring grams, Turing Machines and Languages with It”, The Linux Foundation only Two Formation Rules", Communications of the ACM, 9(5): 366-371 Leemhuis, T. (2009) “What’s new in Linux 2.6.32”, Heise Media Uk Ltd.,

Software Is Studied Design 10 PAOLO MAGRASSI CREATIVE COMMONS NON-COMMERCIAL SHARE ALIKE

http://www.h- chapter, online.com/open/features/What-s-new-in- http://catb.org/~esr/writings/homesteading/ Linux-2-6-32-872271.html homesteading/, accessed 2010.05.01

Lerner, J. and Tirole, J. (2005) The Economics Schroer, J. and Hertel, G. (2009) “Voluntary of Technology Sharing: Open Source and Be- Engagement in an Open Web-Based Encyclo- yond”, Journal of Economic Perspectives, 19-2, pedia: Wikipedians and Why They Do It ”, pp. 99-120 Media Psychology, 12-1, January 2009, pp. 96- 120 Lessig, L. (2008) Remix: making art and commerce thrive in the hybrid economy, Pen- Tapscott, D. (1997) The Digital Economy: guin Press Promise and Peril In The Age of Networked Intelligence, Mc-Graw Hill Lévy, P (1994) L’intelligence collective. Pour une anthropologie du cyberspace, Editions la Tapscott, D. and Williams, A. (2006) Wiki- Découverte, Paris nomics: How Mass Collaboration Changes Everything, Portfolio Hardcover Magrassi, P. (1996) “What is the Average Soft- ware Development Productivity?”, Research Tovey, M. editor (2008) Collective Intelli- Note SPA-200-1281, GartnerGroup, Stamford, gence: Creating a Prosperous World at Peace, USA, February 1996 Earth Intelligence Network, preface

Raymonds, E. S. (1999) The Cathedral and the von Hippel, E. (2005) Democratizing Innova- Bazaar, O’Reilly Media tion, MIT Press

Raymonds, E. S. (2000a) Homesteading the von Hippel, E. and von Krogh, G. (2003) Noosphere, “Project Structures and Owner- “Open Source Software and the “Private- ship” chapter, Collective” Innovation Model: Issues for Or- http://catb.org/~esr/writings/homesteading/ ganization Science” Organization Science 14 homesteading/, accessed 2010.05.01 (2)208-223.

Raymonds, E. S. (2000b) Homesteading the Zittrain, J. (2008) The future of the internet Noosphere, “The Varieties of Hacker Ideology” and how to stop it, Yale University Press

Software Is Studied Design 11