Communication in Open Source Innovation

UNIVERSITY OF CALGARY

Communication in Open Source Innovation:

Key Roles of Shepherds and Users and Their Implications for Entrepreneurs

Banji Li

A THESIS

SUBMITTED TO THE FACULTY OF GRADUATE STUDIES

IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE

DEGREE OF MASTER OF ARTS

INTERDISCIPLINARY GRADUATE PROGRAM

CALGARY, ALBERTA

September, 2010

c Banji Li 2010

Library and Archives Bibliothèque et Canada Archives Canada

Published Heritage Direction du Branch Patrimoine de l’édition

395 Wellington Street 395, rue Wellington Ottawa ON K1A 0N4 Ottawa ON K1A 0N4 Canada Canada

Your file Votre référence ISBN: 978-0-494-69581-4 Our file Notre référence ISBN:978-0-494-69581-4

NOTICE: AVIS:

The author has granted a non- L’auteur a accordé une licence non exclusive exclusive license allowing Library and permettant à la Bibliothèque et Archives Archives Canada to reproduce, Canada de reproduire, publier, archiver, publish, archive, preserve, conserve, sauvegarder, conserver, transmettre au public communicate to the public by par télécommunication ou par l’Internet, prêter, telecommunication or on the Internet, distribuer et vendre des thèses partout dans le loan, distribute and sell theses monde, à des fins commerciales ou autres, sur worldwide, for commercial or non- support microforme, papier, électronique et/ou commercial purposes, in microform, autres formats. paper, electronic and/or any other formats. . The author retains copyright L’auteur conserve la propriété du droit d’auteur ownership and moral rights in this et des droits moraux qui protège cette thèse. Ni thesis. Neither the thesis nor la thèse ni des extraits substantiels de celle-ci substantial extracts from it may be ne doivent être imprimés ou autrement printed or otherwise reproduced reproduits sans son autorisation. without the author’s permission.

In compliance with the Canadian Conformément à la loi canadienne sur la Privacy Act some supporting forms protection de la vie privée, quelques may have been removed from this formulaires secondaires ont été enlevés de thesis. cette thèse.

While these forms may be included Bien que ces formulaires aient inclus dans in the document page count, their la pagination, il n’y aura aucun contenu removal does not represent any loss manquant. of content from the thesis.

Abstract

This thesis uses several sources of new primary data to test how communication relates to innovation in four environments. Its main hypothesis is that particular kinds of innovation succeed when shepherds communicate in particular ways when working. However, more substantial hypotheses are generated and explored. Using narratives, working documents, decision notes, and correspondence from shepherds and stakeholders of several innovations, the analysis shows detriments of deviating from formal rules of innovation processes, and posits generalizations.

ii Acknowledgements

This thesis was supported by my supervisor, Dr. Cooper H. Langford, my supervisory committee Dr. Richard Hawkins, Dr. Alan Smart, and Interdisciplinary Graduate Program Director

Dr. Tom Keenan. I thank them for each taking a risk at this journey’s outset (and I thank IGP’s

Pauline Fisk for masterfully managing the paperwork).

I am grateful for helpful comments from Kris Kotarski, Dr. Peter Phillips, Dale Miller, Dan

Meeking, Stefan Mendritzki, Christine Cheung, Mark Hopkins, and Ben Hoffman, and from the several anonymous reviewers of papers which became Chapter 3 and Appendix C. Several advisors and collaborators provided informal support and guidance, including Amal Umar,

Teresa Woo-Paw, and Anila Umar in Calgary. Friends on other campuses gave perspectives about being a human graduate student, including Dylan Grifﬁths, Mary Chan, and Graeme

Webb. Others helped me keep my research relevant to industry and policy.

I learned much from Phase II of the Innovation Systems Research Network MCRI. I’m privileged to have worked with team members in Calgary, including Dr. Cami Ryan, Dr. Patrick

Feng, Julie Alatiit, Kelly Bergstrom, Ray op’tLand, Sheila Taugher, Terry Ross, and others already mentioned. In addition, I am grateful for advice from several students and faculty on the ISRN team at Simon Fraser University, and to ISRN collaborators from elsewhere in

Canada who contributed in various ways, and to SSHRC for funding the network.

This thesis would not have been possible without teachers who provided interdisciplinary views of the world, despite the ofﬁcial curriculum: Mr. Gerry Ward and Mr. Taco Albrecht, nor without my parents for several reasons.

Finally, I thank and acknowledge several international netizens, who wish to remain name- less, on whom I relied for access to many books and papers cited herein.

iii iv

Table of Contents

Abstract ...... ii Acknowledgements ...... iii Table of Contents ...... iv List of Tables ...... viii List of Figures ...... ix 1 FOUNDATIONS AND LITERATURE REVIEW ...... 1 1.1 Why study change? ...... 2 1.2 Anthropological basis for studying innovation via computer mediated communication ...... 3 1.3 Why study communications during change implementation? ...... 4 1.3.1 Communication during the innovation process ...... 4 1.3.2 Some unknowns ...... 6 1.4 Conceptual framework preview ...... 7 1.5 Deﬁnitions ...... 8 1.5.1 Enhancement process ...... 9 1.5.2 Communication ...... 11 1.5.3 Enhancement environment ...... 13 1.5.4 Shepherds ...... 14 1.5.5 Stakeholders ...... 14 1.6 Conceptual framework in depth ...... 15 1.6.1 Open enhancement processes ...... 17 1.6.2 Communication patterns within enhancement processes ...... 17 1.7 Summary ...... 18 2 METHODS ...... 19 2.1 Innovation and governance ...... 19 2.2 Grounded theory ...... 20 2.3 Content analysis ...... 21 2.4 Classiﬁcation of innovations ...... 21 2.5 Why these methods ...... 22 2.6 Research data sources ...... 23 2.7 Research design ethics ...... 26 2.7.1 Participation ...... 26 2.7.2 Identity and privacy ...... 27 2.8 Approach ...... 30 3 STRUCTURAL ELEMENTS ...... 31 3.1 Introduction ...... 31 3.1.1 Innovation and governance ...... 32 3.1.2 Literature teview ...... 32 3.1.3 Powers of government ...... 33 3.1.4 Open enhancement environments ...... 34 3.2 Research questions ...... 35 v

3.2.1 Hypotheses ...... 35 3.3 Review of governance at the three organizations ...... 36 3.3.1 Similarities and differences ...... 36 3.3.2 Roles of contributors during enhancement processes ...... 39 3.4 Method and results ...... 40 3.4.1 Participation in innovative processes ...... 41 3.4.2 Public participation outside the enhancement process ...... 43 3.4.3 Lack of public participation outside the OEPs ...... 46 3.4.4 Public sources of ideas for enhancements in platforms and modules . . 48 3.4.5 Core vs. periphery ...... 50 3.5 Social implications of governance in OEEs ...... 54 3.5.1 Hypotheses reviewed ...... 54 3.5.2 Differences between organizations’ processes ...... 55 3.5.3 Inclusiveness and participation ...... 57 3.5.4 Key ﬁndings ...... 57 3.5.5 Research limitations ...... 59 4 EXAMINING ENHANCEMENT PROCESSES ...... 60 4.1 Introduction ...... 60 4.2 Hypotheses ...... 64 4.3 Methods ...... 65 4.3.1 Grounded theory ...... 65 4.3.2 Field data collection ...... 66 4.3.3 Content analysis ...... 66 4.4 A pilot effort ...... 68 4.4.1 Shape of the initial data ...... 73 4.4.2 The revised procedure ...... 75 4.5 First impressions from the revised procedure ...... 80 4.5.1 Resources ...... 80 4.5.2 Enhancement processes ...... 81 4.6 Case Studies ...... 84 4.6.1 Case 0: Apache HTTP Server log rotation trigger (Bug 44427) . . . . . 84 4.6.2 Case 1: Apache HTTP Server enhancement to support SNI (Bug 34607) 87 4.6.3 Case 2: Firefox secure connection warning (Bug 327181) ...... 92 4.6.4 Case 3: Firefox “Home” button relocation (Bug 404109) ...... 95 4.6.5 Case 4: Threaded Firefox windows (Bug 40848) ...... 99 4.6.6 Case 5: ARIN Minimum Allocation in the Caribbean Region (2008-4) . 104 4.6.7 Case 6: ARIN WHOIS integrity policy proposal (2008-7) ...... 108 4.6.8 Case 7: ARIN Identify invalid WHOIS POCs (2008-7, second round) . 115 4.7 Categories of communication ...... 118 4.8 Summary of observed communication patterns ...... 120 4.8.1 Information sources ...... 123 4.8.2 Information ﬂows ...... 124 4.8.3 Accessibility ...... 125 4.8.4 Use cases as evidence ...... 125 vi

4.8.5 Social factors ...... 126 4.8.6 Issues encountered ...... 127 4.9 Analysis ...... 129 4.10 Summary ...... 132 5 ANALYSIS ...... 134 5.1 Review of key findings ...... 134 5.1.1 Comparing the three open enhancement environments and their processes134 5.1.2 A modest emergent theory ...... 138 5.2 Eight emergent themes ...... 140 5.2.1 Theme A. Infrastructure facilitates but does not influence enhancement outcome ...... 140 5.2.2 Theme B. Poor internal communications results in poor outcomes . . . 141 5.2.3 Theme C. Poor communications with external stakeholders results in poor outcomes ...... 142 5.2.4 Theme D. Poorly timed communications results in poor outcomes . . . 146 5.2.5 Theme E. Poorly timed implementation results in poor outcomes . . . . 148 5.2.6 Theme F. A high rate of non-adoption is to be expected and possibly desirable ...... 151 5.2.7 Theme G. Lack of internal and external iteration results in poor outcomes154 5.2.8 Theme H. Enhancements which are not communicated as fulfilling their use cases do not succeed ...... 158 5.3 Summary ...... 159 6 CONCLUSIONS AND LIMITATIONS ...... 162 6.1 Some plausible patterns for communicating enhancement processes ...... 162 6.1.1 Rule 1. Communication must be appropriate to the enhancement it communicates at each phase ...... 163 6.1.2 Rule 2. Communication must embody the enhancement it communicates163 6.1.3 Rule 3. Shepherds and adopters must agree on the concept of an enhancement ...... 164 6.1.4 Summary ...... 165 6.2 Warnings ...... 166 6.2.1 Validity and reliability ...... 166 6.2.2 Further assumptions and limitations ...... 171 6.2.3 Assumptions ...... 171 6.2.4 Limitations ...... 174 6.3 Gaps filled ...... 175 6.4 Future work ...... 176 6.5 Final conclusions ...... 178 A LITERATURE CITED ...... 179 B CHAPTER 5 CASE STUDY QUOTATIONS ...... 193 B.1 Quotations ...... 193 B.2 Case 2 ...... 193 B.2.1 Quotation 2.1 ...... 193 B.3 Case 3 ...... 194 B.3.1 Quotation 3.1 ...... 194 B.4 Case 4 ...... 194 B.4.1 Quotation 4.1 ...... 194 B.4.2 Quotation 4.2 ...... 195 B.5 Case 5 ...... 195 B.5.1 Quotation 5.1 ...... 195 B.5.2 Quotation 5.2 ...... 195 B.6 Case 6 ...... 196 B.6.1 Quotation 6.1 ...... 196 B.6.2 Quotation 6.2 ...... 196 B.6.3 Quotation 6.3 ...... 196 B.6.4 Quotation 6.4 ...... 197 B.6.5 Quotation 6.5 ...... 197 B.6.6 Quotation 6.6 ...... 198 B.6.7 Quotation 6.7 ...... 198 C CLASSIFYING ENHANCEMENTS AND INNOVATIONS ...... 199 C.1 Introduction ...... 199 C.2 Development of the framework ...... 200 C.3 Hypothesis ...... 202 C.4 Method ...... 202 C.5 Results (CMA data) ...... 203 C.6 Results (OEE data) ...... 207 C.7 Analysis ...... 209 C.7.1 Comparing enhancements and innovations ...... 210 C.7.2 Shepherds, entrepreneurs, and bureaucracies ...... 211 C.7.3 Validity and reliability ...... 213 C.7.4 Implications ...... 214 C.8 Conclusions ...... 215 D Glossary ...... 217

vii List of Tables

3.1 Study periods for data collection at three projects studied...... 41 3.2 Participation in the three projects during study period, as counted on author based on discussion lists and Bugzillas (collected by author during September 2009)...... 42 3.3 Number of eligible participants, participation by one-time contributors (OTC) and governance as counted by author...... 49

4.1 Overviews of Apache, Firefox and ARIN mailing lists and Bugzillas. Sources: projects’ mailing list charters and indexes, Bugzilla archives...... 74 4.2 Author’s summary of discussion regarding policy proposal 2008-7 at Septem- ber 2008 ARIN meeting...... 113

C.1 Change profiles for 27 identified innovations in CMA data...... 204 C.2 Change profiles for 10 identified enhancements in OEE data...... 205 C.3 Characteristics of enhancements from the open enhancement environments. . . 209

viii List of Figures

1.1 The enhancement process model to be employed...... 16 1.2 The context of the enhancement process model to be employed...... 16

3.1 Distribution of governing bodies’ responsibilities at three organizations. (Num- ber of salaried employees given as full-time equivalents (FTE). Typical innovation pathways are indicated. Outlines indicate infrequently exercised formal or de facto powers. Sources: structures and staff sizes are based on project governance documents, Bugzillas, and contact lists; constituent sizes are approximations based on project and third-party estimates.) * indicates that the number of role holders is relatively ﬁxed, but the holders of the role change. . . 37 3.2 Ideas, enhancements logged, changes accepted, and features at three projects during the study period. Sources: ARIN-ppml, Apache Bugzilla, Mozilla Bugzilla, discussion lists, product documentation...... 42 3.3 Ideas, enhancements logged, changes accepted, and features at three Apache projects. Sources: projects’ discussion forums, Bugzillas, product documentation...... 44 3.4 Ideas, enhancements logged, changes accepted, and features for four Firefox plug-ins. Sources: plug-in projects’ discussion forums, Bugzillas, product documentation...... 45 3.5 Participation rate, ideas discussed per active participant; ideas discussed per eligible participant, changes accepted per active participant; and changes accepted per eligible participant for ten projects studied...... 50 3.6 Number of ideas discussed vs. number of changes accepted...... 51 3.7 Participation rate vs. ideas discussed or changes accepted per active or eligible participant...... 52 3.8 Ideas discussed per eligible or active participant vs. changes accepted per eligible or active participant...... 53

4.1 Summary of communication types ...... 121 4.2 Summary of communication types, continued ...... 122

ix 1

Chapter 1

FOUNDATIONS AND LITERATURE REVIEW

This thesis reports on ethnographic studies of three communities that maintain global on-line infrastructures. It examines their formal and informal rules of organization, work, and communication to identify patterns linking their new ideas to the progress by which those ideas become adopted or not.

Public work and communication logs from the Apache HTTP Server project, the Mozilla

Firefox project, and the American Registry for Internet Numbers Policy Development Process are analyzed to identify patterns and procedures use by participants to consider and implement ideas. This thesis argues: a) that formal structures only slightly affect work or communication but personal interactions appear crucial; b) that work enabled by computer mediated communications—as disclosed in intentionally public records—resemble ofﬂine work patterns; and c) that communications and personal actions are more important than artifacts to express new ways of thinking and doing.

This research begins with a framework thought to turn ideas into enhancements: infrastructure, implementation, and participants. Isolating and examining the roles and effects of each component in the enhancement process allowed discovery of key communication patterns among shepherds and potential adopters. This thesis proceeds as follows.

Chapter 1 continues with a brief review locating the reported work within the broader context of research in the ﬁelds of anthropology, communication studies, and innovation research.

A conceptual framework is detailed as a way to explore the data.

Chapter 2 introduces the methodology, the open enhancement environments studied, and the data sources for this research.

Chapter 3 identiﬁes the loci of interesting phenomena within the three open enhance- 2 ment environments studied, and reports on their functions and structures. It also provides an overview of the inputs and outputs to the three open environments’ enhancement processes.

Chapter 4 reports and analyses data from case studies of enhancements to build a model about work, communication, and enhancement success. In particular, it uses data about open enhancement processes that did not succeed to extract requirements for success, providing examples and counter-examples.

Chapter 5 reﬂects on the research question, data, and model to form general hypotheses about the relationships between communication, participants, and enhancement processes.

Chapter 6 concludes the thesis and explores implications of the ﬁndings. Primarily, the present research demonstrates using content analysis of public work records to identify effects of individual action to facilitate or obstruct the work of entire technical and policy communities. It also suggests several strategies that may be used to help, or hinder, computer-mediated collaborations.

Appendix B provides a list of acronyms.

Appendix C tests whether the open enhancement environments studied and local organizations produce enhancements and innovations can be compared by objectives and outcomes.

The present research contributes to anthropology a new entry point to analyze large text archives of open on-line communities, and to the innovation literature a grounded view of entrepreneurship in on-line environments.

1.1 Why study change?

It’s easy to gather academic and popular articles about the importance of innovation. Seemingly every strategic plan or policy document or conference produced in the last decade contains the word “innovation” prominently in its goals. Through innovation, we try to focus resources to enhance our condition, as though applying sufﬁcient innovation will bring us apparently 3 forward. But we know that not all innovations are “good” (e.g., Baumol, 1996).

But plans for innovation do not universally succeed. Thus innovation is neither natural nor inevitable. Scholarship and applied research—considering how innovation may be both purposeful and impeded—has generated 1.5 million publications (according to Google Scholar), with tens or hundreds of thousands of publications on each of the adjectivised varieties (“industrial innovation”, “social innovation”, “corporate innovation”, “policy innovation”, etc.).

Understanding how best to work toward desirable innovation could beneﬁt many human affairs.

1.2 Anthropological basis for studying innovation via computer mediated

communication

Social anthropology provided foundations to study economics, political science, and communications. We use many of their methods and concepts to study how we innovate. As we include computer mediated communication (CMC) in more collaborations, CMC has become a research focus as reviewed by Garcia et al. (2009). Despite not passing many tacit cues communicated in person, much apparent novelty ranging from developing President Obama’s election campaign machinery (Obama for America, 2008) to international SARS coronavirus research (Drazen and Campion, 2003) have relied on CMC.

The research reported herein uses CMC’s limits on communication channels, modes, and on content diversity to elicit and codify communication patterns that participants used while making purposeful changes. Communications archives from three international organizations are the primary data source. The archives contain comprehensive sets of detailed working and formal documents produced by individuals who developed ideas into adoptable changes. 4

1.3 Why study communications during change implementation?

If innovation is interactive and interpersonal, requiring an inventor to at least communicate a new idea to some potential adopters (e.g., as reviewed by Jayasinghe et al., 2007), we should understand how that communication affects the outcome. Understanding links between desired changes and how those changes are communicated using limited CMC may tell us how to better support new ideas. The following review of literature about communication in innovation processes highlights speciﬁc gaps in current knowledge.

1.3.1 Communication during the innovation process

Research about innovation in business management and competition is extensive (e.g., Tidd et al., 1997; von Hippel, 1998); comparatively less is known about contents of communications during innovation processes, or about innovation failure. Directly measurable explicit inputs and outcomes of industrial innovation processes (e.g., OECD, 2005) often overshadow more difﬁcult to quantify social processes and knowledge transfer through formal and informal linkages. Recent studies in game theory have examined interpersonal decisions and interactions in durable groups (e.g., as reviewed by Brabisch and Rusinowska, 2010) but rarely situate models in an innovation or communications framework with many transient or one-way interactions. Studies of participatory or committee-based decision-making and communications therein (e.g., Gerling et al., 2005) illuminate those types of processes when voting and consistent committee composition may be assumed, but have limited reach beyond formal settings. Foucault might characterize the relationships between innovation process participants through expressions of power, objectives, and institutions in their decision-making (e.g., Fou- cault, 2003). The current research counts on the presence of some structure in which ideas, communications and actions occur toward innovation goals. Unlike Project SAPPHO which attempted to quantify a hundred factors around successful and non-successful innovations in 5 commercial chemical processes and scientiﬁc instruments (Rothwell et al., 1974), the present research examines change processes and communication before ideas reach mass markets.

Rogers’ (2003, pp. 94–100) typology of diffusion research describes eight varieties of diffusion analysis: three varieties about the time factor of innovation adoption (“earliness of know- ing about innovations”, “rate of adoption of different innovations in a social system”, “rate of adoption in different social systems”); two varieties about individuals’ effects on their environments (“innovativeness”, “opinion leadership”); one variety about consequences of innovation; and three varieties about communicating innovations (“diffusion networks”, “rate of adoption in different social systems”, “communication channel usage”). Of the three varieties concerning communication, all were constructed around the diffusion of finished innovations among adopters and potential adopters, and none focused on the process leading to the finished product. (The present thesis does not attempt to define exactly when innovations are complete, but is informed by the workflows and histories of particular ideas.) Only in 2005 did the OECD

Oslo Manual emphasize communication as integral to the innovation process. Describing differences from the previous edition, it states: “Evaluation of linkages is expanded because of the importance of knowledge ﬂows among ﬁrms and other organisations for the development and diffusion of innovations” (para. 8).

Amadi-Echendu (2007) found that among many inputs, outputs and opportunities, innovation process participants’ actions reﬂected their thinking styles, and that the thinking style strongly inﬂuences how “the entrepreneur initiates, the entrepreneurial process nurtures, and entrepreneurship sustains the commercialization of intellectual assets into useful activities”.

The phases of initiating, nurturing and sustaining an innovative process assume effective communication in order to identify limits and motives, apply resources to affect a creative change, and to propagate solutions and new resources.

Tapscott and Williams (2006, pp. 10–15) found that small numbers of individuals may cooperate to generate new things, despite geographic distance. Globalization avails any en- 6 trepreneur of all eligible suppliers and ideas to the extent that “collaborate or perish” has become an international rule of business (Tapscott and Williams, 2006, pg. 62). Corporations who seek and receive solutions to problems from independent researchers worldwide with little communication in person (Tapscott and Williams, 2006, pg. 106) show that externalizing explicit knowledge via CMC during innovation processes is key to collaboration.

Henderson and Clark (1990), and Utterback (1994, pg. 200), found that “radical” innovations cause major disruptive changes in the marketplace for producers and consumers, often yielding new producers and market leaders. A radical innovation’s appearance indicates effective communication after invention. The almost continuous supply and incorporation of “incremental” innovations slowly changes products in the marketplace without necessarily rendering previous products useless, and requires group and personal communication to be maintained.

In both cases, an adopted innovation has required extensive communications.

Although “communication” has been broadly used here, the communication of interest to the present thesis occurs between individuals as they develop ideas into something adoptable.

For this research, “enhancements” include the class of proposals and realized changes defined by the participants of the three organizations studied, explicitly communicated in a public record. This operational definition is used by participants of the three organizations studied, although one organization uses the more explicit label “Policy Proposal” instead of “enhancement”. As such, “enhancements” may broadly include or lead to ideas, inventions, and innovations as popularly and scholastically defined, but it is not assumed that the three organizations studied produce changes stereotyped by the common definitions of “innovation”.1.

1.3.2 Some unknowns

In total, much has been studied and written about communication with innovation based on partial views of outcomes, but complete innovation processes have been relatively inaccessible

1The comparability of enhancements studied herein and innovations in general is examined in Appendix C 7 for direct examination. Nor have complete records of innovation processes been often compared to each other. This research draws from a broad literature to test a few important ideas pertaining to enhancement processes the environments studied, with the assumption that they are broadly similar to innovation processes. It does so in order to determine how well our assumptions about the decisions and actions that should occur in innovation processes match with those of three particular environments. Concordance or discordance both inform possible improvements to our theories of innovation, and tell us how to better study open enhancement environments.

The next section introduces a conceptual framework which permits systematic exploration of the data for evidence supporting or refuting theory, without assuming that any particular theory most strongly applies. Subsequent chapters detail and explain theoretical and methodological contexts as required.

1.4 Conceptual framework preview

The present framework divides enhancement processes into four primary aspects: infrastructure, work, communication, and enhancement characteristics. The technical effort and circumstance to implement an enhancement is roughly captured by data about the infrastructure hous- ing an enhancement process, while the social effort and circumstance among stakeholders is roughly captured by archives of CMC. Those two aspects (infrastructure and communication) intersect through work undertaken to implement an enhancement, and through the objective characteristics of each enhancement.

Within this framework, research will explore the following main research question: How do communication patterns during enhancement processes relate to the success or failure of those processes to yield enhancements?

This research analyses records of infrastructure, communication, activities, and enhance- 8 ment characteristics to relate communication to success of enhancements. A substantial framework is given after the following deﬁnitions.

1.5 Deﬁnitions

From this conceptual framework, it is helpful to carefully define specific elements to study, as they relate to broader communication and innovation theory. (In reference to specific ideas and outcomes studied, the term “enhancement” is used in preference to the term “innovation” since

“enhancement” is the term used in the source data, and since “innovation” carries unneeded ideological baggage.)

Recall that an enhancement refers to any intentional action to durably change the way stakeholders do things (usually for some benefit to the user). This definition is purposefully broadly inclusive, so that specific varieties of innovation may be allowed to emerge on their own terms from the data. Specific enhancements studied include narrow technical changes possibly regarded as pure in some senses, as well as broader changes combining industrial, social and conceptual changes. A potential enhancement is an enhancement in process, in that it has not yet been adopted by its intended users, and thus is neither a successful enhancement, nor a non-successful enhancement.

A non-successful enhancement is one which has not been adopted by its intended users for the enhancement’s intended purpose. An enhancement may be non-successful because it has been formally rejected for its intended purpose, because it cannot be used for its intended purpose, because it lacked supporters, or for other reasons. A potential enhancement which has not been adopted does not automatically fail, and non-successful enhancements may be subsequently adopted.

(New ideas or changes which are not brought about for some advantage, and collective actions which seek to bring about change without specifying any particular novelty, are both 9 interesting and may contribute to innovation, but fall outside the current scope.)

1.5.1 Enhancement process

Following the Oslo Manual, this research considers an enhancement process to “include all scientiﬁc, technological, organisational, ﬁnancial and commercial steps which actually lead, or are intended to lead, to the implementation of innovations” (OECD, 2005, para. 40), without bias toward any particular scale or variety of change. An “enhancement process” therefore embodies the temporal sequence of activities and conditions in which a problem precedes an idea to solve the problem, which precedes the enhancement’s implementation and application.

Further, an enhancement process embodies the process by which “the existing level of compe- tence of the problem solving, decision-making and implementing activities is not reduced and is preferably raised” and requires one or more individuals to commit planning and resources to the enhancement, and to follow through on its execution (Argyris, 1970). Since enhancement processes occur through cooperation, “collective action requires some demonstration that a group not only did something, but that they did something intentionally to achieve particular goals” (Poteete and Ostrom, 2004). This description restates the contours of the framework introduced above, but not necessarily its dynamics.

The processes studied herein appear to formally implement (Chapter 3) the following broad phases familiar to studies of innovation: inventing, improving, adopting, and iterating.

Inventing

As Kauffman points out (2000, ch. 9), the vast majority of inventions and new ideas result from recombining previous ideas. The act of inventing by an individual or small team—acting in a formal or informal research capacity—produces a previously unknown object, concept or process, resulting in an invention that may or may not be manifest in a tangible way. Invent- ing captures many possible original sources of ideas and enhancements including: personal insight, mimicking nature, directed research, desperation, serendipity, peer pressure, and other 10 inputs encountered. Here, the communications of interest are expected to be largely ad hoc between the inventor and other individuals in personal and professional networks pertaining to the invention (Nonaka and Takeuchi, 1995, pp. 95–96). The result of such communication may be expected to range from an idea through a prototype to a marketable product.

Improving

Improving an invention means to select one or more inventions having potentially desirable uses (Nonaka and Takeuchi, 1995, pg. 122), and then deliberately and repeatedly permutat- ing particular characteristics of those inventions to produce something better in context. One or more personal or group actors communicate, decide and carry out the permutation process using input from both internal sources (personal or collective actors such as colleagues, managers, testers, etc.) and external sources (personal or collective actors such as funding agencies, shareholders, potential users). Some of these roles may not be encountered in the current research. Here, the communications of interest are among the set of individuals directly working on the invention (internal actors), and between that set of individuals and external stakeholders and opinion leaders, etc. (external actors).

Adopting

An adoptable invention—including sufficient hardware and software to actuate the invention— is put into practice when adopted (e.g., Rogers, 1962, pg. 79). This is one possible end point in the enhancement process. Public and mass communication among innovators and adopters are well characterized in existing innovation diffusion literature. Radical innovation processes may end here as the new product cycles through incremental or process innovation to reduce costs or increase efficiencies. Another possible endpoint is further refinements through iteration.

Iterating

In iteration, an enhancement is combined with another idea or resource to produce a new invention, which re-enters the enhancement process. Iteration is viewed by Utterback (1995, 11 pg. 99) as part of a continuous innovation process, in which waves of opportunities always arrive for new participants to re-exploit an innovation by fundamentally altering characteristics of its dominant design. Iteration is strongly stimulated when producers and consumers are co- located, encouraging rapid and effective communication. According to Porter (1998, pg. 85),

“Cluster development is often particularly vibrant at the intersection of clusters, where insights, skills, and technologies from various ﬁelds merge, sparking innovation and new businesses”.

According to Dosi (1982), once an innovation is established within a particular perspective of a selected set of problems to be solved using a particular model or pattern, the development of that innovation occurs along a technological trajectory, “the pattern of normal’ problem solving activity (i.e. of progress’) on the ground of a technological paradigm”. Examples in Chapter 4 highlight the role of iteration in the enhancement process.

1.5.2 Communication

British cognitive scientist Colin Cherry’s classic On Human Communication (1966, pp. 3–7) explored several deﬁnitions of communication of interest to practitioners in various disciplines.

First, that “communication is essentially a social affair” is useful in the enhancement context since individuals and organizational entities conducting enhancement interact with each other within a mutually understood collaborative environment. Second, that “the very word ‘communicate’ means ‘share’” is also of value since to share information is to attempt to impart an understanding of that information. Since developing and diffusing enhancements are ultimately sharing processes, expressions of novelty must be in reference to mutually understood rules and boundaries. Third, that “communication means organization” merely supports the intuition that enhancements are merely organizations or recombinations of people, things, data and knowledge in new ways. To organize information also means to purposefully arrange information to yield knowledge of greater utility, acts viewed from the enhancement perspective as knowledge creation and diffusion. Finally, that “communication is not the response [to a 12 stimulus] itself but is essentially the relationship set up by the transmission of stimuli and the evocation of responses” is helpful since the enhancement process requires many potential combinations of stimuli and responses, but which are documented well in the chosen data set.

Communication is deﬁned for present purposes as the interpersonal information exchanges carried out (by entrepreneurs, stakeholders, users, and others) during an enhancement process.

The contents of communication can be of several varieties. According to Cherry, “‘Infor- mation content’ is not a commodity, but rather a potential of the signals... signals possess a potential to communicate, and the information communicated will depend upon the choice of signals in any particular channel of communication with relation to the receiver’s expectan- cies” (Cherry, 1966, pg. 13). According to Rogers (1995, pg. 336), the most effective “change agents” are the individuals who carry new information and apply some degree of persuasion to non-users of a particular innovation, that are “marginal ﬁgure[s] with one foot in each of two worlds”. Change agents are capable of effecting change through the information they carry, and have also the capability to be changed.

In Clark’s (1987, pg. 67) system of market signals, change agents are the essential communicators in the diffusion of innovation among innovators. The communicator acting at an interpersonal or group level must concurrently communicate the tacit knowledge surrounding an innovation along with communicating the codified message itself. It is compelling to study communications which bundles both the codified technical content of the message, and the bearer of the message whose form and reputation may prejudice the reception of the communication (Littlejohn and Foss, 2005, pg. 71). Analysis of the current data set explicates many such comparable factors which have formerly been difficult to access objectively.

Since the data set (to be fully described in section 3.6) consists only of explicit communications among shepherds and stakeholders during enhancement processes, communications content is deﬁned as the textual and image data contained in such communications. 13

1.5.3 Enhancement environment

This framework, like many before it, assumes that knowledge is at least an input into the enhancement process via records and the human participants, and that such input is communicated during that process. Examining communication during an enhancement process requires a way to record the modes and opportunities for knowledge transfer as practiced around an enhancement. But the sources of information from which an inventor might be inspired has geographic and social limits.

The parties to a knowledge transfer may be anyone, but practically the data set is limited to providing data about a subset of transfers among “shepherds” (a term originating from the data used in preference to the term “entrepreneur” to indicate the person in charge of an idea) in charge of managing individual enhancement processes, bureaucrats (individuals who operate the enhancement environments, see section 1.6.4), and stakeholders. As the product of networked people (Tapescott and Williams, 2006, pg. 153), knowledge may be used by both the knowledge giver and the knowledge recipient simultaneously to the beneﬁt of both. The very act of communicating knowledge may generate new knowledge by virtue of the need to understand and codify it in a new context understandable to the recipient.

Although new technologies enable rapid communication and collaboration (considered in section 1.7.1), common location facilitates contact among interested individuals. Gertler (2002, pg. 118) observed that collaboration and problem solving, especially with complex technological processes and products, occurs more efﬁciently in person, despite rapid advancements in information and communication technologies. Such geographically proximate communication is undoubtedly facilitated by arrangement of industry in clusters but it would be negligent not to look outside of strict, geographic bounds. An increasing number of globally distributed efforts mediated by impersonal communications demonstrate the successes of CMC for collaboration.

Thus, analysis requires an “enhancement environment”, deﬁned as the assemblage of involved individuals, resources, ideas, and outputs sharing a distinguishable immediate purpose. 14

A ﬁrm, non-governmental organization, project, or individual may form an enhancement environment and have a goal or mission, which is met through coordinating work of several de- partments which may each form a separate enhancement environment, and within each department, individual projects may form their own enhancement environments. The enhancement environment, therefore, also includes the government and governance contexts.

1.5.4 Shepherds

In Schumpeter’s Theory of Economic Development (2e), the communication of a new idea in the economic realm is the responsibility of the entrepreneur who originates the idea. “It is the producer who as a rule initiates economic change, and consumers are educated by him if necessary” (1934, pg. 65). Schumpeter’s entrepreneur brings innovative new products onto the market for the purpose of gaining entrepreneurial proﬁt (1934, pg. 72), which he may then re-invest into making new products and new means of production. Like Schumpeter’s “entrepreneurs”, shepherds in the enhancement environments studied may or may not be inventors or originators of new ideas, and may simply be assigned to champion particular ideas by others.

A particular enhancement may have multiple shepherds throughout its enhancement process.

Although the entrepreneurial role may become embodied in individuals for individual and collective interest, the present work and its data primarily concern the collective interests and actions of organizations.

1.5.5 Stakeholders

An enhancement processes’ stakeholders include any individuals or groups who contribute information to an enhancement process directly or through another participant, or who could be affected by the outcome of an enhancement process. (As this set is large, this research only considers stakeholders’ views which are recorded in the enhancement processes.) Formal or informal subsets of shepherds and stakeholders of a particular enhancement may pursue 15 speciﬁc goals. At the outset, this research does not assume that the pursuit of enhancements at one level of aggregation affects enhancement at other levels. However, evidence of individuals bridging adjoining enhancement or environments would appear in the data as individuals whose communications content appear in the records of multiple enhancements.

1.6 Conceptual framework in depth

Recall that the framework to be employed divides the enhancement process into four primary aspects. The technical effort and circumstance to assemble an enhancement is roughly captured by data about infrastructure (presumed to be static), while the social effort and circumstance involving stakeholders in the enhancement process is roughly captured by data about communication. Infrastructure and communication are linked through the activities undertaken to implement the enhancement, and through the objective characteristics of the enhancement.

Within an infrastructure, individuals are thought to use communication to coordinate activities around particular enhancements with particular characteristics (Figure 1.1). The present research seeks to characterize each of those four aspects of the enhancement process by several quantitative and qualitative criteria as originating themes for the grounded theory approach employed.

Slightly more formally, in this framework, the dependent variable for analysis is the degree to which a worked enhancement succeeds, as shaped by the communications employed during the enhancement process. In turn, the communications employed is thought to be shaped by the infrastructure and activities of the environment in which enhancement occur.

This formulation implies a chronological order which is convenient as it is the order in which the data sources are organized in the enhancement environments, and the order in which the enhancement environments claim to operate their enhancement processes. (This progression may occur at each of multiple phases of an enhancement process.) However, it does not 16

Infrastructure Communications Innovation Characteristics Activities

Figure 1.1: The enhancement process model to be employed.

Infrastructure

Idea dummy Communications Innovation Characteristics Success/Failure

Activities

Figure 1.2: The context of the enhancement process model to be employed. recognize a source of ideas to be worked in the enhancement environments, nor does it acknowledge whether an enhancement has succeeded or failed. Figure 1.2 is a more complete estimation of the enhancement environments and processes.

For now, the sources of ideas, prior to their appearance in the enhancement environments studied, are considered to simply exist (although they receive more consideration later). The middle activity is an interactive process allowing participants to combine inputs from the technical and social efforts with each other toward the common goal of the enhancement. Each iteration of effort feeds into another, since changes brought about by enhancement and the environments in which they take place are highly dependent on rapid feedback of valid information (Argyris, 1970, pg. 7). The success of an enhancement will be measured by its adoption at various stages prior to and including its ultimate release to the public.

The on-line environment provides an interesting setting in which to study communication within the enhancement process via this framework. In research employing ethnography and analysis of communication, such tacit features of communication as identities of the participants, body language, tone of voice, etc. are readily visible to the researcher and can provide 17 a wealth of information not contained in explicit spoken words (Baird et al., 2000). However, the computer-mediated on-line setting largely prevents communicating via such tacit channels, forcing communicators to express themselves entirely using the textual or visual forms.2 This research leverages the limited on-line setting to extract and study those communications elements essential to successful collaboration around a variety of innovation. Speciﬁcally, this research examines records generated by open enhancement processes as its data source to reveal details of those processes.

1.6.1 Open enhancement processes

Broadly, an open enhancement process (OEP) is defined as one in which the majority of activities and decisions are explicitly valid objects of public scrutiny and input. Its definition encompasses those defined by Free and Open Source software (OSI, n.d.), as well as other efforts following open principles which do not primarily produce software.

Within the set of studied organizations practicing OEPs, each organization is operated by a relatively small number of paid or unpaid organizational and administrative leaders mandated to seek the participation of hundreds or thousands of public collaborators. Leaders and contributors may communicate with each other using all of the traditional means of direct and group contact at meetings and gatherings, but they primarily use collaboration technologies such as documentation wikis, mailing lists, revision-controlled software repositories and on-line forums, which are all open to the public (to be detailed in Chapter 3). The collective mediums and resources in which OEPs occur is the open enhancement environment (OEE).

1.6.2 Communication patterns within enhancement processes

Within any organization carrying out changes, the task of spreading information among collaborators is thought to be both hindered and helped by features of the organization, and by the

2Some participants meet and communicate off-line or in different on-line contexts than studied herein. Chapter 4 provides context to some of those other environments. 18 participants involved. Since ideas of interest already exist within the organization, some barriers to trialability and credibility may be diminished or are easily mitigated by communications from internal champions of the innovation. Other barriers, such as institutional knowledge, beliefs or practices, may more strongly hinder adoption by potential internal adopters than by potential adopters in the outside world.

Gertler (2002, pg. 115) points out that close communications between technology producers and technology consumers are important to the success of technology adoption and production. Close personal contact allows both parties to gauge and establish trust with respect to individuals and processes. From the perspective of a firm looking to implement new technology, communication facilitated by close proximity to the technology supplier increases returns on capital investment by enhancing efficient use of the new technology product. Within the current research, idea sources and adopters do not form geographic clusters, but participants of the OEPs studied do interact in relatively well defined systems with established membership, norms and circulation of knowledge.

Communication patterns are therefore deﬁned as sets of interactions generated and experienced by participants of OEPs. Even though humans have an inﬁnite variety of things they could communicate with each other, it is unlikely that we continuously invent new methods and vehicles to share meaning. The fact that institutionalized enhancement processes with communications exist implies that participants simply vary the content.

1.7 Summary

This chapter has outlined the motivations for studying enhancements and their communications carried out in open enhancement environments, and the framework which will be used to do so. The next chapter outlines methods to address the research question. Chapters 3–5 outline and explore infrastructure, implementation, communication, and enhancement outcomes. 19

Chapter 2

METHODS

The research conducted for this thesis used methods to break down and study the infrastructures, activities, and communications within three organizations employing open enhancement processes. It does so to identify how features of open enhancement environments affect the inclusion of stakeholders in the organizations’ innovative practices and their effects on outcomes.

This research purposefully perceives enhancement from the viewpoint of the shepherds, organizations, and stakeholders performing enhancement work. This permits analysis and con-

ﬁrmation of the personal and organizational motives and understandings behind the work to be based on the beliefs and values of the shepherds at the time they worked on the enhancements. Taking this perspective also unlinks the enhancements from the beliefs and values of the analyst or other third party. This analysis does not judge whether or not an enhancement is worth doing, leaving that to the stakeholders, but does judge how and how well an OEP met the shepherds’ stated and revealed objectives for their enhancements.

The following overview of approaches is expanded in subsequent chapters.

2.1 Innovation and governance

Governance coordinates work toward common objectives, including beneficial new ideas, in exchange for diminished individual freedom. The government of a nation state, the board of directors of a corporation, and the social norms of a reoccurring grouping of people, all provide governance. Markman, Balkin, and Schjoedt (2001) examined governing innovation process in entrepreneurial firms, with respect to effects of board structure and venture capital-backed monetary incentives for risk-taking innovations among seed-stage firms. But, the organizations 20 studied presently are significantly more mature; are not backed by venture capital (nor, generally, for profit); have boards of directors who (mostly) do not perform innovation work; and explicitly encourage internal entrepreneurship. Mockus et al. (2002) examined technical Open

Source software development processes at Apache and Mozilla, via internal interactions with software source code repositories, error rates, etc. under a software development paradigm. The current research considers from a governance perspective the organizational structures, public participation, processes around ideas, inventions, and adoption at those two organizations, and at a quasi-government organization.

2.2 Grounded theory

Grounded theory is used here to understand communication patterns arising from OEPs as recorded through working documents by their participants, supplemented by accounts of the

OEEs as described by participants. This method relies on transcripts and ethnographic observations (Glaser and Strauss, 1967) as a starting point to deﬁne the processes and environments to be studied. It also draws upon external data about identiﬁed OEPs and their environments to triangulate views supplied by informants with objective and subjective realities.

The grounded theory approach maximizes sensitivity of data collection to the endogenous conditions of selected OEEs as the basis of theory development and comparison. This analysis is not interested only in ﬁnding evidence supporting the many existing theories about technical change. It certainly draws from them to provide assurance that the phenomena observed by the current method, and preliminary explanations, are reasonable compared to previous work.

However, this thesis seeks also to posit novel theory offering more than alternative paths to the same explanations of the same observations, and more than reasons for their refutation.

Instead, it seeks to observe more of that which is observable but which is not considered by current explanations about innovation. 21

2.3 Content analysis

Content analysis enables “the objective, systematic, and quantitative description of the manifest content of communication” (Berelson, 1952, pg. 18). “Simulation of interviews” was reviewed as a useful method to “obtain survey-type data through the medium of the respondent’s’ writing” (Krippendorff, 1980, pp. 79–80). Content analysis of narratives as a method to study innovation has been used with success by Barringer et al. (2005) in their examination of founder and ﬁrm characteristics with respect to ﬁrm growth rates. The methods employed presently rely heavily on the same source materials as the participants use to gain an approxi- mate understanding of the important (to the participants) features of their conversations.

2.4 Classiﬁcation of innovations

Innovations have been categorized by various approaches, including Schumpeter’s (1942) sources of competitive advantage; Nelson and Winter’s (1982, pp. 128–129) “routine” change and “innovations”; and Henderson and Clark’s (1990) “modular” and “architectural” innovations. Other systems that consider industrial and scientiﬁc innovations abound (Tornatzky et al., 1983). Innovation and invention processes have been likewise categorized. Arthur (2007) proposed that an invention links a purpose or need with an exploitable effect satisfying it. As in Khun (1962), creating new things requires inputs such as existing materials, knowledge, functionalities, etc. and reconﬁgures their relationships to yield novelty. To understand inspira- tions for change, Schmookler (1966) analyzed endogenous technical change, while Lancaster

(1966) examined consumer-demand for new capabilities. The OECD’s Oslo and Frascati manuals (OECD 2005; OECD 2002) offer standards to measure research and development activities on a macro scale, but they emphasize economics of agglomerated technical change rather than the dynamics of individual creative units. The classification literature’s focus emphasizes innovation dependent on scientific or technical change, and thus favors markets and indus- 22 trial processes, neglecting analysis of intellectual and social dimensions. As well, quantitative comparability among categorization systems is often difficult to mobilize. The present research classifies enhancements by decomposing them into objectives and outcomes, and then testing whether they may also be usefully classified as innovations as above.

2.5 Why these methods

The data source provided a rare opportunity to study the OEEs with respect to responses to proposed, anticipated, successful, and non-successful enhancements. Challenges of data collection normally faced by social anthropology with respect to reﬂexiveness and ethics are minimized or held constant in the current data set by studying groups which operate by choice and by default as subjects of open and public scrutiny. If such OEEs operate in a manner comparable to innovation environments in general (see Appendix C), this work would provide valuable insights into the study of innovation in general. If OEEs are atypical, this work would provide insights into a growing range of innovation environments relying on CMC.

Applying grounded theory to the current data sources provides additional advantages. In contrast to survey methods which attempt to force informants to distill their multitude and diversity experiences and beliefs into indicators along a limited and externally imposed model of their enhancement process, the grounded theory approach leverages the fact that the communications during the OEP are forced to be explicit and evidence-based in the OEEs studied. In addition, since the transcription was free in this case, techniques accepting a larger volume of data than questionnaire responses merit consideration.

With respect to reusing existing categories of innovation, it was previously found that the decomposition method used herein provides data to quantitatively categorize superficially different kinds of innovation with a common set of empiric categories (Li, 2009). The method also maintained compatibility with existing categorization frameworks in the literature. De- 23 spite the fact that the ethnographic method, guided interview data, and examining case studies enables narratives to draw out broad and systematic features of the environment under study, the ability to internally and externally triangulate categorizations adds confidence to findings.

Content analysis enables external end users of enhancements to be distinguished from internal shepherds within the OEEs studied as sources of information. This ensures that data about enhancements may be read with some external validity built into the data itself with respect to the beneﬁts of enhancements as evaluated by the prospective beneﬁciaries. Such a reading also ensures the participants and analyst both interpret data sources in a similar manner.

Finally, mechanically parsing well-defined and explicit fields in Bugzilla databases and source code repositories has reliably generated data for other authors studying software development (Mockus et al., 2002). The present, more difficult, task is analysing enhancement processes with human implications beyond whether a computer executes bits of source code as intended. Analysing the free-text content of Bugzillas and mailing lists requires more focused resources than operating scripted database queries or keyword matching.

2.6 Research data sources

The two Open Source projects, Apache HTTP Server and Mozilla Firefox, and ARIN which uses an open Policy Development Process but is not formally Open Source, were chosen since they all explicitly publish salient details of their enhancement processes. Mockus et al. (2002) provided detailed descriptions of the Apache and Firefox software development processes and management structures. Participants in projects employing OEPs are encouraged to be verbose so that new contributors could (theoretically) easily acquire sufﬁcient knowledge to contribute effectively through reading the explicit notes from the enhancement processes (Ray- mond, 2000). Proposals for new software features of any scale or scope (which are treated in this study as potential enhancements) must be made, discussed and justiﬁed in public prior to 24 being explicitly accepted or rejected. Existing scholarly research about ARIN primarily concerns ARIN as a technical data source (e.g., about routing tables, IPv6 transition, WHOIS, and network protocols and topology), as an exemplar Regional Internet Registrar, and as an emerging legal concern (e.g., Plzak and Ryan, 2006). As of April 2010, the common research publication databases had not indexed any articles concerning the dynamics of ARIN as a collaborative environment.

The organizations were chosen in part for their varied reliance on CMC. Apache has no substantial off-line infrastructure to facilitate face-to-face interactions among the voluntary shepherds and stakeholders on a daily basis. Its main purpose is to facilitate on-line development of a key on-line infrastructure platform for CMC. Firefox has a substantial off-line infrastructure operated as a corporate foundation to manage interactions and contributions among salaried individuals at its corporate site and volunteer contributors from around the world. Its main purpose is to facilitate on-line development of an end-user tool for CMC. ARIN sponsors or operates meetings to facilitate face-to-face interactions of some of its members on approximately a quarterly basis to supplement CMC-based policy development. Its main purpose is to be an administrative infrastructure for regulating policies enabling Internet connectivity at the foundation of much of the global CMC activities.

All three organizations use public mailing lists to discuss potential enhancements. Such mailing lists are intended to allow shepherds and interested stakeholders to discuss potential new enhancements, their revisions, challenges and processes. Discussions constitute the substantial component of the communications, and often of the creative work, leading up to and including implementation of enhancements.

Mailing list discussions help participants in the two software projects to understand challenges relating to particular enhancements, and to build direction and consensus to implement technical changes. The actual changes to the software are managed through a Bugzilla system.

Bugzilla is an on-line workﬂow database allowing participants to track progress of individual 25 and groups of proposed enhancements, to locate enhancements within the scope of a broader project or collaboration, and to provide a mechanism for formally vetting proposed enhancement before they are adopted by, and integrated into, the broader collaboration. Bugzillas also broadcast the activities they record to mailing lists and to individual, role, and group subscribers. Source code revisions are submitted as patches to the relevant mailing list or Bugzilla before being applied through a source code revision control system. With ARIN, analogous changes to the organization’s policy book are shepherded through a formal Policy Develop- ment Process which is initiated, discussed, and partially decided via mailing list discussions established for that purpose. Policy proposal texts and statuses are made available for public inspection via ARIN’s public website with the intent that input from the entire Internet community is valued. Details follow in Chapter 3.

Thus, the projects’ mailing lists, Bugzillas, and source code repositories provide time- correlated sets of data about the communications, activities and successes of potential enhancements. They also explicitly provide data about the timeframe and actors involved in other past and ongoing enhancement, integral with their communications activities regarding speciﬁc enhancement. With this data, it is possible to explicitly identify many of the communications and technical decisions underpinning each change in each enhancement. By comparing particular contributors’ communications and actions through time, the data also provides a good opportunity to examine revealed vs. expressed motivations, although the data does not include private correspondences and exchanges which may occur among stakeholders, despite formal injunctions against private processes (see e.g., Apache Software Foundation, 2009a).

Brieﬂy, mailing lists are have the following role in Apache’s OEP:

”Mailing lists are crucial to the operation of the Apache Software Founda-

tion. The Foundation, as well as each of the Apache Projects, uses mailing lists

to coordinate development of the software and administration of the organization.

Mailing lists also serve as a primary support channel where users can help each 26

other learn to use the software.” – Apache Software Foundation (2009b)

Supplementary data, including the projects’ end user documentation, along with promotional content and support forum discussions reveal how well particular enhancement were received and diffused, and provide one indicator of adoption. Other public discussions about the software provide a different, but unstructured, data source about adoption. Since the primary and often only interaction by participants is through the textual CMC, this method provides an opportunity to legitimately hold many of the otherwise difﬁcult to study directly interpersonal factors constant by forcing communications through a limited medium.1

This research takes the narrative data as is, since leadership styles, personality traits and assumptions based on personal interactions (e.g., Howell and Higgins, 1990; Moenaert and

Deschoolmeester, 1992; Barringer et al., 2005) of leaders would be reﬂected in their communications, and should remain constant for each individual. In the theoretically meritocratic and accessible OEPs, each ideator, in effect, has the opportunity to behave as their own shepherd.

Therefore, textual evidence of attributes of individual shepherds, their roles, their styles of interaction, etc. should be available even if individual communicators intended to mislead.

2.7 Research design ethics

2.7.1 Participation

Early in the design of the current research, it was decided that direct participation in the OEEs for the purpose of this study would be unnecessary.

Respecting ARIN policy development, substantial membership in the governance body would have necessitated direct investment in Internet infrastructure capital at significant financial cost (several thousand dollars). Attempting to directly influence the operating rules

(potentially affecting 1.7 billion Internet users world-wide) of an organization in which the

1Appendix C uses another, off-line data source as a comparator. 27 researcher had no ongoing direct interest would not have been appropriate. In the cases of

Apache and Mozilla, all individuals are welcome to participate by contributing discussion and ideas, but comparatively few individuals are trusted with authority to approve and commit changes to software source code. By design, those organizations intend to provide outside observers with sufﬁcient information—via discussion lists, Bugzillas, source code repositories and other transcripts—to transparently understand decisions without requiring tacit knowledge about interpersonal relationships of the participants. Apache requires that each contributor

“makes sustained, welcome contributions to the project for over six months” to be eligible to commit changes (Apache Software Foundation, 2009a). In addition, for reasons analogous to the ARIN case, it would have been inappropriate to directly suggest or render judgment about particular OEPs without developing sufﬁcient expertise in the software source code to make meaningful contributions, which would affect hundreds of millions of Internet users.

Further, the Apache and Firefox collaborations used common software development tools

(mailing lists, Bugzillas and source code revision control systems) and practices to manage their work. As the author had previously used the same tools professionally for corporate software development, there was no need for the author to re-learn the technical aspects of the tools.

(The author had also provided minor errata reports to the Firefox Bugzilla several years prior to commencing the current research.) Focusing on the non-technical aspects of how the tools were used, and how the participation mechanisms were used by stakeholders to communicate ideas, was thought to provide greater research beneﬁt to understanding enhancement processes than the actual operation of the tools themselves. Abstaining from direct participation also ensured an appropriate personal detachment was kept from the individual enhancements.

2.7.2 Identity and privacy

Even though the data sources detailing OEPs and their communications consist of published work of their respective organizations, the linked topics of identity and privacy deserve exam- 28 ination. Such considerations are especially salient since the present research concerns human activities in on-line environments. Information deliberately made public by OEPs, which as part of their fundamental charters must explicitly invite public scrutiny and contribution, were speciﬁcally chosen for this research. The OEEs themselves valued having many critical eyes on the process as a goal and virtue, even if not all the eyes belonged to capable participants.

So far, and still further into the manuscript, the OEE participants are variously called

“shepherds”, “participants”, “stakeholders”, etc. depending on their roles in particular contexts. While there is value in categorizing the participants according to various theoretical criteria, it must be emphasized that participants chose to actively participate in Open Source projects (Apache and Firefox) in particular (not always well labelled) ways, and that their participation was only possible through the openness of the model. The openness of the model is valued by participants for reasons which include subjecting development and decision-making processes and outputs to public scrutiny. In the case of ARIN, the policy development process explicitly requires a public role for the purpose of providing transparency to decision-making processes concerning shared resources required by the public to use the Internet infrastructure.

Participants in mailing lists and Bugzillas are made aware, through the software interfaces enabling them to contribute using those tools, that their contributions are made available for the public and other participants to inspect, store, and evaluate. Apache and Firefox are explicitly software publishing projects which publish their starting materials and their contribution records openly in order to attribute copyrights and solicit further contributions. Participants in ARIN policy discussions explicitly publish messages via the mailing list to call attention to perceived deﬁciencies of the organization and its policies. All three OEEs require contributors to contribute via the act of “posting” messages to a mailing list, which “[u]sually implies that the message is sent indiscriminately to multiple users, in contrast to mail’ which implies one or more deliberately selected individual recipients” (FOLDOC, 1997). As a usage metaphor, posting a contribution to any one of the OEEs follows the conventional off-line meaning of the 29 verb, roughly “[t]o make known, advertise, or bring before the public (a fact, thing, or person) by or as by putting up a placard or notice” (OED, 2009).

Each of the three OEPs form an essential component of the Internet’s data handling infrastructure. Participants in all three efforts would be reasonably required to know about basic common data handling practices on the Internet in order to meaningfully participate. Partic- ipants would reasonably be expected to comprehend the policies and disclosures about their participation to which they must agree to gain access to, and participate in, the OEPs. The default message sent to users who wish to create a Bugzilla account speciﬁes that “Bugzilla is an open bug tracking system. Activity on most bugs, including email addresses, will be visible to the public” (Mozilla Foundation, 2009a). Participants in Apache development are informed by their project guidelines that “[t]he Apache developers’ primary mailing list for discussion of issues and changes related to the project ([email protected]). Subscription to the list is open, but only subscribers can post directly to the list” (Apache Software Foundation, 2009a).

However, the fact that participants’ contributions and discussions have been made public by virtue of their participation does not on its own mitigate potential for harm. Individual participants, both as human beings and potentially as pseudo-anonymous on-line identities with reputations, may not fully appreciate potential consequences of contributing to perpetually public searchable aggregate archives of work. Even though Apache and Firefox accept ideas and discussion from individual e-mail addresses, rather than from individual persons whose identities are veriﬁed off-line as with ARIN, both projects require software code to be contributed by legal persons who may assign copyrights to the organizations for licensing reasons.

To keep the focus on communication during enhancement processes (not on how communicators come to perform enhancement work), the research design chooses to view individual enhancement processes as the relevant unit of activity (the same view available to any participant or observer), and not to analyse particular individuals’ contributions over time or across projects. (However, roles of leadership or bureaucracy in the OEEs—as disclosed through the 30 public governance records of the three OEEs—are noted.) Thus, this research explicitly does not deliberately disclose information about any individual’s or group’s social capital which would be new to participants, or new to social or professional settings in which they have accu- mulated social capital (this is ultimately the source of any potential harm to OEE contributors).

Nor does the research reveal any personal information beyond that which is typically disclosed in citation analyses, ofﬁcial publications of scientiﬁc proceedings, or legislature Hansards.

2.8 Approach

The on-line, mostly textual collaborative OEEs studied may appear somewhat foreign to the urban research environments typically studied to understand innovation. Salient operational features of OEEs are detailed in each of the next two chapters. They each explore an aspect of the OEEs through an aspect of the framework: infrastructure, activities, communication, and enhancement characteristics. A general analysis summarizes learnings via new hypotheses. 31

Chapter 3

STRUCTURAL ELEMENTS

3.1 Introduction

This chapter1 reports on governance institutions, infrastructures and processes within the three open enhancement environments studied with respect to stakeholder inclusion in innovative and governance practices. It does not examine innovation or governance in, or of, the Internet as a whole, nor in general. Since the three OEEs may not be generally familiar to researchers, brief descriptions of the three organizations’ precede the primary analysis.

The three OEEs studied are the Mozilla Foundation for its main Firefox web browser project, the Apache Software Foundation for its HTTP Server Project, and the American Reg- istry for Internet Numbers (ARIN) for its Policy Development Process. The three are key components of a common technological and social infrastructure: 300 million individuals use the Firefox web browser to retrieve and display web pages from 70 million web servers running instances of Apache HTTP Server providing websites such as YouTube, Wikipedia, the BBC, digg, and the U.S. Senate websites (Netcraft, 2009). The web browsers and web servers are connected to each other via the public Internet, which, in North America, uses an addressing system managed through ARIN. ARIN’s products—policies in its policy manual—are similar to computer source code in that they deﬁne the kinds of outputs to be produced given particular kinds of inputs and conditions, but policies do not specify particular operational algorithms which are left to the ARIN bureaucracy to develop and implement.

As publishers and stewards of platforms for Internet innovations, the three organizations are plausible sites of innovation. As open environments, each explicitly seeks and requires formal

1presented in an earlier form at 4S 2009, Washington, DC 32 enhancement processes to be fully documented in public archives. Such archives trace contributors, ideas and decisions, so that the public may understand and contribute to the projects.

3.1.1 Innovation and governance

Innovation policy encourages individuals and groups to attempt to cause specific kinds of changes which benefit society. Governance coordinates work toward common objectives, including innovation, in exchange for diminished individual freedom. The elected and appointed officials of a nation state, the board of directors of a corporation, and the social norms of a reoccurring grouping of people, all provide governance; the first two provide governments. This chapter does not address all innovation issues and variables of governance, but instead focuses on a natural experiment around the governance of technological change, within and around

Mozila Firefox, Apache HTTP Server, and ARIN, through their OEPs.

3.1.2 Literature teview

In this chapter, a simple and commonly relatable model of government frames governance.

This chapter does not presume that the organizations and processes studied ﬁt into any particular corporate governance paradigm. The goal is to draw conclusions about the rudimentary governance and enhancement phenomena so that new patterns may be detected if present.

From between the bodies of existing literature sampled below, this study carves a potentially new path.

Markman, Balkin, and Schjoedt (2001) examined governing innovation in entrepreneurial seed-stage firms, with respect to effects of board structure and venture capital-backed monetary incentives for risk-taking. The organizations studied presently are significantly more mature; are not venture-capital-backed (nor, generally, for profit); have boards of directors who (mostly) do not perform innovation work; and explicitly encourage internal entrepreneurship. Swyngedouw (2005) examined innovation in state governance with respect to citizen 33 participation, and also novel facets of new governance practices, finding “innovative [urban] governance arrangements fostering inclusive development processes” around systems formerly provided by state. However, unlike Swyngedouw’s municipalities, the organizations studied presently trace various paths from U.S. government-funded projects from the 1990s; currently provide services that were not previously provided by the state; do not use state apparatus; and explicitly engage state, private, and civil society actors. Previous efforts have examined power separation with respect to states seeking civic participation to develop policies (e.g., Jaeger,

2002; Kuhlmanna and Edler, 2003). While the organizations currently studied also seek civic participation to develop policies, the projects are not state governments, and variously fuse or separate powers. Cooke (2001) and others have studied regional innovation systems, broadly deﬁned by economic, political and institutional relationships in a geography, which generate collective learning, rapid diffusion of knowledge and best practices. The present OEEs are global platforms for other enhancements; they depend on internal and external information via producers, users, and researchers for enhancements; they move together with technological advancements; and they are institutions embedded among others carrying out enhancements. Mockus et al. (2002) examined technical Open Source software development processes at Apache and Mozilla, via internal interactions with source code repositories, error rates, etc. under a software development paradigm. This chapter considers the organizational structures, public participation, process around ideas, inventions and features at Apache, Mozilla, and related others.

3.1.3 Powers of government

The classic Greek model separates the three branches of government. Independent leadership limited the scope of individual roles to ensure no individual gained too much power. In modern implementations, the legislative branch sets the framework under which the governed individuals participate in deciding the mutually agreed bounds of the shared environment. Legislated 34 bounds may prescribe or circumscribe some manners and conditions of technical execution and set the terms under which philosophical, organizational or technical disagreements are resolved. The executive branch builds and operates the shared governed environment according to established policy, via a leadership which sets out a broad direction supported by policy, and a bureaucracy which implements infrastructure to support and enforce policies and procedures. Parts of the executive branch are able to modify policy and dispute resolution through selectively building/modifying infrastructure. The judicial branch interprets policy and organizational vision and its application in case of conﬂicts among legislation, executive and individual constituents. Respected or authorized individuals and groups resolve disagreements among constituents, may make decisions which bind the legislative and executive branches, and may create or modify policy through setting precedents.

To reiterate, this research uses the above framework to identify the governance powers in the organizations and projects studied, not to examine how they are governed by states. It is expected, just as in state governments, that the organizations partition powers in different ways, and that actual powers may not reﬂect the ofﬁcial documentation.

3.1.4 Open enhancement environments

Recall that the Open Source philosophy values that users may access everything required to improve upon and share the collaborative output with others. This is accomplished through policies mandating that process and product documentation (e.g., discussions, decision notes and source code) be shared in public. Like other cooperative efforts, OEEs may be implemented and managed in many ways supporting openness and participation. 35

3.2 Research questions

Without re-capitulating discussions about sovereign and formal attempts to regulate the Inter- net, the present chapter studies three entities who enable or regulate limited aspects of Internet use. Speciﬁcally, this chapter seeks to answer the following question: How does conﬁgration of governance affect participation and outcomes in OEPs? Examining how the powers, responsibilities, and visibility of governance are distributed, in conjunction with OEP outputs, will provide a direction to explore the links between infrastructure and enhancements.

3.2.1 Hypotheses

This chapter focuses on three hypotheses about the three OEEs studied based on the previously speciﬁed framework. They test analytic sensitivity to the structure, functions, and stakeholders of the OEEs, rather than attempt to explain substantial relationships among them.

• H1. Governance functions from the three classical governance branches can be identiﬁed

through formal and informal institutions, infrastructures and processes.

• H2. Conﬁguration of branches of governance relates to enhancement processes and en-

hancement outputs.

• H3. The access to participate in the technology governance processes relates to enhance-

ment outputs.

If these hypotheses are correct, differences in how the three organizations govern their enhancement activities will coincide with differences in how the organizations translate ideas into enhancement outputs. Evidence might come in the form of: points of public or internal access to encourage or discourage input; communication interfaces within a project or organization and between a project and its constituents; or quantitative measures of participation, enhancement inputs and outputs, and size of governments. 36

3.3 Review of governance at the three organizations

This section summarizes the governance infrastructures at the three OEEs, focusing on how they generate, receive, and implement ideas supporting enhancements. It uses documents published by the OEEs to identify formal sources of governance authority, the actors exercising those powers, how such powers are exercised, and how each branch of power is accountable to others. In so doing, the OEEs’ formal enhancement processes and infrastructures, or parts of their governments, are also encountered. Purposely excluded are personal, informal, and professional considerations not systematically subject to governance or policy arising from the

OEEs. Salient details about the personal execution of governance are examined in Chapter 4.

3.3.1 Similarities and differences

The three organizations function within section 501(c) of the U.S. Internal Revenue Code pertaining to tax-exempt corporations for educational, charitable, and scientiﬁc purposes; but perform somewhat broader functions in areas where state government has delegated authority

(ARIN) or does not exercise authority (Apache and Mozilla). All three organizations employ

(relatively) small formal bureaucracies responsible for coordinating the technical and social activities of the entire organizations.

Visually, Figure 3.1 depicts three different organizational conﬁgurations. Firefox is developed within a “faceted” structure, requiring multiple levels of review and action from every branch. In practice, most participants who are not part of the organization contribute ideas only, with a small number occasionally submitting software patches into the relatively long process bringing ideas to product feature. Apache HTTP Server uses a “fused” governance system in which every participant may exercise every kind of governance function (although the vast majority of external constituents do not practically do more than suggest ideas). Finally, ARIN employs a clear linear process and separation of powers (labelled “distinct”), and uses regu- 37

Legislative Executive Judicial

Foundation Board (6) Corporate Board (4) Corporate Staff (250) Super-Reviewers (30* roving) Mozilla Module Owners [reviewers] (86*); Firefox Owner Mozilla Module Peers [reviewers] (206*); Firefox Peers (2), Firefox UI Group (2), Firefox Members (18), sub-module owners (14), sub-module reviewers (33) Pathway

Commmitters (730) Enhancement Bugzilla Admins (#?) Mozilla Firefox Constituents (300 million) 990 bureaucrats, 260 FTE

Board of Directors (80) Release Manager (1* rotating) PMC (53) Committers (72) Pathway Server

Constituents (72 million) Enhancement

Apache HTTP Apache HTTP 205 bureaucrats, 0.5 FTE

Board of Trustees (6) Corporate Staff (49) Advisory Council (15) Pathway

ARIN members (3497), ARIN members (3497), Enhancement NANOG members (open) NANOG members (open)

Constituents (1.7 billion Internet users) ARIN PDP 70 bureaucrats, 55 FTE

Figure 3.1: Distribution of governing bodies’ responsibilities at three organizations. (Number of salaried employees given as full-time equivalents (FTE). Typical innovation pathways are indicated. Outlines indicate infrequently exercised formal or de facto powers. Sources: structures and staff sizes are based on project governance documents, Bugzillas, and contact lists; constituent sizes are approximations based on project and third-party estimates.) * indicates that the number of role holders is relatively ﬁxed, but the holders of the role change. 38 larly scheduled live and virtual meetings at which policies may be supported or opposed by members, which are then formally approved or rejected by the Board of Trustees (as is required by U.S. law), and implemented by the ARIN corporate staff. However, ARIN does not substantially enjoy participation from outside of the network or Internet operator community.

As with state governance, some legislative, executive and judicial functions in the three organizations were fused in legislation and operation. In particular, just as policy and judgments may be made through service delivery, just as legislation may be made at the bench, and just as regulation may dictate how operations are to be evaluated and carried out, analogues were found in the infrastructures studied. Within Apache, any executive decision may be the subject of a vote through which constituents render judgment about the decision. In Mozilla, committers are expected to conduct their executive work and judge or recommend the technical merits of those contributors who would become committers. At ARIN, the Advisory Council and Board of Trustees both have powers to decide and refer legal questions.

Even though these OEEs commonly innovated openly, they employed different but not unique governance structures. Firefox’s sprawl recalls moderately sized corporations, foundations and conglomerates. Apache’s flat configuration recalls typical member-driven coopera- tives, associations, and NGOs. ARIN echo a state government bureaucracy with well defined organs of responsibility. In short, even though these diverse organizations all use open and inclusive processes, these examples do not appear to represent forms new to governance.

Like an NGO, Apache provides specialised technical products, services, and project management supporting development activities implemented on the ground by other parties. But, unlike many NGOs, Apache readily permits any technically competent individual from governments to participate, and receives no government funding. It was formed to develop and maintain its core product, the Apache HTTP Server, which arose from personal collaborations among individuals at several public U.S. universities. The Mozilla Corporation, wholly owned by the Mozilla Foundation, pays business staff to publish consumer software products 39

(including Firefox and Thunderbird) from which the company earns profit (via an arrangement making Google its default search engine). The standards and environment enabling Firefox arose from foundations laid by the National Center for Supercomputing Applications (NCSA), the European Organization for Nuclear Research (CERN), and the World Wide Web Consor- tium (W3C). ARIN is responsible for the oversight and administration of specific functions related to Internet Number Resources in a specific geography, similar to the responsibilities of a state regulator or government agency. Unlike Apache and Mozilla which emerged from constituent efforts, ARIN originated as a service provider built by the U.S. government from an agreement among several international and intergovernmental regulators (Karrenberg et al.,

2001), with a goal to enable constituents to contribute to their own regulation (ARIN, n.d. 1).

3.3.2 Roles of contributors during enhancement processes

The following comparison of intermediate enhancement products at the three organizations uses data collected for approximately June 2008–August 2009 (to minimize uncontrolled external inﬂuences common to all three environments). Data were counted from the following types of public sources: product development discussion lists (“ideas”); formal requests entered in the change tracking mechanisms (“enhancements logged”) in Firefox’s and Apache’s

Bugzillas and ARIN’s Policy Development Process; inventions implemented as recorded in the change tracking mechanisms and products (“changes accepted”); and changes advertised in marketing or general product literature (“features”).

ARIN also offers a Consultation and Suggestion Process, to “consult with either the members of ARIN or with the community at large regarding ARIN services and practices” (ARIN,

2007) arising from ARIN’s implementation of policy and other initiatives which are not policy proposals. Reviewing the suggestions and ARIN’s actions and responses indicates that a vast majority of submissions concerned operator technical issues, knowledge referral requests, and direct intervention requests outside of ARIN’s policy scope. Since ARIN actively referred the 40 handful of policy suggestions in ACSP to its Policy Development Process, there is no need to consider ACSP as a different substantial part of ARIN’s innovation process. (For the 14 month study period, the ARIN-consult mailing list received a total of 21 messages mostly concerning topics which were already under discussion within the ARIN-ppml list.)

3.4 Method and results

The contents of each of the three projects’ discussion mailing list and development mailing list or Bugzilla were retrieved and the number of conversations and participants were counted.

The number of constituents, installations/users, and third party modules of each project were gathered from ofﬁcial project documentation (websites) or estimated from third-party sources if no ofﬁcial values were available.

Note: The numbers of intermediate products (ideas, enhancements logged, changes accepted, features) at each stage of the OEPs were recorded for the same period (see Figure 3.2).

However, such counts did not track individual ideas as they moved through the OEPs. This ap- proximation was justiﬁed as follows: Originators of ideas consistently move (or are encouraged to move) their viable ideas into the formal workﬂows within a short time (perhaps a month) through individual interest. The OEEs are well established in their processes and resources available to move ideas through their OEPs, remaining consistent for at least two years before the study period. Changes in attention and resources available to implement inventions (e.g., interns and meetings) are cyclical but occur annually or more frequently. Therefore, an idea anywhere in an OEP three years ago would be subject to substantially the same governance conditions as an idea at a comparable stage during the study period.

Not surprisingly, all three projects ﬁltered many ideas down to a few inventions. The institutively most accessible OEE (almost any Internet user has the knowledge to suggest a usability change to the Firefox web browser) received more ideas and generated more changes 41

Table 3.1: Study periods for data collection at three projects studied.

Project Versions covered Start date End date Mozilla Firefox 3.0–3.5.2 June 17, 2008 August 2, 2009 Apache HTTP Server 2.2.9–2.2.13 June 14, 2008 August 8, 2009 ARIN PDP Policies 73–97 June 5, 2008 June 12, 2009 accepted (inventions) than ARIN which had the highest barriers to entry (few individuals are qualiﬁed to make suggestions about Internet architecture policy). Excepting marketing which converted inventions or policy changes into new features, Figure 3.2 shows the same pattern of OEP occurring at all three OEEs. If governance patterns, deﬁned by traditional powers, affect enhancement outputs then the three OEEs would yield different patterns of output (before they reach marketing and adoption). However, the only notable but unremarkable relationship observed is that large bureaucracy occurs with many ideas (Figures 3.1 and 3.2).

3.4.1 Participation in innovative processes

Perhaps examining participation in OEEs reveals something about how their OEPs are governed. The simplest way to participate in the OEEs was to suggest a change or idea for the platforms, a more difﬁcult contribution would be to write and maintain computer or policy software, while the most challenging would be to develop and maintain a third-party module which interfaces with the platforms to provide speciﬁc new functionality which the OEEs do not wish to support internally.

Table 3.2 shows over ten thousand Firefox users participated by contributing ideas or developing modules to extend the web browser. Less than a thousand individuals participated in Apache HTTP Server by contributing ideas or through module development. And very few public individuals participated in ARIN’s policy development process, although relatively many of its three thousand members (network operators) participated in governance and policy development. The distribution of powers in governance again provides no obvious link to par- 42

1000! 21,038 1,341 (Firefox)! (Firefox)! 900!

800!

700!

600!

500!

400!

300!

200!

100!

0! # ideas discussed! # enhancements logged! # changes accepted! # "features" marketed!

Firefox! Apache! ARIN!

Figure 3.2: Ideas, enhancements logged, changes accepted, and features at three projects during the study period. Sources: ARIN-ppml, Apache Bugzilla, Mozilla Bugzilla, discussion lists, product documentation.

Table 3.2: Participation in the three projects during study period, as counted on author based on discussion lists and Bugzillas (collected by author during September 2009).

Project Constituency Participants Participation Third-party (contributed ideas) Rate modules Mozilla Firefox 270 million 14,331 5.3 x 10-5 10,317 Apache HTTP Server 72 million 610 8.5 x 10-6 505 ARIN PDP (theoretical) 1,670 million 203 1.3 x 10-8 24+ ARIN PDP (practical) 3,497 members 203 5.8 x 10-2 24+ 43 ticipation or enhancement outcomes. Perhaps the interesting relationships between governance and enhancements occur at the peripheries of the three organizations.

3.4.2 Public participation outside the enhancement process

To survey areas around the OEEs’ cores, the above counting method was repeated for several projects related to the Apache, Firefox and ARIN products examined. These projects produced successful enhancements which have been adopted by many individuals to enable them to do new things. These projects, and their relationships with each other and with broader social contexts, are ﬁrst brieﬂy outlined.

Apache Tomcat serves webpages generated using the JavaServer Pages technology designed by Sun Microsystems, and is a low-level standard platform like Apache HTTP Server.

JavaServer Pages technology enables at least a million programmers to develop portable web- based applications supporting business processes, social media, and various communications without being bound to any proprietary vendors’ (costly) platforms. Apache Tomcat is used by Apache Open for Business (OFBiz), a customizable enterprise automation platform used by

United Airlines, 1-800-Flowers, British Telecom, the American Heart Association (along with dozens of others) to provide on-line storefronts and information to tens of millions of individuals each year. Business service providers also use OFBiz as the platform to manage and deliver outsourced services and products, enabling small firms to access and scale their business infrastructures at low cost. Apache SpamAssassin is a widely deployed platform which identifies junk e-mail. Like OFBiz, SpamAssassin is used and customized in free and commercial forms in dozens of products and services, and may use spam identification lists and heuristic rulesets provided by third parties. Hundreds of millions of email accounts are protected from junk mail by SpamAssassin, saving individuals minutes to hours of unproductive work each day. All of these Open Source Apache projects follow Apache’s governance model.

As evident in Figure 3.3 Apache Tomcat, as a platform like Apache HTTP Server, shares 44

2000!

1800!

1600!

1400!

1200!

1000!

800!

600!

400!

200!

0! # ideas discussed! # enhancements logged! # changes accepted! # "features" marketed! Tomcat! SpamAssassin! OFBiz!

Figure 3.3: Ideas, enhancements logged, changes accepted, and features at three Apache projects. Sources: projects’ discussion forums, Bugzillas, product documentation. the funnel shaped intermediate enhancement output graph in which many ideas only yield a small number of inventions. Apache OFBiz and SpamAssassin do not exhibit the same exponential reductions. Both Apache HTTP Server and Apache Tomcat require the addition of other software to be of any meaningful use, while OFBiz and SpamAssassin require only conﬁguration of settings to become immediately useful.

The Firefox web browser is distributed as a turnkey product, but must be augmented by the user or content producer with plugins and frameworks to access many kinds of common web content such as streaming videos and interactive web applications, or to add functionality described as follows. Firefox plug-ins allow individuals to add or expose functionality in the

Firefox browser without modifying the underlying common platform. Unlike Apache modules,

Firefox plugins (Figure 3.4) are regulated to an extent by Mozilla in that widely distributed 45

400!

350!

300!

250!

200!

150!

100!

50!

0! # ideas discussed! # enhancements logged! # changes accepted! # "features" marketed!

AdBlock Plus! Greasemonkey! NoScript! Web Developer toobar!

Figure 3.4: Ideas, enhancements logged, changes accepted, and features for four Firefox plug-ins. Sources: plug-in projects’ discussion forums, Bugzillas, product documentation.

Firefox plugins must undergo a review and approval process (Mozilla Foundation, 2009c).

Unlike Apache Tomcat, OFBiz and SpamAssassin which may be used without Apache HTTP

Server, Firefox plug-ins require Firefox to function.

Among the popular (dozens of millions of users) Firefox plug-ins studied, the funnel shaped

OEP occurs in two instances: once for Greasemonkey, which enables third party templates to reconﬁgure the appearance and functionality of websites as chosen by users; and NoScript which relies on the user to decide which websites may run software in their browsers. By contrast AdBlock Plus, which blocks advertisements on web pages, shows more enhancements logged entering its OEP than potential ideas being advanced by users, like Apache OFBiz.

Both AdBlock Plus and OfBiz may be configured by the user, or may use standard third-party configurations. As a toolset mainly intended for website developers, it is not surprising that 46 the Web Developer toolbar shows exponential reduction of ideas discussed to inventions, but not to the extent of Greasemonkey or NoScript. All of these Firefox plug-ins are Open Source, however they follow governance models centred around one to seven individual volunteers who have clear responsibilities, but not necessarily clear roles in governance. In addition, lacking the technical and human infrastructure of the scale of the Apache Software Founda- tion’s projects, the Firefox plug-in projects employed simpler infrastructures, often combining discussions, feature requests, bug reports, mailing lists, and technical support into a single discussion forum instead of using separate workflows and tools.

3.4.3 Lack of public participation outside the OEPs

Finally, third-party modules for ARIN (lists of bad IP addresses which supplement rather than leverage ARIN data) exemplify inputs and enhancement from undocumented sources. Ideas about collecting and managing lists of “bad” (howsoever deﬁned) IP addresses were not gathered in a systematically open manner, their processes were not speciﬁed in public, inventions may or may not be documented, source code is not easily accessible, etc. even though the organizations providing the lists claim to be open, transparent and fair (but not necessarily Open

Source). One example, a list of IP addresses which have not been assigned, is an unremarkable exception transparently generated from public data using obvious methods (Cymru, 2009).

Wikipedia lists 24 major families of block lists available to the public, although there is no authoritative count since anyone may maintain, publish, and aggregate data from their own and others’ lists. Most lists provide policies about IP addresses being added to, or removed from the lists (dormant and defunct lists pose a problem for those listed since individual system operators are not obligated to verify/remove inaccurate listings). Many lists feed into Apache

SpamAssassin as inputs to ignore senders of spam or malicious e-mail. The block lists generally employ a high degree of automation in collecting data, and in managing list additions and list removals, with manual intervention being viewed by operators with suspicion (e.g., Cotoni, 47

2009 regarding ability to contact Spam and Open Relay Blocking System operators). Although the ARIN discussion lists occasionally mention block lists, dozens, if not hundreds, of other discussion lists and forums also discuss such lists.

Some of the observable variety among block lists is as follows. The Summit Open Source

Development Group maintains the Abusive Hosts Block List, but does not provide any insight into the list management process, nor the size of the entity governing the list. The Anonymous

Postmasters Early Warning System maintains a list completely anonymously, insisting that network operators should trust it by reputation (APEWS, 2010). Spamhaus and UCEPROTECT, both sell commercial managed services (Spamhaus, 2009; UCEPROTECT, 2010) which implement blocking off parts of the Internet originating spam. The commercial invaluement DNSBL isolates not only speciﬁc hosts on the Internet which send spam, but their logical neighbors as well, again without transparency of governance (MacEwan, 2009). The Composite Block List is more comprehensive in the types of undesirable behaviour it attempts to prevent, and feeds into the Spamhaus and other lists. It includes hosts which

“exhibit characteristics which are speciﬁc to open proxies of various sorts and

dedicated Spam BOTs which have been abused to send spam, worms/viruses that

do their own direct mail transmission, or some types of trojan-horse or stealth’

spamware, dictionary mail harvesters etc.” (CBL, 2009).

There is clearly a diversity of demand and of inventions among these lists. Anyone may interro- gate block lists for individual IP addresses or networks, and they may usually freely download lists, but evidence supporting listings may or may not be provided.

In short, ARIN “modules”, in both process and accountability, are almost completely closed to external inspection. Although end users rely on Internet service providers to use such lists for protection from spam and computer malware, any network operator or ISP may compile, use and share list with anyone else, without disclosure to the Internet-using public. Mistakes or malice may block email from or to individuals, or entirely prevent access to from or to whole 48 swaths of the Internet, since accuracy of individual lists may range from 0–100 per cent, and inaccuracy may range from 0–30 per cent (Intra2net, 2009). Spamhaus alone claims to pro- tect almost 1.5 billion user mailboxes through the various block lists it generates (Spamhaus,

2009), so simple errors may easily be magniﬁed in ways not obvious to the beneﬁciaries of the technology. Regardless of how these block lists are governed, it is clear that they affect a great number of users without being directly sensitive to their input or ideas.

3.4.4 Public sources of ideas for enhancements in platforms and modules

To examine the possible relationships between governance of enhancements and social consequences, this section focuses on public participation as a source of ideas.

Table 3.2 summarizes participation by one-time contributors to nine of the ten projects studied. For each project, the table lists the percentage of individuals who only contributed once to the project (OTC), as well as the percentage of ideas contributed by one-time contributors to the project (P). A high rate of one-time contributors could indicate low barriers to contributing to a project, but also low motivation or incentive to participate on a sustained, repeated basis.

Conversely, a low rate of one-time contributors could indicate high barriers to contributing to a project, but also a high reliance on those already within the project to contribute ideas.

Table 3.3 suggests some relationships which are more rigorously examined in the next section. Participation by one-time contributors does not appear to relate to how governance powers were conﬁgured. Participation also does not appear to relate to the size of each project’s bureaucracy. The Firefox plug-in projects have one to seven individuals each in their bureaucracies yet are the most open and very closed to participation. Firefox has the largest number of individuals in its bureaucracy and yet ranks moderately in openness to participation, while the Apache projects almost span the entire range of openness to participation. Overall, individuals who only contribute to the projects once are responsible for providing more ideas than are individuals who contribute repeatedly to the projects. Accessibility may be a beneﬁcial 49 indicator that the public is able to contribute to the development and governance of their new technologies, but how does openness to public input contrast with the role of the bureaucracy tasked with shepherding the enhancements?

Table 3.3: Number of eligible participants, participation by one-time contributors (OTC) and governance as counted by author.

Project Eligible Bur. % % inven- Particip- Rank Power participants* Size ideas tions from ation distri- by OTC ideas index bution OTC (P) (P/OTC) ARIN PDP 3,500 or 1.7 70 77 61 0.79 3 Distinct billion Apache HTTPD 70,000,000 207 93 85 0.92 2 Fused Apache OFBiz * 800,000 33 41 10 0.23 9 Fused Apache Tomcat 10,000,000 72 88 68 0.77 4 Fused SpamAssassin * 100,000,000 35 74 35 0.47 8 Fused Firefox 270,000,000 1253 81 58 0.72 5 Faceted AdBlock Plus * 60,000,000 1 80 45 0.57 7 Distinct Greasemonkey+ 20,000,000 7 ?? ?? ?? ?? Faceted NoScript * 56,000,000 6 87 53 0.61 6 Faceted WebDeveloper TB 13,000,000 1 93 89 0.96 1 Fused AVERAGE 79 56 0.67 * Numbers of eligible participants for plug-ins are (under-)estimated to at least one signiﬁcant ﬁgure based the number of downloads publicly reported by their respective primary download websites, or publicly reported estimates as of August 2009. + The Greasemonkey archives stored on Google were not amenable to automated counting.

Recall from Tables 3.1 and 3.2 that AdBlock Plus, Spam Assassin and OFBiz showed bulges in their OEP funnels (numbers of enhancements logged comparable to, or exceeding, number of ideas discussed), in which it appeared that ideas were entering the OEP from outside prescribed public discussion lists and forums, or were being less aggressively ﬁltered. Those three projects also rank poorest with respect to receiving ideas from one-time contributors, as indicated in Table 3.2. Together, these observations again point to some important aspect of the OEP not clearly deﬁned by organizational structure. 50

1.0E+00! Firefox Apache ARIN OFBiz Apache Apache Spam AdBlock Grease- NoScript WebDev. ! 1 ! HTTP2! S. PDP3! 4 ! Tomcat5! Assassin6! Plus7! monkey8! 9 ! Toolbar10 ! !

1.0E-01!

1.0E-02!

1.0E-03!

1.0E-04!

1.0E-05!

1.0E-06! participation rate! ideas discussed per eligable participant! changes accepted per active participant!

Figure 3.5: Participation rate, ideas discussed per active participant; ideas discussed per eligible participant, changes accepted per active participant; and changes accepted per eligible participant for ten projects studied.

3.4.5 Core vs. periphery

The large proportion of ideas originating from outside the projects’ leaders and regular contributors also elicits an examination of the distinction between the core and the periphery. While the core is responsible for implementing inventions demanded by the users more than for originating those ideas, user participation in OEPs (but not necessarily in governance of those processes) appears important.

As is evident from Figure 3.5, participation rate, ideas discussed per eligible participant, and changes accepted (inventions) per active participant, are all closely linked to each other.

Some components of these relationships are shown in detail as follows.

Figure 3.6 illustrates that, across many scales of project dimensions, between the proposal 51

1000!

y = 0.3432x0.6547! R" = 0.62859!

! 100!

changes accepted 10!

1! 1! 10! 100! 1000! 10000! 100000! ideas discussed!

Figure 3.6: Number of ideas discussed vs. number of changes accepted. 52

1.0E+01! participation rate! 1.0E+00! 1.0E-06! 1.0E-05! 1.0E-04! 1.0E-03! 1.0E-02! 1.0E-01! 1.0E+00! 1.0E-01! y = 2.5799x-0.612! y = 0.0135x-0.11! R" = 0.17686! 1.0E-02! R" = 0.04137! y = 0.8495x0.9819! R" = 0.86089! 1.0E-03!

1.0E-04! y = 0.0135x0.8897! R" = 0.73751! 1.0E-05!

1.0E-06!

1.0E-07!

1.0E-08! ideas discussed per eligable participant! changes accepted per active participant! changes accepted per eligible participant! ideas discussed per active participant!

Figure 3.7: Participation rate vs. ideas discussed or changes accepted per active or eligible participant. of an idea and its realization as an invention, most ideas do not survive the OEP. Since distribution of powers did not relate to inventive output, an explanation may rest in social dimensions.

Figure 3.7 shows that the total number of changes accepted per active participant remains consistently linked with participation rate regardless of project size. That is, more participants at the core or at the periphery do not necessarily enhance inventive output. However, both the number of ideas recorded per eligible participant, and the number of changes accepted per eligible participant, were consistently high with high participation rate. (The log of number of ideas discussed per active participant was typically greater than zero and did not relate to participation rate.) Since the ideas and inventions of the OEPs behave consistently for both small and large projects, this suggests that the OEPs were more strongly inﬂuenced by the social dynamics among individuals in a community, rather than by individuals themselves or by the 53

1! 0.000001! 0.00001! 0.0001! 0.001! 0.01! 0.1! 1! 0.1! y = 0.0411x1.037! ! R" = 0.57127! 0.01!

y = 0.0185x0.9228! 0.001! R" = 0.88862! 0.0001!

0.00001!

0.000001! changes accepted per participant changes accepted per

0.0000001!

1E-08! ideas discussed per participant!

Eligable Participants! Active Participants!

Figure 3.8: Ideas discussed per eligible or active participant vs. changes accepted per eligible or active participant. scale of infrastructure. These general consistencies in relationships between participation and what might be considered innovation across such diverse projects and organizations suggests a common mechanism throughout.

Figure 3.8 shows that the rate of idea generation is more strongly linked to the rate of invention as measured through the size of a project’s eligible participants, than as measured through a project’s active participants. This result is counter-intuitive if one assumes that the participants inside a project would be the ones to primarily influence that project. However, this result complements the earlier finding that a majority of ideas and inventions arise from one- time contributors (Table 3.3) who bring insights from outside industry. Recall that the projects all aim to be open user-oriented endeavors in which project health is reflected in the project’s ability to convert demands expressed in the market (recorded user ideas) into inventions in the 54 product to be used by the users. (The Open Source framework, wherein open processes and documentation allow the semi-permanent individuals within the project to be readily substi- tuted, may also draw support from this observation.) Governance allowing social participation in the OEP appears to be critical to the development of technologies among the organizations studied. Effective participation, in turn, requires effective communication at a minimum.

3.5 Social implications of governance in OEEs

This section addresses some of the social implications of governance in OEEs identified within the international Internet infrastructure organizations studied. It first reviews the working hypotheses to find brief evidence for their support (or otherwise).

3.5.1 Hypotheses reviewed

Revisiting the hypotheses, the data indicate that governance, enhancements and participation are related at the three organizations studied.

• H1. Governance functions from the three governance branches can be identiﬁed through

formal and informal institutions, infrastructures and processes.

Supported: Governance powers were successfully categorized into the three familiar branches (Table 3.1) via public documentation about the formal and informal roles and responsibilities in the organizations. The governance conﬁgurations themselves are similar to those of

NGOs (Apache), corporations (Mozillla) and state government (ARIN). Given the many free- doms to potentially organize in new ways afforded by OEEs operated through CMC, largely without industrial capital limits, it was necessary to explicitly understand the OEE infrastructures.

• H2. Conﬁguration of branches of governance relates to enhancement processes and en-

hancement outputs. 55

Not supported: The governance conﬁgurations did not sort with OEP outputs, nor with participation. Patterns of OEPs and outputs were more closely linked to each other, and to participation rate, than any features of governance organization as deﬁned.

• H3. The access to participate in the technology governance processes relates to enhance-

ment outputs.

Supported: As Figures 3.4 through 3.8 show, increases in participation rates are directly related to both increases in the number of ideas discussed and inventions arising from the OEEs, in a stronger manner than the relationship between ideas in and inventions out. Further, as Fig- ure 3.8 shows, the inventive output of each participant increases with the rate of participation, indicating better than linear returns for each individual already involved in the project. These generalizations appear to hold in a scale-free manner for projects ranging from 1–1000 individuals in governance, across annual budgets ranging from $0–70 million, across participants and constituents ranging from thousands to hundreds of millions; and across dozens to tens of thousands of enhancements logged per year.

The above observations that governance infrastructures are not prime factors affecting OEE outputs suggests further analysis in two parts. The ﬁrst, a closer examination of the formal- ization and competition among governance mechanisms and structures as they relate to OEPs.

And the second, a discussion of the political and social barriers around OEPs.

3.5.2 Differences between organizations’ processes

The OEEs used several methods to accept new ideas. Some used rigid procedures in different silos, some accepted anything and everything through one vehicle, and others fell in between.

Some OEEs completely fused their governance functions and governance layers. One OEE completely distributed its governance functions into distinct layers. This diversity in governing

OEEs points to particular areas of interest outside of formal structure. 56

For example, the Apache HTTP Server project’s meritocratic focus on the core web server platform enables a rich ecosystem of allied and external projects to innovate around diverse needs. Apache Tomcat enables rich data interactions and presentations for economic and social platforms to be built on sharable components; and Apache SpamAssassin provides a platform to combat junk e-mail. (And users may further combine these in novel ways.) However, the Apache OEE only formally accepts input from a very small portion of the total Internet community of 1.6 billion users. Through a user forum separate from its development process, but staffed by Apache HTTP Server developers and external experts, the Apache HTTP Server project energetically but informally provides advice to all with ideas or questions about how to implement Apache products, without modifying the core platform. Apache HTTP Server is critical to, but not dependent on, innovations by its users. Extending the functionality of

Apache HTTP Server through modules allows the operator of each instance to freely and safely innovate and implement without adversely affecting any other instance or operator.

By contrast, ARIN allows anyone to contribute policy ideas, but limits input to broad questions of how Internet Number Resources should be allocated. It reserves the mechanical bureaucracy for its own professional staff, and devolves policing use of the Internet, and of In- ternet Number Resources, to Internet operators and third parties. The ARIN membership’s operational overlap with the North American Network Operators Group’s (NANOG) membership has a similar pattern to Apache HTTP Server developers’ relationship with Apache HTTP

Server users. In this way, ARIN concerns itself with the core philosophical and bureaucratic

Internet infrastructure which is much slower to change, rather than the much more dynamic social or technical threats of the month which operators contend with daily. ARIN outsources user participation in policy-making around bad parts of the Internet to the users. Since the questions and threats around Internet topology leave a footprint of 1.6 billion users, it is no surprise that two independent layers and branches of ARIN governance would want to hold the wide mouth of the suggestion box in balance. 57

Similarly for Firefox, and its plug-ins, the Mozilla bureaucracy places a great deal of restraint on the ﬂow of ideas through the OEP. In the browser proper, all changes to a particular module must theoretically pass through at least the individual bureaucrats in charge of the module, other reviewers, and an automated testing process before entering the product. Among modules, changes tend to be approved by a single individual who has the entire view of the project or is a personal champion (detailed in Chapter 4). Since product updates to Firefox and its plug-ins occur through automated mechanisms (unlike Apache HTTP Server which must be updated manually), very concentrated authority appears to be effective in not automatically updating users’ computers with error-ridden software. An analogous centralized, deep knowledge of the system could provide similar risk mitigation at the block lists which supplement

ARIN’s database, although no evidence about governance at third-party block lists was located.

3.5.3 Inclusiveness and participation

As illustrated by Figures 3.2 through 3.4, not all OEPs were funnel shaped. Bulges in the OEP may do more than indicate procedure, they may also reﬂect trust or self selection. Many ideas being discussed in the ofﬁcial forum could indicate a high level of trust in the governance and social characteristics of the forum (not necessarily of the organization).

Observing more ideas start their official journey than are discussed in the official forum could indicate distrust in the governance and social characteristics of the official forum, but trust in the official process, peers, or others.

Both sharp and shallow joints speak to inclusiveness and participation. To the extent that any part of the funnel is wide, individuals making decisions at that part have opportunities for their views included (while narrow parts of funnels may indicate exclusion).

3.5.4 Key ﬁndings

Among the projects and organizations studied, the following implications are evident. 58

1. User participation in OEPs appears more important than core governance structures or sizes. Generally, this suggests a broad approach to engaging and informing constituents rather than a top down approach to governance.

Active narrow channels (individual and small group text-only discussions) are shown to be sufﬁcient and effective for collecting ideas, and for developing those ideas into enhancements.

However, such channels are not necessarily effective at enabling opportunities to participate to the general population.

For users, information is also key to how the technology is perceived. While particular users may readily choose which web browser and plug-ins to install to gain speciﬁc functions, users do not generally get to choose which IP blocklists our ISPs use (nor do most ISPs obviously disclose how they shape our view of the Internet through the use of such lists). The ability to switch among choices within the technological stack (the choice to adopt speciﬁc innovations) is also an important policy issue. IP blocklists (and their aggregates) used by ISPs are commodities, having known and externally testable quality, and highly substitutable. Some Firefox extensions (particularly ad blockers and personal information/communication managers which require the user to supply information) have high switching costs while others are almost clones of each other in terms of appearance and functionality. Almost all Apache platforms have high switching costs since web pages and business applications become increasingly tied to the platforms interfaces and capabilities through customization.

2. Identifying, measuring, and interpreting OEPs and sources requires care. Among the

OEEs studied, counting ideas, potential inventions, inventions, features, and users all yielded different numbers with different meanings. Taking any one metric as an indicator of “innovation” risks misidentifying innovation as an outcome, as opposed to the process it manifests.

If participation from constituents is valued, comparing the number of ideas discussed ofﬁ- cial venues versus the number of ideas ofﬁcially recorded informs where ideas come from, and how to stimulate more. If inventive output is valued, adding more inventors will not help much, 59 but increasing the market size or adoption rate might. If lists of features are valued, marketing will be of more help than more inventors or users.

3. Closely connected enhancements or platforms may be governed completely differently with success. And participation enhances governance, but faces knowledge and other barriers.

3.5.5 Research limitations

This chapter did not study discovery or basic research leading to new science. The purposes of the research and enhancement work conducted by participants of the OEEs were consistently to: a) achieve particular outcomes in particular products, and b) to deﬁne the broad rules by which systems may operate. As such, there was a strong product-oriented focus within the environments studied, but as open environments, they were theoretically required to clearly document their technical processes. Such documentation, even if incomplete, offered invalu- able insights into how the OEPs were practiced, but documentation would not necessarily speak to internal and external social factors inﬂuencing the origins of the current practices. Not all governance actions left records. Despite representation from a wide variety of scales of projects occupying a diversity of roles in various technology stacks, the results obtained herein should not be generalized beyond those particular technology stacks without further data and study.

The following chapters take up some of these issues. 60

Chapter 4

EXAMINING ENHANCEMENT PROCESSES

This chapter concerns data to address the main question of this thesis: How do communication patterns in enhancement processes relate to the success of those processes to yield enhancements? It ﬁrst details the methodology used to examine communications during the open enhancement processes studied. It then presents ﬁndings from eight cases of enhancements.

[[Add: clear separation between observed and analysed features of the OEEs, explain references more]]

4.1 Introduction

The previous chapter established that OEPs in the organizations studied are not strongly shaped by formal structures. Attention now turns to factors outside the organizations’ expressed theory and philosophy about how they should conduct their work.

Within the OEEs, the ideas, information and work to implement enhancements should be conveyed through artifacts such as archives of objective discussion and software code (Sharma et al., 2002). The Open Source ideal prescribes that discussions and software code are to be accessibly communicated, recorded and archived to provide documentation for future contributors to understand the decisions and processes in a project’s history (Raymond, 2000). Recall that one of the OEEs does not produce software, but employs substantially the same kinds of process and environment which mandate that new policy ideas be converted into functions in a manner allowing participants and the public to retroactively inspect the entire policy development process.

Previous studies of source code development have revealed insights about technical output 61

(e.g., code efﬁciency, error rates, distribution, etc.) as relating to change management processes. Such research considered computer source code outputs as the unit of analysis (e.g., those reviewed in Sharma et al., 2002). The present research focuses on the English-language text of communications employed to realize particular enhancements, whether expressed as source code or policies. The goal is to identify social factors around ideas, and how those factors affect the way they become enhancements.

Among Open Source projects, there are many examples of products used by tens of millions of people in which no direct personal contact among stakeholders or OEE leaders occur

(for example, the many Firefox plug-ins produced by individual authors, anonymous collaboration on Wikipedia, etc.). While some Open Source projects routinely meet off-line as part of the enhancement process, others succeed without face to face interactions. This implies that the essential communication elements of successful OEPs that are required to be communicated among collaborators (e.g., shepherds, bureaucrats, leaders, users) can occur entirely via codiﬁed electronic communications systems.

The Mozilla Foundation admonishes contributors to exclusively use its electronic Bugzilla database to record bugs and enhancement requests:

“Unless the bug owner or another respected project contributor has asked you

to email them with speciﬁc information, please place all information relating to

bugs in the bug itself. Do not send them by private email; no-one else can read

them if you do that, and they’ll probably just get ignored.” (Paquet, 2009).

There is both a desire, and an expectation that the OEPs occurs (or is at least documented) openly. However, Mozilla also simultaneously acknowledges that other forms of non-public communication may be more effective at times for contributors:

“When getting a [code] review, try not to belabor a point that a reviewer is

debating you on [sic]. If the debate is involved, solve it in person, on IRC [Internet 62

Relay Chat] or over AIM [AOL Instant Messenger]. A ﬁve minute discussion is

worth an hour of e-mails.” (Spitzer and Flett, 2009)

Public computer-mediated communications was assumed to be the norm in the OEEs studied, and that private communications are the exception. However, exceptions were investigated.

Mockus et al. (2002) have examined software development processes using data from the

Apache Foundation and Mozilla Software Foundation. They found that record sets from project mailing lists, code revision control databases and bug tracking systems provided good data from which to analyze and understand how the software products were developed. Speciﬁ- cally, they employed automated analysis of the meta data attached to individual source code revision records to investigate the roles of individuals responsible for managing and developing projects and modules. They extracted and tested hypotheses about contributor participation and software code quality in Open Source projects. That study, however, focused almost entirely on overall management structures and procedures of the projects and their supporting/supported satellite projects and modules. It acknowledged the importance of communications as a coordination tool for individuals who may never meet or work together in person, but emphasized the role of communication messages as carriers of technical information for, or about, the projects.

Data about source code patches and mechanical detection of technical defects do little to illuminate how new ideas are carried. The Mockus et al. study did not examine progress or success of particular individual enhancements, ascribing possible variances (none were explicitly identiﬁed) among the success of individual changes to the regular output of the broader management processes.

In contrast, the present research does not assume that broader management processes explain how or why ideas succeed, or not. (The previous chapter found against an infrastructural determination). If any process completely speciﬁed the criteria for potential enhancement to be successfully adopted, any entrepreneur of any potential enhancement could guide it through that process to adoption with a guarantee of success. Clearly this is not reality. Potential 63 enhancements must proceed through human judgments and interventions during which contributors may support or prevent adoption on several grounds, including the (potentially vague) appropriateness of any particular idea in context. Technical merits are readily demonstrated through unit tests of proposed changes, but as high proﬁle resignations from Open Source projects over philosophical non-technical differences have shown (e.g., Fielding, 2008; and

Cox, 2009), human factors are important.

Data about values behind individuals’ support for ideas may escape the technical content of communications, but may be shadowed in the interactions among humans who receive, emit and modify ideas during the innovation process. The Apache Software Foundation recognizes the need for individuals in diverse roles to communicate in common:

“Mailing lists are crucial to the operation of the Apache Software Founda-

tion. The Foundation, as well as each of the Apache projects, uses mailing lists

to coordinate development of the software and administration of the organization.

Mailing lists also serve as a primary support channel where users can help each

other learn to use the software.” (Apache Software Foundation, 2009b)

This research studies OEEs’ mailing lists in service of their goal to “coordinate development of the software”, and not their foundation operation or end user technical support goals.

Despite the linear OEP assumed in Chapter 3, are least two kinds of opportunities to receive ideas are evident. The ﬁrst is at the informal beginning, before (perhaps incomplete) ideas join a formal OEP. The second is during implementation where new ideas may modify other ideas already in progress. While a vast majority of ideas known to the OEEs studied do not make it directly into the OEP (Figure 3.2), it’s unclear how well ideas suggested during the process survive. “Lead users” may contribute in the second way toward the end of the OEP, but they do not offer a comprehensive perspective.

This chapter does not initially assume any similarity between idea inputs before or after 64 an idea or enhancement has been adopted at various phases of the OEP outlined in Chapter

3. Through characteristics of the messages themselves, it looks at how ideas are successfully incorporated into OEPs.

4.2 Hypotheses

The following hypothesis draw from the broad relationships discovered in Chapter 3, and attempt to relate the contents of communications to enhancement success. They are drawn from communications observed in the OEPs:

• H1: User participation in an idea during or after the enhancement process, via consider-

ation of their “use cases”, supports adoption.

The ﬁrst hypothesis tests the OEEs’ premise that being open to ideas and needs of users leads to success of enhancements (“adoption”). However, since the previous chapter found that most ideas come from contributors from outside an OEE, those individuals inside OEEs who implement the ideas must be considered. Recall that entrepreneurs in traditional innovation environments may not necessarily be the ones to devise new ideas but are essential since they take risks to bring inventions to the market (Schumpeter, 1982, p. 150). Since the OEEs studied do not use industrially expensive investments that may indicate risks taken, risks can only be expressed through communication of investments such as contributed work and social reputation. Therefore:

• H2: Ideas championed by shepherds who communicate their risk-taking activities are

more successful than ideas whose champions do not communicate their risk-taking ac-

tivities.

Essentially, communicating risks taken—for example, by contributing shepherds’ own work, resources, and support—may be more important to implementation and success than just bear- ing risk. These two hypotheses are related through the communication content by way of 65 shepherds for individual ideas who must consider and express the effects of their proposed changes on the project and user environments.

4.3 Methods

Grounded theory and content analysis were used to identify concepts and exemplars of successful and non-successful OEPs, and successful and non-successful communication patterns.

Source materials were coded and categorized to identify the nature of, and participants in, communication events and OEPs. From broad categories, specific theories were developed about how the activities, now coded, may link to each other. Such specific theories were qualitatively tested and refined in detailed case studies.

4.3.1 Grounded theory

Previous research employing grounded theory with ethnographic methods has sought to match successful and unsuccessful pairs of innovations in and among companies at the project level

(Moenaert et al., 1994). Doing so required assuming that aspects of data are, or are not, relevant for comparison, and biased toward data from recollections of processes and communications, rather than data generated during the processes and communications themselves. The methods and public data sources currently employed allowed records of individual OEPs to highlight their own important elements. Public data enabled thorough external evaluation of the success of individual enhancements unencumbered by corporate conﬁdentiality. This method also provided information about non-successful enhancement attempts (which Moenaert found dif-

ﬁcult to reach) without informant bias toward preferentially disclosing about their successes.

Allowing OEPs to describe their own status, successes and non-successes reduced the empirical instability and theoretical confusion around what is, or is not, a “successful” “enhancement”.

Labels were grounded in observable actions of individuals adopting (or preparing to adopt) 66 ideas rather than in personal opinion.

Of note, the narratives and textual data sources recorded both rapid interactions among individuals—multiple contacts in one day as might be suitable for study via direct observa- tional methods—and also drawn out interactions over months or years, which may be suited to methods analyzing professional letters. Importantly, the nature of the medium forced lags in communication such that responses were not immediate, and introduced at least a small number of sometimes detectable errors in the ﬁxed recordings of communication (for example, via failed delivery of e-mail messages, misplaced or miss-threaded messages due to human or mechanical error, etc.). Although these imperfect records were acceptable to participants as chronicles of their work, the present method remained open to considering supplemental data generated by the participants and OEEs in venues other than mailing lists and Bugzillas.

4.3.2 Field data collection

As Poteete and Ostrom (2004) acknowledged, “Field-based data collection is the most reliable way to get comparable data with external validity and the only way to do over-time studies”.

The individuals and enhancements identiﬁed in the Apache, Firefox, and ARIN OEEs were not sampled randomly. Unusual cases were preferred to ﬁnd both the extremes and the norms.

The data source also cannot be said to represent a fair sample since not all problem solving or enhancement activities were explicitly made public (even though mandates and philosophies strongly require transparency and openness), since participants select the degree to which to participate openly, and since not all enhancements were documented in comparable detail.

4.3.3 Content analysis

Mailing lists were venues to exchange discreet items of communication, where messages are received with almost no possibility of noise arising between the transmitter and the receiver.

As such, no “technical problem” (Shannon and Weaver, 1948) of communication is consid- 67 ered.1 Any noise would be due to poor composition and interpretation by the stakeholders (the

“semantic problem”). Eliminating noise narrows attribution of differences in enhancement success to how communications were used (the “effectiveness problem”). The clear provenance of individual messages, and their explicit content, rendered the message archives amenable to content analysis as a method to extract trends and patterns of communication (Berelson, 1952).

Bugzilla messages also have those properties, but added a layer of administrative structure and information. (Chapter 3 reviewed the Bugzilla system.) While the social communication systems systems studied likely existed in a co-evolutionary state (Leydesdorff, 1994), it was assumed that the communication systems studied (which include primarily discussion lists and

Bugzillas, but also the in person meetings, source code management systems, and project websites and knowledge bases which are not directly interrogated) were stable in their interactions, and did not act selectively on any particular enhancement, during the study period.

Simply, the operational task of this portion of research was to disentangle—from the available textual pieces pertaining to each enhancement—the meaning and signiﬁcance imputed by participants in their messages, along with how receiving those messages affected particular OEPs. By examining the dynamics between shepherds and their OEEs, categories may be found to characterize communication styles as they relate to kinds of enhancement. The goal was to test the analytic utility of breaking apart OEPs within a simple framework (outlined in Chapter 1), as well as to discover or give labels to new general patterns of enhancement or communication which may not yet be well characterized. Although this research concerned communication and enhancements in a plausibly new (globally distributed CMC) environment, with possibly new business and collaborative models via the Internet, it proceeded by following well established methods of content analysis to draw maximally on existing knowledge, while remaining cognizant of differences which may identify important points of departure.

An approach to data gathering, rather than a speciﬁcation, ensured conceptual and analyt-

1Individual participants may have received or read particular sets of messages in any particular order; of this behaviour no data are available. 68 ical consistency among the different data sources used. This approach also enabled potential relationships among alternative theories, concepts and hypotheses to be detected and assessed while remaining sensitive to varying interpretations of concepts expressed and employed by participants (Poteete and Ostrom, 2004), and to alternative interpretations of the hypotheses.

To constrain the scope of data and effort, the following practical limitations were imposed.

1. For a potential enhancement to be considered, a participant must have explicitly communicated about it during May 2008–June 2009. This constraint minimizes variability through time in uncontrolled other variables in the environment. A clear outcome of the OEP must be indicated during that time to ensure that adequately complete data about the OEP may be traced and obtained.

2. A proposed enhancement must have sought to change the project, its environment, or its output, solving some problem. The outcome sought by the original idea must have been attempted, whether or not the outcome was successful. Conversely, a clear statement that the intent of the enhancement would not or could not be achieved identiﬁed non-successful outcomes. Abandonment differed as an intermediate, non-successful state through lack of actions by shepherds or bureaucrats toward implementation for an extended time.

3. Only discussion threads with one reply or more were considered, on the assumption that replies indicated consideration and successful communication.

4.4 A pilot effort

An initial pilot explored the scope of the mailing list discussion data. The approach was not pursued further since it did not easily permit comprehensive work with categorized components within individual messages. Nonetheless, it informed the method of analysis ultimately implemented, and yielded useful quantitative historical data. It signiﬁcantly informed the framework laid out in Chapter 1. 69

All three OEEs studied—Apache HTTP Server, Mozilla Firefox, and ARIN’s Policy De- velopment Process—employed mailing lists as the main communication venue among project members and stakeholders physically located worldwide. For each project, the primary technical development and discussion list was chosen as the main data source. The user support lists for stakeholders who are not technical contributors, were also considered as a primary data source. However, preliminary analysis revealed that ideas originating in the user support list did not link consistently to the OEPs across all three projects. Apache’s HTTP Server user support list received a moderate volume of sophisticated technical questions about how to conﬁgure and deploy the many existing core and module features. Mozilla’s Firefox wishlist contained a small volume of end-user support questions and general suggestions. ARIN’s

ARIN-discuss list was a low volume mix of operational questions, broad policy ideas only occasionally related to on-going policy development, and interpersonal drama.

With both ARIN and Apache, copies of monthly archives of the mailing lists for the study period (spring 2006 to summer 2009, expanding on the study period described in Chapter 3) were downloaded from their respective mailing list manager websites (ASF, 2006; ARIN, n.d.

2) and then decompressed and concatenated into one standard mbox ﬁle (Hall, 2005) per mailing list. The Mozilla Foundation does not archive its mailing lists on a monthly basis, but instead provides public access to individual messages via its news servers (Mozilla Founda- tion, 2003). The Thunderbird e-mail and news client (version 2.0.0.22 (20090605), Mozilla

Foundation, 2009b) was used to retrieve the mailing list messages from the news.mozilla.org news server for the study period, producing one mbox ﬁle per mailing list.

Finally, the four mbox ﬁles (a user and a developer list from ARIN and Apache) were imported into Thunderbird as local folders. Thunderbird allows messages in each of the mailing lists to be tagged for an arbitrary number of deﬁnable categories, viewed and sorted by author, date, conversation, conversation length and categories, and searched by key words in any of the above. For convenience, H. Ogi’s Tag Toolbar 0.7.80 (Ogi, 2009) was added to Thunderbird to 70 permit several tags to be easily selected and added to individual messages at one time.

A pilot of ﬁve conversations were selected from each mailing list for cursory examination to identify likely candidates for categories of communication. An initial set of broad categories were developed based on the communication purposes required for a mailing use to fulﬁll its intended function (seeking/contributing information, seeking/contributing work, seeking/contributing approval). The possibility of discovering other useful categories was kept open, and resulted in the recognition of another broad category, namely opposition to ideas or suggestions. Each conversation considered consisted of at least one initial message outlining an idea, and at least one response. Messages which received no response were set aside as one variety of non-successful enhancement processes. Approximately a dozen other conversations containing subjectively interesting subject lines were also read casually.

Messages were viewed in groups using Thunderbird’s included “Search Folder” utility, which ﬁnds and displays messages with arbitrary combinations of key words. This feature was also used to ﬁnd additional incorrectly threaded messages contributing to, or arising from, the initial conversations based on key words and concepts. All messages pertaining to each enhancement were organized into its own sub-folder for ease of handling.

Early on, it was noted that mailing lists were not comprehensive of all ideas or information sources entering the OEEs (e.g., “EE”, 2009, who referenced information from the project’s community wiki). For such cases, if another resource was explicitly mentioned in the discussion, then that resource was reviewed for information about the relevant potential enhancement.

Since the kinds of external resources cited differed across all three projects, they were not used to drive the investigation. Discussions detailing perceptions and questions of each project’s

OEE were also noted if encountered by chance. For example, the Apache commit process, as documented at “Integrity of Apache source code” (Beverley, 2007), provided a contrasting operational perspective to the formal policy.

From the broad categories identified, narrower categories were constructed. From each 71 piece of communication, the dimensions and components which may represent distinct parts of an OEP were fit into those categories. Parties and subjects of exchanges were identified:

Who is the communicator? Shepherd, supporter/detractor (“stakeholder”?), neutral/other; and what are their motives? (Rogers’ “senders”)

Who is the intended audience? Shepherd, supporter/detractor (“stakeholder”?), neutral/ other; and what are their motives? (Rogers’ “receivers”)

What is communicated? seek/gain/give physical/social/knowledge resources? (Rogers’

“messages”)

The data sources explicitly stated how and where and when the communications occurred

(Rogers’ “channels”). And from communications which indicate support, objection or decision- making, the data said something about acts of adoption (Roger’s “effects”). For each action instigated, an attempt was made to identify an authority to act. Recall that while OEEs accept and solicit contributions from the community, such efforts are organized such that relatively few individuals are trusted to accept enhancements into the published products. These individuals are identiﬁed by in the public documentation for the product or module.

The following categories of message contents were expected based on operational documents of the OEEs as reviewed in Chapter 3.:

• Seek: an idea, support/supporters, opposition/detractors, information;

• Response: an idea, supporters/supporters, opposition/detractors, information;

• Authority/approval: provided, sought, denied by participants;

• Type of resource communicated: contributed or described technical, social, or intellec-

tual resources;

• Support: commitment to action, advocacy for awareness, agreement with stated objec-

tives or ideas, postpone implementation; and 72

• Objections: unbalanced work/rewards, undesirable analogues, logic/reasoning fault, deny

the problem, postpone consideration.

For each conversation thread listed by Thunderbird, potential lost fragments were manually sought and gathered by searching for other messages by the most active participants of the conversation, as well as for key words, concepts and titles in messages which were sent close in time to the conversation of interest.

Collecting messages and discussions with particular emerged patterns of categories (for example, objecting to an idea while seeking support for another related idea) was thought to be useful in informing the types of enhancement, the types of communication, and the extent of enhancement success. Further samples for examination were selected as follows.

The ﬁrst message (“head”) of each discussion could start a distinct OEP. For each discussion forum, the heads of all discussion threads were displayed in chronological order in

Thunderbird. The number of discussion heads in each list was estimated by multiplying the number of discussion heads on each page displayed by the number of pages required to display all heads. For example, in the mozilla.dev.ﬁrefox discussion, there were 163 pages of 16 heads each, or approximately 2,600 heads; and approximately 11,700 messages in total distributed unevenly among the 2,600 discussions. (Exact counts would have provided little additional analytic clarity.) A handful of discussions about individual enhancements were split over multiple threads. Some threads discussed more than one enhancement. The lists also contained routine administrative messages not about speciﬁc enhancements, spam and off-topic noise, unsubscription requests, etc. which were ignored for the present research.

Coding up to 10 discussions in each of three OEEs was hoped to provide sufficient coverage of typical enhancement processes. To explicitly not pick winners or losers, the top-most discussion thread at every nth page of page heads was chosen (where n=number of pages of heads divided by 10). Questions about existing, potential, or broken functionality which did not include a specific suggestion for enhancement were excluded, as were notifications about 73 implementation of previously approved changes. The goal was to identify at least two potential enhancements for each of the years 2006–2009, evenly representing primarily industrial, primarily social, and primarily intellectual enhancements. But, this method did not reliably or comprehensively identify the relatively small proportion of ideas entering the formal OEPs, nor all discussions contributing to those items which did enter the processes. Therefore, it would have been required to work backwards from information about users, ideas, keywords, and references found in the formal OEPs back to the discussions. However, another issue emerged.

Attributing categories at the message level was found to inappropriately combine units of action or meaning. For example, a question or response on a single action may each be one word long or ten paragraphs long. Some participants discussed different parts of previous messages in a single response. Some participants only responded to a small part of a message and explicitly omitted the remainder. Some participants responded to several distinct ideas using a single response, etc. The participants themselves did not use whole messages as their unit of meaning or action. Therefore, it would have been inappropriate generally to claim that one of several kinds of content dominated a message, or that six different kinds of content were co-dominant, or that three instances of support should have the same analytical weight as one instance of opposition within the same message. Recognizing and recording the categories of content as the conceptual units employed by the participants would allow phenomena at smaller granularity to be tested along with natural and constructed higher units of agglomeration.

Nonetheless, some useful observations were obtained (see Table 4.1).

4.4.1 Shape of the initial data

The development mailing lists lacked some technical details about OEPs, such as: work and release timelines, explicit role of the entrepreneur and ideas within each OEE, the product and the project, formal ownership and approvals, documentation, etc. Since the formal OEP documentation were housed in other tools (Bugzilla for Mozilla and Apache, PDP for ARIN), 74

Table 4.1: Overviews of Apache, Firefox and ARIN mailing lists and Bugzillas. Sources: projects’ mailing list charters and indexes, Bugzilla archives.

OEE List Purpose Size ARIN ARIN-discuss board and staff discuss 2006: 4 threads internal ARIN matters 2007: 30 threads 2008: 29 threads 2009: 19 threads approx. 1,000 messages ARIN ARIN-ppml initiate and discuss policy 2006: 140 threads + 7 policy proposals, other ideas proposal threads 2007: 160 + 22 PP threads 2008: 200 + 15 PP threads 2009: 110 + 8 PP threads approx. 10,000 messages ARIN ARIN-consult seek member input on initia- very few tives originating from within the bureaucracy Mozilla mozilla.wishlist seek public suggestions, 2006: 280 threads organize support and 2007: 180 threads resources for technical or 2008: 160 threads policy changes 2009: 40 threads 1987 messages Firefox mozilla.dev. a forum for project 2006: 580 threads apps.ﬁrefox leaders, developers, 2007: 520 threads bureaucracy to originate 2008: 55 threads technical ideas, policy ideas; 2009: 400 threads discuss with technical users 11,366 messages Apache apache-users support technical 2006: 2,800 threads support implementation for end users 2007: 2,400 threads 2008: 1,900 threads 2009: 960 threads 31,000 messages Apache apache-dev technical development 2006: 1,060 threads problem solving and 2007: 960 threads progress reporting 2008: 700 threads 2009: 360 threads 13,400 messages 75 such formal external archives would also have to be explored for technical information.

Based on information in the mailing list messages, it was decided that source code management systems would not be used as a primary data source. “Checked in” source code changes

(which were sometimes attached and mostly void of decision notes) had to undergo at least one review or approval by a project leader (via Bugzilla, the mailing list or a meeting), and hence had to have been substantially adopted by discussion list participants. Conversations pertaining to individual enhancements proposed in different years did not subjectively appear to be different with respect to topics and actions discussed.

Each OEE held within it dozens to hundreds of concurrent enhancement processes, as well as discussions about how to change features of the OEEs. The goal was to find general patterns of communication and enhancements, not to exhaustively chronicle the particular environments under study. Careful case selection was thought to provide rich details of significant individual enhancement, which define the common case and extremes.

4.4.2 The revised procedure

The revised procedure took care to allow the data to say more for and about themselves than under the pilot procedure. For example, it recognized the different formal phases of the OEPs in guiding the discussions, and the roles of diverse stakeholders. It remained rooted in content analysis and grounded theory, but sought to more comprehensively identify and link the human motives and their communication by ﬁnding edges of disagreement. The procedure follows:

1. Using each project’s formal workﬂow tools (Bugzillas and ARIN PDP), a list of ideas

(enhancements or policy proposals) which had communication or implementation activity during the study period (May 2008–July 2009 as in Chapter 3) were obtained. This is deliberately not to exclude enhancements which may require work over a long period, while retaining a common period of communication and implementation activity. An idea labeled as an “enhancement” by a participant indicated that someone in the OEE thought the idea would make 76 the product better. Starting from the formal lists to isolate relevant messages from the vast majority of ideas that did not enter the formal OEP. Selecting for enhancement requests removed routine bug reports, user support requests and other noise which did not directly contribute to any particular envisaged invention.

2. Successful and non-successful enhancements were identified from the lists of proposed enhancements by finding all reported items in each of the following labeled Bugzilla status categories: “NEW”, “UNCONFIRMED”, “RESOLVED FIXED”, “RESOLVED WONTFIX”; and policies with closed, draft or numbered statuses in ARIN PDP. This mechanical step retained only the unique ideas which the projects’ participants considered to be within the scope of their projects. This filter also consolidated duplicates and eliminated miscategorized reports, operator errors and other individual items such as spam containing no information about OEPs.

3. Within each of the three OEEs, three types of enhancement requests were sought. The

first kind were enhancements requesting original new functionality, which does not simply extend existing functionality in readily anticipated ways. This kind of enhancement would refer more to new concepts than existing platform parts. The second kind were enhancements to enable new functionality required to work with a new third-party platform or usage environment. The third kind were specific changes required for compatibility with external innovations, perhaps around a new standard or feature in a comparable platform. Data collection did not focus on bug and security fixes having clearly defined input and output parameters (e.g., make this function do expected behaviour X instead of unwanted behaviour Y, build/modify a test suite, test and verify the revision, and complete documentation indicating about the fix).

While interactions with third-party entrepreneurs were encountered and noted (e.g., Firefox bug 455283), requests to fix specific incompatibilities only differed from internal bug fixes by the involvement of a focused external advocate. Successful non-contentious enhancements excluded requests to document features (e.g., Firefox bug 252136), and cosmetic changes to display product version number (e.g., Firefox bug 250260). All ARIN policy proposals were 77 subjected to some debate. Two examples of non-contentious Apache HTTP Server (Case 0, and the first portion of Case 1) illustrated the basic requirements of successful simple enhancements.

4. Individual OEPs were chosen as case studies to cover ranges of possible factors (especially those hypothesized in the framework) which could inﬂuence the handling of an idea

(such as length of time in process, number of participants, idea source, persuasions, scope of proposed changes, resources, competitive comparators, scope of stakeholders).2 It was also important to include incremental enhancements and both successful and non-successful ideas to be able to highlight factors inﬂuencing outcomes. Sought in particular were ideas which continued through substantial majority the OEP steps, but which did not realize success after substantial resource investment; ideas suggested by core contributors or project leaders which did or did not succeed; and ideas which transitioned between apparent success and other outcomes.

5. Each selected enhancement’s transcript was read and tagged for basic information: shepherds, contributors, and bureaucrats (and changes in role holders); one-time contributors; relationships of these individuals to the projects; signiﬁcant pauses in work. Action-oriented communications (or exchanges/patterns of the same) were sought and labeled. The emergent list of actions recorded in the communication around potential enhancements included:

Technical:

• Requests or provision of work, alternatives, disclaimers: Since work was reviewed and

revised in phases, requested or provided work incorporated incremental improvements.

Alternative implementations and use cases are often requested, provided, and considered.

• Requests or provision of technical information, speculation: Some participants worked

2It was not within the scope of this research to directly examine particular individuals’ negotiation tactics or tendency toward reciprocity over multiple interactions about multiple ideas, although such an examination could offer additional insights about the role of reputation in OEEs. 78

on detailed design or implementation with incomplete information about the current or

proposed systems affected. Known mechanical details, and best guesses, were both used.

• Offers, provisions, and postponement of technical or conceptual work: Users provided

unsolicited use cases and ideas supporting particular changes. Participants offered to help

research or implement particular details to gain desired capabilities. Others proposed

postponing work when resources (mostly expert human attention) was insufﬁcient.

Administrative:

• expressions of approval, concerns, disagreement, and disapproval: Collaborations re-

quired consensus to proceed, and formal approval for changes to be accepted. In the

course of reaching consensus or approval, disagreements were expressed.

• repetition; assessments of the problem or discussion: Conceptual, technical or admin-

istrative issues may stall work or discussion. Participants analyzed and summarized

common agreements about discussions or progress to identify logical next steps.

• requests and fulﬁllment of administrative actions or information: Regular workﬂows

required acknowledgement or approval to conduct planning and implementation work,

or to adopt ideas. Work may wait on permission from an unexpectedly unavailable or

lazy volunteer bureaucrat. Participants directly asked about current progress, requested

administrative action, and also advice about next steps.

Conceptual:

• requests or provision of ideas; answering/unanswered questions: Shepherds lacked re-

quired conceptual information, as both informal discussions and formal processes demon-

strated. Minimally, ideas and changes proposed required description. 79

• displays of confusion or ambiguity: Confusion about a proposed enhancement is ex-

pressed when participants requested clariﬁcations about proposed changes, existing or

proposed characteristics, and existing or proposed use cases.

• arguments through reasoning, justiﬁcation, evidence: Disagreements about necessity and

competing approaches, particularly when considering use cases, were logically and emo-

tionally argued with reasoning, technical and social justiﬁcation, and evidence.

Social:

• provision of agreement, support, suggestions: Some users and contributors simultane-

ously expressed support, suggestions and offers of work when discussing a new idea.

• encouragement, gratitude, discouragement, threats, apologies: Collaborators used com-

mon relationship management and persuasive tools. Such tools were not speciﬁed in the

formal or informal process, nor expressed through technical work alone.

• admissions of incorrectness, compromise: Participants changed support for particular

concepts or parts of ideas as work proceeds or as new information was learned.

Use cases:

• citations of third-party information or use cases: Information about third party use cases

could directly link shepherds with their users. Information came from users known to

the OEEs, other parts of the projects, other projects, other environments, etc.

• considerations of: legacy, use cases, analogies: The OEEs produced widely adopted

products (thousands to hundreds of millions of users). Changes removing functionality

were externally costly to users and third parties. Shepherds considered effects on the

broader environment, and precedents from competitive or analogous systems. 80

• requests for follow-up inventions: Implementing enhancements generated other ideas

and potential enhancement which were documented.

These were taken as the relevant categories of action in which participants communicated, interacted with, responded to in the data through their actions.

6. Occurrences of above events in OEEs were categorized (frequently, rarely; beginning, middle, and end of adoption; by shepherds, bureaucrats, users, or outsiders)

7. Adherences and deviations in OEPs were identiﬁed and used to identify the operational bounds of the OEEs as background to isolate communication patterns associated with successful and non-successful OEPs.

4.5 First impressions from the revised procedure

“Bugzilla is a complete mix of real bugs, enhancement requests, vague re-

ports that may or may not arise from a bug, and complete nonsense that some

reporter insists on reopening and we can’t be arsed [sic] to pay attention to. That’s

the downside of an open Bugzilla for such a widely-used project [Apache HTTP

Server].” (Kew, 2009)

This section outlines some general observations about the OEEs, communications and

OEPs to be described in detail in subsequent case studies.

4.5.1 Resources

Unlike commercial innovation environments, the OEEs were unconcerned with financial or physical resources. They required labour, administration, and infrastructure, but financial gain was not a prime motive, limit, or prospective benefit or resource. Most highly valued were contributors around a particular enhancement, and the amount of time and expertise contributed, regardless of how the “volunteer” contributors were compensated outside the projects. 81

Apache’s paid staff were administrative only. ARIN’s paid staff may invent a little to operate policies. Mozilla’s paid staff may invent or innovate more when coordinating product/project management, release cycles, partnership agreements, and internal infrastructure. By comparison, several Firefox, Apache, ARIN plug-in projects described the previous chapter succeeded without paid staff.

Ivar Jacobson’s (1987) concept of use cases, but not the documentation formalism, helped to identify situations in which an aspect of a product was used by some user to accomplish some desired objective. Discussions around meeting or preventing particular use cases (and attendant costs) involved responding to or ignoring user suggestions and requests, documenting how to reach particular objectives, and arguments for prospectively doing the same with new ideas.

4.5.2 Enhancement processes

The OEPs varied on several dimensions. Enhancements required hours to years to complete, formally involved one or dozens of individuals, and affected dozens to hundreds of millions of stakeholders. Ideas required hours to years to be rejected, and some were rejected and became resurrected in succession. Some ideas formally arose from several other ideas, others inspired subsequent ideas, others still arose from non-successful more complicated ideas. Some informal discussions showed even more variety.

The broad enhancement process, connecting a new idea to a new capability adopted by a user, required subsidiary enhancement processes. The four stages plotted in Chapter 3— ideas, potential inventions, inventions and features—conveniently framed a single cycle out of repeated flows of work and communication. Several common kinds of decision points were indicated, roughly matching the development process activities outlined by Sharma et al. (2002) which included: problem discovery; finding volunteers, solution identification; code development, testing, review, commit, and documentation; and release management. Some decisions were reflected in status flags and administrative actions. Other decisions were reflected in 82 no action taken when required. Ideas could stop advancing in OEPs without a formal status change. Some decisions were made outside the formal OEP, using formal OEPs only to meet procedural requirements. At times, all of these decisions could be made by a single individual

(not necessarily the shepherds) trusted by an OEE.

Common to the OEPs was that the ﬁrst decision on an idea concerned its validity, based on previous records of the idea, and whether the contemplated capability already existed. Invalid ideas from informal discussions were not entered into a formal process. In the formal systems, duplicate suggestions of a commonly sought capability were administratively merged into the oldest instance, while requests for existing functionality were directed to documentation or support discussions. In this way, most “new” ideas were administratively halted. Bureaucrats were identiﬁed as anyone formally tasked by a project or organization to perform a type of task routine to the project or organization’s policies and procedures.

Feasibility was a common subsequent decision criterion. Each enhancement must fit the scope of the product, project, organization, and broader social and technical environment; be technologically possible; and be plausibly desirable by adopters. Also considered were priority of implementation and availability of limited human resources. Ideas deemed implementable lost the generic input received status (e.g., “NEW”, “UNVERIFIED”) for a status indicating permission to implement (e.g., “VERIFIED”). Some OEEs assigned “verified” ideas to particular volunteer shepherds to guiding the ideas through OEPs. Except in the case of ARIN PDP which specified a schedule of actions for policy proposals, it was possible for ideas to linger indefinitely due to disinterest or other priorities. The Bugzilla platform facilitates a passive, non-binding vote for each idea it records, but the vote counts were rarely discussed by Firefox or Apache HTTP Server OEP shepherds. As discussed in Chapter 3, Apache used a separate voting system, while ARIN also sought consensus from discussions and votes at live meetings.

Valid ideas from non-technical contributors were assigned to shepherds who were technical contributors. Non-technical contributors of ideas almost never followed up or contributed 83 further to their ideas’. An enhancement could be assigned to different shepherds at each phase or decision point of the formal OEP. In ARIN PDP, an explicit shepherd was assigned to each idea to advance it through the formal innovation process, while Firefox and Apache shepherds

(“assignees”) were more or less free to take over or step away from inactive ideas.

Different concepts of a problem or solution could be debated, but not all solutions may be implemented. A shepherd, but not necessarily the assigned one, may dedicate resources toward fully specifying or implementing an enhancement, implying a (possibly weak) consensus that the enhancement was worthwhile to explore. During implementation, participants may question whether a problem or use case was adequately understood, and whether the proposed implementation would be sufﬁcient to address the problem (in completeness, quality, etc.).

Among the circumstances which may trap an idea in a particular phase of (in)completion indefinitely, or return it to an earlier phase, were: informal and formal reviews, approval processes, new subsidiary ideas and suggestions, environment changes, disappearance of shepherds or stakeholders, administrative issues, quality control, testing, etc.

Finally, only particular snapshots of software received the extensive and specialized testing resources to be deemed sufficiently good for public release. Similarly, opportunities for formal policy approvals were limited by infrequent meetings. At each phase (idea, potential invention, invention, adoptable feature), the OEE must agree that the enhancement is viable, desirable and sufficient. Some ideas experienced parts of the OEP multiple times as components or the environment changed. Open calls for comments and requests for comments from particular experienced individuals were used to gain favourable reviews. OEEs may also assign knowledgeable individuals to review and approve work. Even though OEEs should not theoretically depend on any particular individual, lack of response from particular specified approver could stall progress. 84

4.6 Case Studies

From all OEPs encountered, the following diverse set of case studies were selected to illustrate examples following policy ideals, and examples testing the bounds of the OEEs studied. They test and illustrate the main hypotheses, and enable theory to be generated from data gathered.

Quotations referenced in parentheses are provided in Appendix B.

4.6.1 Case 0: Apache HTTP Server log rotation trigger (Bug 44427)

Note: Apache maintains two streams of its HTTP Server: a stable stream intended for deploy- ment, and improved primarily by critical security and bug ﬁxes, with few new features; and a development stream intended for testing new concepts and functionality. The development stream is rebranded the stable stream irregularly every several years. The present research examined enhancement in the development stream, and did not actively consider Apache’s process of “backporting” new features from the development stream to the stable stream.

Background: Web servers record accesses and errors to log files. Apache HTTP Server instances may need to append log files at any time, but only one action may be performed on a log file at one time. Externally archiving a log file requires either that the server stops to release the log files for an operation and then restart, or that log entries be lost while the log files are manipulated externally. This enhancement did not attempt to specifically change how users or third parties handle log files, but offered a generic way to have more access to log files.

Basic idea: On February 14, 2008 a trusted ASF committer, “Rainer Jung” identiﬁed a

“common problem of how to compress/archive log ﬁles without restarting the server processes”

(Jung, 2008). He proposed a mechanism to tell the server processes to temporarily yield control of the log ﬁle when conditions merit compressing or archiving log ﬁles.

Synopsis: Within this enhancement’s Bugzilla entry, “Rainer Jung” proposed the idea, discussed third party use cases and implementation alternatives, outlined a solution and con- 85 sidered related parts of the product. He submitted a prototype implementation (a “patch”), requested assistance with a more complete implementation, and offered to perform additional work. Since it was unlikely that “Rainer Jung” composed and tested 400 lines of software code in under three minutes, as logged by the timestamps on his Bugzilla entries, it is reasonable to conclude that this idea was substantially developed elsewhere prior to entering the formal OEP.

Discussion: During 2007, logging ideas and issues were discussed in approximately 20 developers mailing list conversations, culminating in substantial improvements spearheaded by “William A. Rowe, Jr.”, who is an ASF member and an Apache HTTP Server Project Man- agement Committee member. “Ruediger Pluem”, a trusted contributor, had commented on various ideas, and tested and reviewed prototype implementations throughout that time. Since all relevant stakeholders had been exposed to the internals of the logging system, the Bugzilla documentation generated for this idea likely identifies the only necessary and sufficient communications elements required for the OEE to adopt and implement an idea. The Bugzilla discussion incorporated information by reference—in the form of the “common” problem identification and common use cases—and directly by including a copy of the technical changes and their description.

After “Rainer Jung” submitted his prototype in Bugzilla, he received support from a single individual, “Kevin Connor”, regarding how the change would help “Kevin Connor” test his own inventions. “Rainer Jung” acknowledged “Kevin Connor”’s input and submitted a slightly revised prototype on February 17, 2008 based on “Kevin Connor”’s input. “Rainer

Jung” declared his work ﬁnished and asked bureaucrats for formal review for inclusion in a future version of the product. No other individuals used Bugzilla to communicate about this idea.

Unlike subsequent cases, this enhancement did not raise concerns about legacy issues since the improvement did not alter or remove existing functionality, nor impair any third-party tools or systems built around the logging system. The recorded communication was mostly a mechanical monologue broadly describing technical considerations—including some disclaimers about 86 use cases known not to be supported—and which included all formal requirements.

Almost a year later on January 11, 2009 the requested formal review occurred, and “Rainer

Jung” received technical input from two experienced individuals via the developers discussion list: “William A. Rowe, Jr.” who completed major work on the logging system in 2007 and

“Joe Orton” (also an ASF member and PMC member). After a total of eight messages on the developer mailing list (during which one disapproval was informally expressed about a misun- derstood detail about the implementation, and “Rainer Jung” thanked a reviewer for pointing out an oversight), “Rainer Jung”’s work was accepted. Approval was conditional upon “Rainer

Jung” resolving some logical and aesthetic consistency issues in related existing software code, a process which generated eight further messages over four days.

At the suggestion of “William A. Rowe, Jr.”, “Rainer Jung” looked through historic summaries of enhancements (in the project’s CHANGES ﬁle) to identify when the inconsistencies were introduced, and did not ﬁnd much detail (Jung, 2009). No participant expressed the need to use the project’s source code revision control system to discover who introduced the inconsistencies. Neither “William A. Rowe, Jr.” nor “Rainer Jung”—who had worked on parts of the logging system for the previous two years—was personally aware of some of its details.

This indicates that they were substantially relying on explicit knowledge and documentation to do their routine work. Since the participants did not subsequently use the readily available means to record or seek the providence of the eye-raising changes in the CHANGES ﬁle, their actions indicate information which becomes valuable to an enhancement process may not necessarily be recognized or available when needed. Users of the Apache HTTP Server software would not see the changes until months later when the new feature was included in a product release. After completing work to implement this idea, ideas and issues related to logging were discussed (by the individuals mentioned, and others) in at least a dozen further conversations through June 2009.

In summary, a single well-positioned shepherd of an idea successfully convinced his bu- 87 reaucrat peers to adopt a simple, relatively contained and uncontroversial invention within a one-year timeframe. While this case outlines the sufﬁcient communications elements for formal bureaucratic adoption of an invention, it does not identify the necessary communications elements of the full OEP leading from a new idea to something adoptable. Subsequent cases examine more substantial enhancements.

Of methodological note, this current research relies on the same records which the project’s bureaucrats and shepherds access to make decisions about an enhancement. The public records do not necessarily enable an observer to trace with detail the participants’ sources of background and tacit knowledge, but the participants’ (lack of) application of such tacit knowledge in this case is evidenced by their references to it in use, and in records of their related works.

Thus, the method employed to study the OEEs may not be much blinded by lack of access to tacit knowledge for the simple cases.

4.6.2 Case 1: Apache HTTP Server enhancement to support SNI (Bug 34607)

This case was an enhancement in two parts addressing most OEP features. It was a discreet idea which was clearly separable from concurrent activity. Its name is a clear and speciﬁc technical term which was simple to locate in mailing list and Bugzilla archives. And it contains and builds on the communications elements identiﬁed in the previous case of invention.

One prospective adopter wrote: “[SNI] is IMHO the most important change [to Apache

HTTP Server] in the last 10 years,” (“Ian G”, 2009). The enhancement was implemented over four years under three different shepherds working with internal and external stakeholders, despite participants sharing a common understanding of clear, standard-based requirements.

Background: Server Name Indication allows a web server to host multiple websites on a single IP address. SNI is signiﬁcant for website providers for several reasons. Because IP addresses are in limited supply, their use incurs ﬁxed and reoccurring administrative and capital investment and overhead. For security, website providers and users increasingly demand to 88 encrypt their transactions to foil eavesdroppers. Fully implementing SNI would enable website providers to easily host many more secure websites using fewer resources, but without requiring them to do so. Implementing SNI on a popular web server directly supports the work of all web browser publishers to improve the security of on-line transactions for web users.

Deploying SNI would also remove the (at the time, 2005) most substantial known method for malevolent Internet users to eavesdrop on web trafﬁc and transactions (“Ian G”, 2009).

Basic idea: Implement SNI in the Apache HTTP Server.

The following timeline outlines the OEP for SNI in Apache HTTP Server as recorded in the ofﬁcial discussion forums. Theoretically, no other conversations pertaining to implementing

SNI in Apache HTTP Server should have occurred. However, the idea of SNI did not appear ex nihilo, and prior discussions certainly would have involved website hosting providers, formal or informal standards groups, web server publishers, web browser publishers, and members of the external OpenSSL project.

Timeline: The Bugzilla record of this enhancement noted events given in underlined text below. The Bugzilla text is approximately 10 per cent of the length of the text of the developers’ mailing list discussion. Note: In subsequent cases, both Bugzillas and developer discussions are considered, but summarizeimportant features through direct quotes and actions.

April 21–25, 2005: Paul Querna, an ASF member, announced on the developers’ mailing list his intent to implement software code to support SNI for non-secure communication. In a quick four days, he proposed the idea, discussed third party use cases and alternatives, described a solution and its isolation from related parts of the platform, submitted a prototype implementation, requested assistance with a complete implementation, and offered to perform additional work. He referred to an external standard for SNI contained in RFC 3546 (Blake-

Wilson et al., 2003), and sought input from other Apache HTTP Server developers. None was provided, and Paul’s code was accepted into the core product on his own authority shortly thereafter. In contrast to the OEP in Case 0, the change was accepted without recorded 89 independent review or input in the developers’ mailing list. This is Apache HTTP Server’s

ﬁrst adoption of a technical implementation of the SNI innovation.

April 25, 2005: Paul announced he is unable to implement the secure component of SNI until a standard third-party cryptography platform (OpenSSL)—used by Apache HTTP Server for encryption—introduced the required cryptographic functionality. At the time, there was no urgency since the two major web browsers (Mozilla Firefox and Microsoft Internet Explorer) did not support SNI. Paul contributed no further code to implement this innovation.

October/November 2005: Mozilla and Microsoft announced plans to support SNI.

January 2006: The OpenSSL project announced forthcoming inclusion of the functionality required by Apache HTTP Server to implement secure SNI. This news was noted in Bugzilla by Joe Orton in January 2006, and later by another contributor on the developers’ discussion.

April 2006: “Kaspar Brand”, an outsider to ASF, submitted a software patch to complete the secure SNI implementation, based on a preliminary revision of OpenSSL. After overcoming an administrative barrier to license “Kaspar Brand”’s submitted software code to ASF, the patch enters Apache HTTP Server’s formal development process. The enhancement was conceptually adopted again by the few stakeholders who expressed a preference, conditional on details to be ﬁnalized later.

November 2007–February 2008: Work resumed on secure SNI as the required work by

OpenSSL to support SNI was completed in October 2007. “Kaspar Brand” was assisted by core Apache HTTP Server developer “Guenter Knaf” under the review of Joe Orton (whose only recorded further contribution to this idea was ﬁnding some bureaucratic and conceptual technical issues). In January 2008, a proposal to include SNI in the upcoming version of

Apache HTTP Server was rejected for potentially being incompatible with third-party modules, and because expert leaders and contributors were being too busy with the upcoming release.

Each software release requires substantial and sustained attention from project leaders, senior developers and other contributors for several weeks to ensure that the software is as defect free 90 as possible prior to public use. In February, “Dirk-Willem van Gulik” contributed a test suite to verify the secre SNI implementation and conﬁguration.

March 2008: After working at an Apache developers’ “hackathon” in which secure SNI was presumably discussed in person, Apache core contributor “Ruediger Pluem” discovered that the SNI work was off-course administratively. He lost track of its formal status again by

October 2008.

June 2008–November 2008: “Kaspar Brand”’s work continued after learning that SNI would not be in the version of Apache HTTP Server to be released in the near future. Contrib- utors discussed various potential use cases and implemented.

August 2008: A representative from publishers of the Mandriva Linux operating system announced they have adopted “Kaspar Brand”’s (as yet incomplete) work and will start to distribute it with their platform. Several individuals suggested enabling the work on an experimental basis in the ofﬁcial Apache HTTP Server.

October 2008: Core Apache administrators inform SNI supporters that it would be procedurally impossible to meet the required schedules to include even an experimental version of secure SNI for the next release, and offered no suggestions. They also indicated that further testing was required, which could not be aided by the unsolicited external offers of resources to do so. Prospective adopters expressed disappointment. The major web browsers gained support for secre SNI, and the required OpenSSL functionality was in the ﬁnal stages of testing.

March 2009: An Apache administrator expressed support for enabling secure SNI on an experimental basis. “Kaspar Brand” continued to work on secure SNI, despite “lack of response” from bureaucrats in recent months. He openly challenged “Ruediger Pluem”’s “FUD

[fear, uncertainty and doubt]”, censorship and inaction on secure SNI, to which he received no direct public response.

March 2009–May 2009: “Kaspar Brand” and “Ruediger Pluem” exchanged notes on an almost daily basis about on-going work to, substantially complete secure SNI. Their messages 91 included noticeably more social pleasantries than all correspondence on secure SNI until this point. The secure SNI patch was accepted into Apache HTTP Server in late May 2009.

Sixteen Apache contributors subscribed to the Bugzilla updates for this enhancement (nine contributed information), but at least 22 individuals contributed to the developers’ mailing list discussion (three contributors to the discussion being also subscribed to the Bugzilla updates).

Although the two main developers contributed information to the Bugzilla records, the vast majority of their work and communication occurred through the discussion list. Bugzilla recorded few substantial design and implementation decisions which occurred in the discussion list.

Discussion: From these two very favorable cases—where empowered individuals drove changes—emerged some commonalities as well as some differences.

In both cases, external technical information was incorporated into the discussion and documentation by reference in preference to by direct inclusion, while internal technical information was incorporated by value in preference to by reference. Participants included verbose details of use cases, but only provided references to technical documentation. Both cases also showed several degrees and phases of adoption, with investments and risks increasing with progress.

One or more individuals recognized an idea or unmet use case from outside the formal OEP, and then conceptualized and communicated a suitable written description. Project bureaucrats deemed the ideas within scope and accepted the ideas via Bugzilla (recall from Chapter 3 that most ideas drop out early in the process). Potential users then expressed support and described potential uses and their own follow-on enhancements.

Until a participant wrote software code, the risks required of participants totaled a mod- icum of mental effort and minor social reputation for publicly supporting potentially unfavor- able ideas. (In these ﬁrst two cases, it was understood that ideas had been vetted in previous discussions and that only a summary of such discussions was communicated in the formal documentation.) No technical harm could come to the project or organization, although potential consequences were identiﬁed and communicated through disclaimers that study or functional- 92 ity was limited. Proceeding past this point required investment of substantial time and mental effort by shepherds and by project bureaucrats to implement and verify work.

In both cases, shepherds agreed with the potential benefits, invested resources, communicated prototypes and commentary, and sought specific and broad feedback as they proceeded with the idea. Reviewers accepted the ideas sufficiently to want to invest resources to test the prototypes and help developers with technical details and finishing. The OEEs then adopted the implementations into the product, implicitly accepting risks of increased code complexity, support, follow-up documentation work, and exposure to security issues, bugs, etc. Explicitly communicating acceptance of increased risk was not required. Finally the OEEs offered the enhancement to be adopted by the public. Despite risks, the secure SNI enhancement merited public adoption by a major third party (and other individual third parties, none of whom needed to declare adopting unfinished work) prior to official completion, while the new external log rotation ability did not risk forcing stable workarounds out of use. The timelines were roughly comparable at approximately one year of formal work once processes entered the OEEs. Both enhancements were parts of broader, staggered efforts. The number of shepherds and diversity of contributors prior to implementation may have been comparable. The number of champions during implementation differed. Logging improvements were completed primarily by one already trusted person and one reviewer, while SNI was completed by multiple individuals, leading up to work by one person who became trusted. It’s unclear if narrow distribution of work despite many capable contributors is typical. In the next case, ideas for enhancements were less well developed prior to formally entering the OEP.

4.6.3 Case 2: Firefox secure connection warning (Bug 327181)

Unlike Apache, Firefox’s norm is for all work and communication to be documented in Bugzilla.

This enhancement, related to SNI, sought to increase security for web users. It was both a technical and social issue, and the enhancement sought to change both social and technical 93 user behaviour. The enhancement was adopted with few legacy concerns.

Background: Web servers may be configured in a few standard ways to securely encrypt traffic between users’ web browsers and websites. Web servers may also be configured to allow users and website proprietors to mutually verify identities. Many non-standard configurations are intentionally, unintentionally, or maliciously used. All web browsers behave unobtrusively as expected when standards are followed, but may handle other cases differently. Typically, highly technical warnings about non-standard cases accompany a choice to proceed or not.

Users tend to ignore technical warnings and click the user interface to bypass warnings until they achieve their desired outcomes, knowingly or unknowingly exposing themselves to risks of data interception.

Basic idea: The web browser should inform users about different web server (mis-)conﬁgur- ations and require users to actively choose to use insecure connections by making the warnings more difﬁcult to bypass.

Synopsis: An instigator posed a position paper (initiated elsewhere) about this problem and possible approaches to building a solution, and then became inactive. The problem was broken apart by others, reassembled, and solutions were prototyped conceptually. A shepherd

(not the instigator) contributed an early mockup, but work paused. After several approaches were discussed, the shepherd summarized a consensus about the problem and set out to design a solution. Dozens of use cases and effects on third parties were considered, including user alienation and support issues if current capabilities were removed. Values, goals and objectives were clarified since European users valued connection security over identity verification, inverting the U.S. contributors’ priority. The consensus was to require users to consciously choose to use potentially insecure connections. After more discussion, the instigator revealed his motive—to stimulate discussion only—but became convinced by a particular approach. He did not contribute to the technical improvements. After seven revisions, the work was completed by the shepherd. The browser’s core rendering engine and an accessory security com- 94 ponent were modified. Upon release, a few users complained about being unable to knowingly access websites over insecure connections (e.g., Quotation 2.1). Such input was dismissed or moved into other OEPs. Despite the fact that the enhancement was complete, other use cases were discussed. Participants reminded each other that genuine security certificates are expensive (in money, knowledge, and time) for website operators to implement; and some users valued access over both security and identification. Shepherds perceived that users did not pay attention to their website choices, did not read, and did not consider security in their actions.

Discussion: Many use cases were considered, with frequent message exchanges comparable to Apache developers discussion list (multiple messages were sent daily during busy periods, weeks-long gaps were observed during lulls). Participants expressed few social pleasantries or thanks. Ambiguity, questions and answers, and technical approaches were debated prior to prototype implementation, unlike the Apache cases. In this enhancement, descriptive prototypes (user interface mockups) served a similar discussion purpose as early code prototypes in SNI. As with SNI, the entrepreneur did not originate the idea. Uniquely, the instigator’s objective was not even to cause speciﬁc enhancements.

Two phases of the OEP were distinguishable by communication and actions. Before implementation, subsidiary ideas were openly considered and infrequently diverted to follow- up bugs, while questions focused on deﬁning ideal behaviour. After implementation, most subsidiary ideas were diverted to follow-up bugs, questions focused on differences from old behaviour. Like Case 1, the shepherd’s active question/reply pattern to gather peer input at every phase built support the problem deﬁnition and solution. There were several instances of data collection from a variety of outside theoretical and applied sources, resulting technical compromise and agreement about the core problem and details.

This OEP and enhancement improved the safety of users, despite explicitly breaking users’ existing (unthoughtful) use of the product, along with other enhancements. (Participants cited protection against man-in-the-middle attacks, poor security certificate configuration, and other 95 one-off hacks.) Participants justified removing existing capabilities to access secure, but poorly identified websites by the wide availability of legitimate ways to securely configure websites.

Participants also considered new methods and pointed out new resources for users and website operators to build from this enhancement, implementing changes which mirrored the actual and potential enhancement considered in received and contemplated use cases.

Cases 1 and 2 illustrate the importance of use cases to OEPs, and of consulting about use cases before substantial implementation. This case contrasts strongly with Case 3—a high impact technical change affecting all users–in which few third-party use cases were considered before, during, or after implementation, and in which few ideas entered or left the OEP.

4.6.4 Case 3: Firefox “Home” button relocation (Bug 404109)

This case examines a seemingly trivial aesthetic change, by a respected contributor with support from project leaders, resulting in adoption, distribution to the public, and ﬁnally, rejection.

The case is unlike the others in some ways: It was submitted as a ﬁnished product without providing rationale or external reference about why it was implemented, and it carried a list of administrative actions as long as the substantial discussion about the change itself.

Background: Clicking the “Home” button on a browser takes the user to the designated home page. On almost all graphical web browsers, the “Home” button is conceived and used like a bookmarked item in that way, but also as a standard navigation element.

Basic idea (as presented to stakeholders): Move the “Home” button from between the navigation buttons and address bar to left of the bookmarks bar below.

Synopsis: In the months prior to its appearance in Bugzilla on November 16, 2007 this enhancement was not discussed in any sanctioned discussion forums (mozilla.dev.applications.

firefox, mozilla.dev.planning, mozilla.dev.platform, mozilla.dev.quality, mozilla.dev.themes, mozilla.dev.usability, mozilla.feedback.firefox, mozilla.feedback.firefox.prerelease, mozilla.general, mozilla.support.firefox, mozilla.wishlist), nor does the enhancement itself re- 96 fer to any other enhancement which inspired it. In isolation, Bugzilla’s records would conclude the change was an attempt to change the way users do things without providing any benefits.

Since Mozilla encouraged web developers to test intermediate versions of its products prior to their ofﬁcial public release (Mozilla Foundation, 2008), many users tried, and complained about the change. The Beta 3 release of the unﬁnished product version was provided to the public on February 12, 2008. The release notes for Beta 3 did not mention that the “Home” button has moved (Mozilla Foundation, 2008). That release generated hundreds of discussions among early adopters about the new location of the home button (e.g., Google search results at

Google, 2009) as well as in the Firefox Bugzilla (e.g., Brown, 2008).

Feedback to the official discussion forum was significant. Of the 225 messages in 2008 to mozilla.feedback.firefox.prerelease about the “Home” button, 195 were posted between Febru- ary 12 and May 16, 2008. In contrast, 25 messages were posted in 2009 about the “Home” button. Most subject lines were variations of “(no) home button” and message bodies generally supported returning the “Home” button to its prior location. One tester noted that the change “reverted [the browser] to the Mozilla format: Home button on the Bookmarks Tool- bar” (“H”, 2008-01-30 21:09), a design choice used by Firefox’s predecessor in 2004. After a month of complaints, project leaders began work to revert the relocation (Sharp, 2008) which was completed in five days. The original idea was marked “WONTFIX” in Bugzilla on May

17, 2008, one day after the Release Candidate 1 version was published.

In his personal blog (which does not accept user or reader input) Mozilla’s Director of

Firefox, “Mike Beltzner”, publicly explained and defended the change to the “Home” button, as a part of a larger design. He pointed out the signiﬁcance of this change to a more important, larger and disruptive shift in the project (see Quotation 3.1 in Appendix B).

Discussion: So, why was this change—which was not quite an enhancement—so troubled?

An obvious avenue to explore begins with how this idea came to ofﬁcially exist, and how its rationale was not communicated. 97

Unlike every other case considered, this idea did not begin public life as an enhancement to solve a problem, but still moved quickly through the formal process. It just came to exist as an almost ﬁnished solution without discussion about its goals for users or the project. Even though the ofﬁcial project leader and some active participants knew why the change was required (as suggested by the Director of Firefox), the submission of the changes on November 16, 2007 to Bugzilla surprised “Alex Faaborg”, Firefox’s “User Experience Specialist” (and eventual

“Principal Designer”) responsible for administratively ﬁling the bug. Only a day after the change was ofﬁcially approved and adopted did an outside individual contribute by asking the core developers to consider his use case, and a common one he observed (“Ed Hume”, 2008).

Early in and throughout the process, participants discussed possible technical effects on third-party modules designed to alter Firefox’s user interface. But they did not engage authors of third-party modules, nor did they communicate how the change would affect end users.

Uniquely among the cases considered, no one who completed the technical work responded to any comments or inquiries made by end users about the change. The technical contributors made no further communications at all in Bugzilla after their changes were adopted on January

30, 2008. The “superreviewer” reviewing the changes noted in his approval that “we need to be very explicit publicly about what we’re doing here, both for users and for themers” who produce modules to alter the browsers’ appearance (“Mike Connor”, 2008). However, a themer who explicitly objected that the change would break his and others’ themes received no response from the technical contributors, the Director of Firefox, or the superreviewer.

The timeline for this enhancement reversed the general case in which problems precede inventions, user input, technical work, formal approvals, and ﬁnally adoption.

Communication content and its timing during the OEP seem signiﬁcant. Prior to completing implementation, most communications consisted of references to internal technical information, and attachments of changed computer code ﬁles, by developers for other developers.

After adoption, most of the communications were by end users for developers, who never re- 98 sponded (recall Figure 4.1). No substantial explanation for reverting was given in Bugzilla:

“Beltzner thinks it would be best to revert the changes we made to move the home button to the personal toolbar by default.” (Sharp, 2008), nor by Beltzner in his blog. According to custom, such a bug report should be unacceptable because its purpose was unclear, and no observer could access Beltzner’s thoughts. It was approved nonetheless.

Without Beltzner’s personal blog post about moving the “Home” button for larger design reasons, there would be no readily available documentation about its purpose. If contributors used only mandated communication tools, they would not know the purpose of the change, nor its reversal. (Neither the blog post, nor the rationale it offered, were cited in the formal channels even in the face of questions about justification, indicating that few participants did know about its true purpose.) A related challenge exists for the present research, which uses the same data resources as would a novice contributor to the OEEs studied: important history about particular enhancements may not be captured in the official documentation. Misleading conclusions so drawn would be difficult to detect without direct, tacit knowledge of the working environments. (Alternatively, the OEEs function despite such impediments.) Unexpectedly, no stakeholder objected to the circumvention of established open processes ensuring fair evaluation of contributions based on technical merits, nor to the complete exclusion of community concerns about adverse consequences. However, relocating the “Home” button may not have succeeded even if the real objective, to support UI design innovation, had been communicated.

The user community possibly originated this idea, but in an unusual manner. Months prior to relocation, users on the discussion lists asked repeatedly about having not a single home page which would open when the browser started, but a “home group” of several different tabbed pages. At the time, the only way for a user to open a group of different pages in tabs in one action was to open a folder of bookmarks, or (unknown and undocumented to many users who kept requesting the feature in Bugzilla3) to conﬁgure the home page to be several

3Mozilla Bugzilla search results at: https://bugzilla.mozilla.org/buglist.cgi?query format=advanced;short desc 99 tabbed pages. In discussions, users mentioned that the “Home” button was conceptually like a bookmark storing the address of the home page, so the “Home” button could ﬁt amongst their number in the bookmark toolbar. Speculatively, since there is no public documentation to this effect, the idea may have appealed to a technical contributor already working conceptually similar functionality.

In any case, the users’ ﬁnal input, to keep things as they were, was heeded but only after negative user experiences and poor public publicity for the entire project. Thus, this case illustrates that poor communication of use cases with external stakeholders and circumscribing the established OEPs may result in non-success of an internally sourced enhancement. The next case illustrates a similar circumstance in which a highly desired enhancement, based on an external idea, can be rejected due to poor communication within an OEE.

4.6.5 Case 4: Threaded Firefox windows (Bug 40848)

This case describes an idea which required ten years not to implement, despite strong external support and validation. Unlike Case 2, in which conceptual designs were able to be freely discussed, some participants in the present case actively suppressed discussion. The idea of threaded windows originated before the Mozilla Foundation’s current legal incarnation, and was formally suggested in at least nine other instances.

Background: Modern desktop computer applications allow the user to interact with several documents at once. There are two primary implementation approaches. In one, each open document of an application uses its own distinct copy of required resources. This approach prevents one misbehaved open document from monopolizing shared resources required other open documents, but consumes more total resources. Alternatively, every open document shares resources required in common and only duplicates the resources not required in common. This minimizes total resource usage, but risks allowing each single open document to monopolize

=multiple%20home%20pages;short desc type=allwordssubstr;product=Firefox 100 resources required by its peers. Firefox uses this second approach.

Basic idea: Within the Firefox web browser, isolate different browser windows from each other to prevent any misbehaving browser windows from adversely affecting other browser windows open at the same time. This idea originated as a suggestion to implement a specific technical measure to gain unspecified “substantial improvement in the quality of the UI [user interface]”. As such, the idea sought change at greater specificity—but with less consideration of specific problems to be solved, or specific use cases—than the basic enhancements considered in other case studies so far. Participants indicated that since threaded document windows enhance the product’s performance, it was advantageous to implement in light of all of its competitors having done the same (Quotation 4.1).

The idea was not new, but copied from elsewhere. It experienced a variety of states in the formal OEP. It was ﬁrst adopted as plausibly beneﬁcial a mere three days after it was formally suggested in 2000 (moving from the “UNCONFIRMED” to the “ASSIGNED” status in

Bugzilla). It was then assigned to different shepherds for two different periods. After sparse discussions, in 2005, bureaucrat “Brendan Eich”, took control of the enhancement as his ﬁrst formal contribution to it. He offered to “Tak[e] this bug, so that it can get some technical attention”, offering to move it along the OEP. At the same time, “Brendan Eich” also admonished that progress would not be likely (Quotation 4.2). His threats to privatize the enhancement and limit discussion about problems he did not perceive were not particularly open actions.

Two other contributors objected that users did care about product performance, but perused the matter no further.

“Brendan Eich” subsequently objected to every argument in favor of implementing threaded document windows, or other related technical means to enhance performance. “Brendan Eich” cited prospective adverse use cases which he did not detail, abstract “experience, real data, sound theory, and least-cost-to-ﬁx judgments” (2007-06-12 11:04), and the lack of syntactical clarity in suggestions by less technical contributors. “Brendan Eich” communicated all this 101 without providing suggestions about how to move forward with resolving the manifest performance issues users had complained about.

“Brendan Eich” appeared simply hostile to threaded document windows and used bureaucratic and technical force to quash the idea. But before formally rejecting the idea, “Brendan

Eich” seemed to have retained it for two years so as to keep control of it. In response to a follow-up comment by the originator of the idea (seven years hence) suggesting better use of the better computer hardware which became available, another bureaucrat, “Benjamin Smed- berg”, had closed the enhancement request (the “bug”), effectively rejecting the idea. “[“Ben- jamin Smedberg”] kindly don’t close my bugs for me. I was keeping this ’attractive nuisance’ around for a reason”, complained “Brendan Eich”. “Brendan Eich” then reopened the bug, created a “new non-nuisance meta-bug summarizing the separable issues... and then [assigned the] WONTFIX [status to] this bug”. “Brendan Eich” left the new bug in the less substantial

“NEW” status (above only the “UNCONFIRMED” status accorded by default to all public input). By that time (2007), six other suggestions of the same idea had been marked as duplicates of the original enhancement, which “Brendan Eich” controlled. “Brendan Eich” stopped contributing to that original enhancement request, and focused on the new bug he created. By this point, less than half of the total discussion about this idea has occurred, and the discussion did not vacate from this bug until late April 2009. Opening the new bug (Bug 384115), “Brendan

Eich” explained:

“I’m making this meta-bug mainly so everyone who thinks threads cure cancer

can come here and see the exactly [sic] problems and solutions involving paral-

lelism, and not confuse means for ends or otherwise vent their enthusiasm for

threads. Hope it works better than the last time.” (Bug 384115, 2007-06-11 23:03).

After short exchanges among participants about possible technical solutions to address the technical issues about parallelism as requested, “Brendan Eich” complained: 102

“Bugzilla has had important bugs overrun with vague but strongly felt feelings,

stubborn confusions, and continual digressions in the past. Don’t id such noise in

this bug, or I’ll WONTFIX it and do work in a private bugsystem.” (2007-06-12

15:11).

Again, moving public work from an OEE into a “private bugsystem” would contradict any reasonable interpretation of openness. A user noticed the severe irregularity of “Brendan

Eich”’s threats:

“[“Brendan Eich”], I don’t mean to instigate you into unleashing your WONT-

FIX WMD [weapon of mass destruction]... but it appears as though you opened

this bug to more accurtely [sic] reﬂect the cause of the symptoms being reported

in that other bug, then closed that other bug saying this one was taking the place of

it, and are now annoyed that people are trying to ﬁnd a place to continue the dis-

cussion of the original ‘unresponsive UI’ symptoms — here, there, or wherever”

(“M”, 2007-06-13 07:26).

To which “Brendan Eich” responded, contradicting his earlier statements and actions: “This bug is not the successor to 40848... This bug is about exploiting hardware parallelism” (2007-

06-13 10:16). “Brendan Eich” administratively changed the name of the bug from “Mozilla 2 multi-thread and/or multi-process meta-bug” to “Mozilla 2 ’exploiting hardware parallelism’ bug” on 2007-06-13 at 10:48. One year later, after Google released its Chrome web browser, which implemented threaded document windows as originally suggested (and reportedly performed faster than Firefox [e.g., Kingsley-Hughes, 2008; Booth, 2008]), a user had noted the same information in the bug. “Brendan Eich” responded: “law: we’re looking at multi- process now... Your comment [about Chrome’s threading] belongs in the newsgroup, not this bug.” (“Brendan Eich”, 2008-09-08 13:38). Previously, “Brendan Eich” had stated (2007-06-

12 08:55): 103

“What really does not make sense is prescribing ‘threads’ as a solution for

undeﬁned or ill-deﬁned problems, especially if there are existence proofs of re-

sponsive browsers that do not use threads.”

Ignoring the counter existence proof provided, “Brendan Eich” contributed nothing further to this enhancement. It was not proceeding successfully through the OEP.

On May 5, 2009 “Benjamin Smedberg”, who had originally tried to administratively reject the threaded document windows enhancement, took control of a new project at Mozilla to implement threaded document windows in Firefox (Smedberg, 2009). “Brendan Eich” was not on that team. No mention was made of this new project in existing entries for this idea in Bugzilla, despite the project being reported in the public media (e.g., Dunn, 2009). According to Bug

478976, the project had its roots in a related effort to enable browser plugins (programs within documents) to run in different threads than the documents themselves (“Out-of-process plug- ins”). The Inter-*-communication Protocol Deﬁnition Language, “where ’*’ includes ’process’ and ’thread’” (Mozilla Foundation, 2010) and OOPP implementations underway are strongly supported by both Firefox’s OEE and stakeholders, as evidenced by completion of work on more than half of the approximately 180 bugs (ideas and technical changes) required elsewhere in Firefox to enable threaded document windows in Bug 478976 (Stenback, 2009). Of only six comments recorded in Bug 478976 itself, only the ﬁrst two concerned the overall effort.

Discussion: This enhancement process did not follow successful OEP or communication patterns encountered in previous cases. However, it did spin out at least one apparently successful enhancement process. It also revealed that volunteer bureaucrats and shepherds with authority may actively obstruct at least some OEPs without much fear of reprisal. It is also clear such individuals may also steer OEPs into venues that may be difﬁcult to access by the public.

(For example, understanding the 180 dependent bugs would require substantial effort, with or without adequate documentation.) Superﬁcially, it appears that this case also falls outside the exploratory model in the mechanistic sense. However, this case shows that without implemen- 104 tation activity, communication is sufﬁcient to drive implementation activity to informal venues and processes, for the purposes of suppressing and enabling successful enhancement outcomes.

Implementing threaded document windows may be a response to external competition from

Google’s Chrome browser, which design goal for a lean browser overlapped with Firefox’s original objective to be a lean version of the Mozilla browser. Despite communicated user demand, Firefox bureaucrats resisted adding threaded document windows in part due to the significant internal architecture changes required, but perhaps also because improving performance admits that the product had performance deﬁciencies. Stakeholders routinely highlighted use cases in which some variation of threaded document windows would help to alleviate manifest performance issues. However, such discussions were diverted into other discussions about performance around particular modules as opposed to performance with respect to how the core product was designed to interact with the modules.

These last two cases showed top-down enhancements and top-down resistance to enhancements which were not adopted due to insufﬁcient communication. Conversely, these cases are also examples of users indirectly working to change a product by working outside a formal OEP. Ideas may be connected to enhancement outputs via a pathway outside the model assumed by the participants of the OEEs studied. Without conducting a deliberate separate study of formal OEP circumvention, all that should be concluded from this observation is that

OEPs in the other two OEEs may also likewise be circumvented. Finally, unlike Case 1, which in which the shepherd encountered bureaucratic issues, Cases 2 and 3 had very permissive processes which provided opposite outcomes. Infrastructure seems again a weak inﬂuence on enhancement processes or outcomes.

4.6.6 Case 5: ARIN Minimum Allocation in the Caribbean Region (2008-4)

Note: ARIN Advisory Council and Board meeting minutes are available to the public on-line, but are not considered directly since they focus on bureaucratic matters, rather than on the 105 substance of policy proposals developed on the ARIN Public Policy Mailing List.

This case illustrates a simple change brought through the ARIN Policy Development Pro- cess. It resembles the two software enhancement cases, following a nearly ideal process. It departs by paying some attention to the clarity of stakeholder and potential adopter groups.

Case studies from ARIN PDP will quote more generously from communication items since the substance of the ideas proposed are relatively non-technical.

Background: ARIN’s policy is to allocate Internet Protocol addresses in contiguous blocks of 4,096 addresses (a “/20”) or larger multiples for use by Internet service providers (broadly deﬁned) to provide services to end users (individuals in domestic or corporate settings, Internet hosting providers, mobile phone users, etc.). An ISP may ask for additional allocations of addresses only when efﬁcient utilization of existing allocations is demonstrated or reasonably foreseen in the near future (ARIN, 2009). Globally, it is desirable to maximize the number of addresses in each allocation in order to minimize the total number of allocations. Major

Internet network operators’ routers (having finite capacity to store and retrieve records) must track each allocation to reach each allocation holder on the network. It is also desirable to maximize efficient usage of allocated IP addresses since address allocations are a finite resource with limited options to be further sub-divided and redistributed (as doing so would effectively create additional sub-allocations which would must be tracked).

Basic idea:

“The minimum... allocation size for ISPs from the Caribbean portion of the

ARIN region [shall be] /22 [1,024 addresses]... ARIN staff have noted that organi-

zations in the Caribbean region have problems meeting the current criteria due to

the fact that the population in the region is smaller than that of Canada and the US.

There is also a lack of competition with many countries in the region faced with a

monopoly or duopoly situation in terms of transport providers. To spur develop-

ment in the region a similar proposal was passed in this region for the portion of 106

the African region that ARIN administered prior to the formation of AfriNIC. This

proposal seeks a similar outcome.” (Aronson and Andersen, 2008.)

Synopsis: Virtually every participant expressed support in principle, but many disagreed over a particular ambiguity. Of over 60 messages on ARIN-PPML about this proposal, a majority concerned how “Caribbean” was defined using geographic, geologic, political, or other criteria. Participants gathered and shared information about where and how islands were organized and affiliated, as well as demographics, to argue definitions and wordings. The policy scope was questioned since other non-continental territories serviced by ARIN engaged different use cases. The proposal text specified a use case to be enabled, and also why, but not exactly who was to be included or affected by the policy.

The general process and outcome of good policy-making was a discussion point, analogous to discussing good code authorship in the software projects. Late in the discussion, it was pointed out that the proposal as worded suggested that it came from the ARIN staff and not the stakeholders affected (e.g., Leibrand, 2008). The discussion raised analytical questions about the importance of the source of ideas, and points out for the current analysis the difference in trust of bureaucracies among ARIN, and Apache and Firefox. A proposal co-author reassured that the proposal came through staff from Caribbean stakeholders (Quote 5.1). Another participant responded that the proposal arose from a discussion with stakeholders via the Secretary

General of the Caribbean Telecommunications Union (Darte, 2008). Of methodological note, a different response to the question of idea source validated that the present analysis uses the correct kinds of source material, and the importance of context, as the respondent had referred to public meeting records of a meeting he attended to inform his present deliberation (Quote 5.2).

For a proposal initiated in May, it should be curious that a question of operational authority to originate the proposal arose in October, and that the originator of the proposal recorded her only participation in the discussion until that point (Aronson and Andersen, cited above) in response. In the other cases studied, the sources of ideas were rarely questioned. Stakeholders 107 voted in favour of the idea at the ARIN Caribbean Sector Meeting (September 17, 2008), concurring with the PPML participants, and was ofﬁcially approved by the AC (November 20) and the Board (December 3) and implemented on December 17.

Discussion: This example of an enhancement in the ARIN environment sets a baseline against which to examine the the more substantial changes proposed in the following case.

Only eight of the messages in the entire discussion about this proposal (four arising from

ARIN’s PDP) transpired between the announcement of the proposal, and the discussion beginning October 6, as a result of reporting about the favorable (11–2) reception at ARIN’s

September ARIN Caribbean Sector Meeting (ARIN Member Services, 2008a).

Participants requested ARIN staff provide information about resource impact of the policy proposal, and of the current situation, beyond the standard information contained in the

Staff Assessment required of each policy proposal. This was analogous to contributors working with established experts in the software OEEs, excepting that ARIN staff were procedurally excluded from participating in policy discussions directly (they responded via the assigned shepherd, the Advisory Committee or the Board). During the PDP, staff fixed the proposal’s wording to match their definition of the “Caribbean service region” and other mandated At- lantic territories, and ARIN website’s definitions of the same. Notably, little involvement or input was recorded from Caribbean stakeholders. Their role resembled users who submit ideas to Bugzilla without following through. This was not surprising since the ARIN-PPML discussions in general do not receive much input from Caribbean participants. However, participants noted the importance of Caribbean participants’ involvement in offline encounters. This again highlights participants’ enhancement activities outside the formal OEPs recorded in discussion archives. This case compares favourably to the Apache HTTP Server log rotation enhancement, in which diverse stakeholder use cases and potential enhancements are enabled without their direct communication via invention.

Recordings and transcripts of formal ARIN meetings are publicly available on ARIN’s 108 website, but are not pushed directly to subscribers unlike discussion messages. Such transcripts are brieﬂy considered in the next case. Mozilla also makes available transcripts of their staff developer meetings, but no citations of that form of record were observed in the shepherd and stakeholder discussions in cases studied. The lack of citation may indicate participants’ lack of awareness of the other records, or or that such records are otherwise unimportant to their work in the OEPs.

4.6.7 Case 6: ARIN WHOIS integrity policy proposal (2008-7)

The proposal presented in this case was the first in a series of four related proposals which eventually become adopted as a single policy. Although this first proposal was not adopted on its own, it represented the first clear articulation of an idea to solve a long-standing issue, while stimulating conceptual work. It illustrates the requirement to communicate the balance of costs and benefits to various stakeholders in various use cases.

Background: Internet resource authorities assign IP addresses to individuals and corporations for use on the public Internet. ARIN’s legal Registry Services Agreement requires assignees of IP addresses to provide ARIN with accurate contact information to obtain and retain their allocations. Such contact information is stored in ARIN’s WHOIS database and must be vetted by ARIN to verify identities and authorization of individuals to act on behalf the assignees they represent. Under policies pre-dating ARIN, IP addresses were assigned to individuals and corporations (“legacy resource holders”) with less stringent or no contractual requirements to provide and maintain accurate contact information. Some such entities are reluctant to enter into any legally binding agreement with ARIN, such as the RSA or Legacy

RSA. Many recorded assignee individuals, roles and corporations have disestablished. Many allocations have operationally changed hands without ARIN’s knowledge. de facto IP address holders and users may have difﬁculty demonstrating the provenance of their authorization to update the technical characteristics of their allocations’ WHOIS records. ARIN cannot contact 109 assignees with inaccurate contact information to request updated contact information. Further,

Internet resource authorities and IP address assignees require valid contact information to coordinate technical operations. ARIN’s database of contact information contained both accurate and inaccurate contact information, collected under different circumstances.

Basic idea:

“Policy statement: To ensure the integrity of information in the ARIN WHOIS

Database a resource must be under an RSA (either legacy or traditional) in order

to update the WHOIS record. ARIN will not update historical information in the

ARIN WHOIS Database until the resource holder can prove the organization’s

right to the resource.” (Schiller, 2008)

Recall that ARIN’s PDP and environment differ from those at Apache and Mozilla. Primar- ily, ARIN speciﬁes a formal process in which contributors suggest, debate and decide ideas in the abstract to generate policy, which is then interpreted by a bureaucracy through implementation. Unlike the software OEEs in which contributors may pose ideas, create code, and propose implementations at any time during the process, ARIN PDP formally speciﬁes phases of al- lowable and required discussion and implementation activities. Compared to the two software

OEPs, ARIN PDP less clearly segregates conceptual discussions among humans and algorith- mic code to be executed mechanically. It is therefore expected that prospective operational details and use cases will co-mingle with conceptual discussions earlier in ARIN PDP than in Apache or Mozilla OEPs since the opportunity to discuss use cases at implementation is denied in ARIN PDP. The current research focuses on communication in OEPs, not administrative procedure mechanics. Contrasting the Apache and Mozilla enhancements, this case holds internal bureaucratic process consistent. ARIN policy proposals also included a manda- tory explicit suggested implementation timeframe, compared to optionally targeting particular upcoming release versions or milestones in the software OEEs. 110

At the outset, the proposed enhancement deliberately sought to eliminate some use cases developed by third parties, in order to generate a collective beneﬁt for the user community. It also did not consider the needs of affected third parties. The pattern from Cases 0–5 suggest that this idea would face difﬁculty for the reason that it would curtail, rather than expand, the possibilities for third-party innovation.

Synopsis: Two months prior to the policy proposal being ﬁled, Owen DeLong asked ARIN-

PPML subscribers about access to historic WHOIS data to help resolve an on-going dispute about rights to an old IP address allocation (DeLong, 2008a). DeLong explicitly asked as an individual, not as an ARIN Advisory Council member. The idea to provide access to historic

WHOIS data was adopted outside of policy on July 11, 2008 (DeLong, 2008b) as part of the ARIN Consultation and Suggestion Process. The ACSP operates like a suggestion box and support forum for existing ARIN services. It receives approximately 25 legitimate inquiries per year. On August 15, 2008, Heather Schiller submitted the “WHOIS Integrity Policy Proposal”, making indirect reference to DeLong’s issue (Quotation 6.1).

The main WHOIS integrity proposal and its descendants generated 198 messages in the following month, pausing for a semi-annual ARIN meeting in which members discussed and voted on pending policy proposals. Participants indicated this proposal’s signiﬁcance by the number of communications pieces generated. The ARIN-PPML archives record fewer than

300 messages about WHOIS from fall 1999 to June 2008. From June 2008 to May 2009 there were approximately 300 messages about WHOIS—220 responding to the proposal and its descendants, all within one week. (A brief earlier discussion in 2008 of over 60 message about WHOIS concerned the detail in data available in a different WHOIS database concerning allocations from IP resource holders to their customers.) The majority of other messages during that period were related to Legacy RSA agreements, inspired by and later integral to the

WHOIS policy proposal. A minority of the other messages concerned the results of a survey about IP (version 4) transfer policies arising from anticipated IP address depletion. Changes to 111

IP transfer policies would require an accurate WHOIS database showing providence of legacy resources. A brief and small discussion ensued about policies and implementation of IP (version 6) as a solution to IP (version 4) address depletion from the current pool. In short, the

WHOIS policy proposal and its consequences monopolised discussion, drawing an overall average of one message per active participant for the year. This comprehensive scale of participation was not observed in any other case.

The main objections to the original proposal (and not the three subsequent proposals which did not enter the formal process in time for the September meeting) were as follows. First, participants were unclear about envisaged technical and operational mechanisms. A participant asked (Quotation 6.2), and received direct feedback from proposer about the policy proposal’s dual purpose: accuracy of information and authorization to update that information (Milton

Mueller, 8/19/08 3:49 PM). However, the proposal was not substantially amended. Second, participants perceived poor communication about the policy’s several motives which could adversely (but ambiguously) affect existing use cases for stakeholders. And the several motives were viewed as conﬂicting.

“By requiring an RSA, this policy in fact does not implement the rationale,

but actively subverts it. *MY* WHOIS information is currently up-to-date... but

under this policy, I could not update it in the future if my company ofﬁces move...”

(Santos, 2008).

Third, participants expressed a lack of solid information about the scope of impact to

ARIN’s operations and services, and the number of allocations and members affected (Quo- tation 6.3). That open information could be required by the organization to operate closed processes seemed acceptable because security objectives were not required to be completely met in the open.

Participants considered the little information which was available, as well as the extent 112 of restricting potential use cases which were only recently accommodated (Quotation 6.4).

One participant assessed the discussion, and offered alternative suggestions. He separated the issues: Should legacy holders pay for services like WHOIS via an “LRSA-lite”? Whether

LRSA-lite could help address the integrity issue via stronger authentication tools? And could legacy holders pay for ARIN services without addressing jurisdiction over legacy resources

(Sinatra, 2008b). Some contended that the “proposal is an attempt to prevent the hijacking of legacy space... [not] an effort to make life difﬁcult for legacy holders” (Oberman, 2008). “This is not an attempt at a shake-down for $100/year legacy RSA fee” (Seastrom, 2008). Others pointed out that the policy would cause unauthorized attempts to update data to leave evidence of fraud (Quotation 6.5).

Alternative ideas also arose. One sought “a provision to revoke delegations based on intentionally false (and refusal to correct) WHOIS data” (Loch, 2008). Another objected to using policy to force legal contracts on non-members (Quotation 6.6). One participant suggested a live public list of allocations (and their network owners) with outdated information, in order to compel compliance via social pressure and media attention (Michael Dillon, 8/21/08 4:40 AM)

(Quotation 6.7). In a short time, the discussion generated three other policy proposals which eventually become merged with the original (to be considered in the next case study). Inter- estingly, the participants did not deliberately attempt to seek input from holders of outdated resources, even though they would be reachable by virtue of being attached to the logical and social network.

Methodological note: Unlike the other cases considered, ARIN’s verbatim in person meeting minutes are available publicly on-line. The minutes potentially offer a substantiating view into the ARIN PDP. At the Public Policy Meeting portion of the September 2008 ARIN meeting

(ARIN Member Services, 2008), ARIN Advisory Council Chair Leo Bicknell lead a discussion about the proposal. ARIN Counsel Stephen M. Ryan—in charge of legal review for policies, and for bringing legacy resource holders into the fold through legal agreements—was in a great 113 position to judge whether a policy could be implemented, but he did not actively participate.

Table 4.2: Author’s summary of discussion regarding policy proposal 2008-7 at September 2008 ARIN meeting.

Action Participant Rationale Support Hannigan Anticipate future IPv4 transfer policy which will require accurate information. Support Hughes Recoup costs of providing service Oppose Seastrom (AC), Does not increase accuracy; prevents non-RSA Roberts, resource holders from updating WHOIS without Manning (Trustee), legal agreement (compels agreement) Cassimire Question Wallace Confusion about 60 day implementation period; fear ARIN could reclaim assigned addresses on slow e-mail response. Proposal Roberts, Need IPv4 transfer policy ﬁrst, to incentivize Hannigan, legacy resource holders to update information Seastrom so that they could participate/monetize. Proposal Roberts Membership level without RSA. Noted various This policy is joined to the other three which could not be presented at this meeting. WHOIS must become more reliable for there to be a market for IPv4 addresses.

Table 4.2 outlines the discussion at the September 2008 ARIN meeting regarding 2008-7.

A show of hands recorded 19 of 19 participants were “in favor of something like this”, while only ﬁve of 19 (21 per cent) were “in favor of this speciﬁc proposal”. This result is not out of line with the sentiment expressed in the mailing list discussion in which four participants were in favor, and ten were opposed (29 per cent). However, the oppositions in e-mail did not indicate even support in principle. The meeting participants were invited to suggest possible amendments to the policy, but none did so. The meeting also discussed, informally, the issues raised by the three spun out proposals. In October, the policy was revised to include the substance of the three other proposals arising from the discussion, and discussion about the amended proposal restarted in the weeks after the meeting.

Discussion: The live meeting did not record substantially expanded discussion about points 114 raised in the mailing list, and involved very similar participant views. In this case, no substance would have been lost by not considering the meeting transcript. The transcript was signiﬁcantly shorter and did not yield as much depth or breadth of consideration as had occurred on the mailing list, nor the opportunity to seek and provide research information about the decision.

The only new behaviors observed from the meeting transcripts were the strong support and strong opposition to the policy proposal as stated. Supporting an amended policy proposal was not possible at the meeting, but alternatives were informally suggested.

Chapter 3 found that higher rates of participation from the total constituency related to higher rates of invention per participant. Does that necessarily apply here? In this case, the high participation rate did not associate with this idea’s success as an enhancement as worded in the proposed policy (despite strong support for the idea of enhancing the accuracy of the database). In addition, the overlap between ARIN-PPML and live participants suggests a potentially higher exclusivity or barrier to entry into ARIN PDP, as opposed to the technical and knowledge barriers in the software OEEs (ARIN’s smaller, but perhaps more focused, bureaucrat pool handles implementation unlike the software OEEs). From the case studies in which participation adversely affected adoption, it is possible to generalize that participation through provision of input on its own does not advance an enhancement since such contributions may be ignored, regardless of the formal infrastructure or processes implemented to ensure that stakeholder input is considered and valued. This should not be an outstanding proposition since effective and useful communication in whatever form requires generating common understandings of new information.

As in the case of moving the “Home” button in Firefox, participation brought attention to existing and desirable use cases which would be disadvantaged by adopting the idea, as well as drew attention to deﬁciencies in consultation leading up to the policy proposal. However, the idea contained in the policy proposal did receive strong approval as part of a larger set of related proposals (to be discussed in the next case). 115

4.6.8 Case 7: ARIN Identify invalid WHOIS POCs (2008-7, second round)

On the day after ARIN published the original proposal to require RSAs to be signed prior to

WHOIS updates, other related ideas surfaced.

Background: In addition to allowing Internet operators and ARIN to coordinate immediate technical operations, accurate contact information is required by ARIN to authenticate holders of IP number resources who request operational or administrative changes to their corresponding WHOIS entries. Contemplated attempts to discover and recover abandoned IP number resources also requires the contact information in the WHOIS database to be accurate and authentic.

Basic ideas: Three overlapping ideas were proposed arising from 2008-7.

1) “A holder of resources not governed by any type of RSA... may work with

ARIN staff to... authenticate each resource claimed by the holder [who] will be

entitled to make updates to WHOIS information... ARIN will supply a report

to the community, updated monthly, that lists the percentage of “REFUSED RE-

SPONSE” POCs, the percentage of POCs that accept e-mails, and the percentage

of POC addresses that have not responded but have not yet been notiﬁed by paper

mail or telephone.” (Sinatra, 2008a).

2) “ARIN will use an automated system that once a year will attempt to e-mail

all separate e-mail addresses in the directory... These records should be avail-

able to the public on request... [Current policy] carries an assumption that POCs

belonging to defunct companies will be removed when the bills for allocated IP ad-

dressing cease being paid, and the address resources are then returned to the ARIN

pool as a result... A netblock with no valid POC presents a target to hijackers.”

(Mittelstaedt, 2008). 116

3) “ARIN will conduct POC validation annually... As a defense against such

hijacking attempts, this policy proposes that the information be presented in full to

the entire community.” (Grundermann, 2008c).

Synopsis:

Discussion of the original policy proposal raised separate issues of authentication and potential for further innovation, e.g., (Sinatra, 2008c): “A lot of us on PPML don’t have the ability to sign the LRSA, regardless of whether or not we want to do so.” Sinatra formally introduced the ﬁrst follow-up idea: to establish a mechanism outside of formal contractual agreements to authenticate legacy resource holders, numbered 1 above (Sinatra, 2008d). In so doing, he acknowledged the relatedness and providence of the ideas considered. He respected other individuals involved in the process, and reinforced the importance of ARIN-PPML as a venue to discuss new ideas in policy.

The second follow-up (proposed at Mittelstaedt, 2008) numbered 2 above, broadened the discussion to acknowledge that as the entire Internet community approaches exhaustion of the current pool of IP addresses, identifying and recovering abandoned IP addresses becomes important to expansion and preventing criminal misappropriation. His proposal acknowledged a missing use case and a prospective use case, trusted ARIN to handle collected information and only report in aggregate, but also emphasized the role of the Internet operator community in deciding how to address pressing concerns.

The third idea, numbered 3 above, in direct response to the second, focused on validation and mitigating consequences of identifying abandoned resources. It required that the point of contact respond annually to an ARIN e-mail to verify its accuracy, and that ARIN publish lists of allocations with invalid contact information to defend against hijacking. (Gundermann,

2008a). His purpose was to “bring the netblock to the attention of whomever is responsible for it and/or allow other network operators to understand the potential risk and take appropriate action to mitigate...” (Gundermann, 2008b). 117

All of these discussions occurred prior to the September policy meeting. Since policy proposals must be registered 30 days prior to such a meeting, consideration of these proposals was delayed. During the continued discussion in 2009, old 2008 issues were rehashed. Before the next policy meeting, participants had the opportunity to iterate and amend the proposal considering use cases. Participants became aware of real world labour costs to be incurred as a result of requiring increased data handling per the policy, and considered broader implications.

In addition, since the original proposal was inspired by another regional Internet registrar, comparisons with practices at analogous organizations were communicated into the discussion.

The policy proposal was amended and discussed at a subsequent meeting in April 2009, and was adopted by ARIN Board of Trustees on July 1, 2009. However, implementation has not yet been reported. In the July 2009 ARIN Board meeting, it was reported that implementation would take 10 to 12 months.

Discussion:

Pair-wise exchanges occurred, but did not dominate any phase of the discussion, despite the fact that an AC shepherd was assigned to guide the proposal. Nor, unlike Apache and Fire- fox OEPs, did any particular pair dominate at any time. Unlike software code enhancements, concurrency of effort in writing policy drafts did not require coordination around a particular working copy; and internal and external technical information, rationales and justiﬁcations could be imported into the ARIN-PPML discussion without committing to their exact stated forms. The ability of stakeholders and potential adopters to informally consider and amend an enhancement as it progressed seemed critically important. The original proposal saw objections and discussions about non-handled use cases, but alternative ideas, amendments were not viable due to the short timeframe before the meeting in which the idea was to be discussed. The merged and shortened proposal provided time for three formal revisions after the September meeting according to its ARIN status page (ARIN, 2008b), although the ARIN-PPML mailing list records six different versions, including the non-merged intermediates. Participants 118 could also analyse ARIN staff and legal counsel’s report for their understanding of the policy intent; potential issues and concerns with respect to operational and legal issues and risks; and potential resource impact such as staff training, developing new procedures, etc.

Follow-up enhancements, as were explicitly identiﬁed and handled in this case, were explicitly linked by communication and reference from the discussion for original idea, but not from the follow-up ideas themselves. (Bugzilla provides explicit “blocks”, “depends on”, “duplicate” relationship categories for ideas) In ARIN PDP, new policy ideas (even explicit products of discussions about previous ideas) do not refer to previous ideas formally, and only to previous ideas in passing. With a smaller number of active proposals (and with ideas being conﬁned mostly to abstract concepts rather than implementation), and an explicitly communicated OEP, the few ARIN participants may track relationships among changes without explicit notes.

4.7 Categories of communication

Several categories of communication were identiﬁed throughout the case studies.

Technical: As expected from the purpose of work and discussion notes, this category of action was contained in one-third to one-half of all messages.

Administrative: As expected from the primary organizational feature of the OEEs—to conduct the processes in an open and documented manner—this category of action was contained in one-third to one-half of all messages except in ARIN’s PDP, which had little discussion of the currently engaged innovation process, and a small number of (possible) administrative actions overall.

Conceptual: This was not a useful independent category of actions communicated. Com- munications with respect to questions, arguments and reducing ambiguity were easily identiﬁed in both successful and non-successful innovation processes, but all occurred in the context of technical and bureaucratic actions where they would be expected. 119

Social: This was not a useful independent category of actions communicated. Instances and functions were were common to both successful and non-successful OEPs. Agreement, support, suggestions, discouragement, threats, apologies, admissions and compromises all occurred and were communicated in the context of technical and bureaucratic actions. Of possible human interest was that gratitude was rarely expressed (perhaps once or twice in an OEP of several dozen exchanges) since almost every message was from or to participants were volunteers who asked for or provided work or information. Gratitude was only consistently used in one case in which the formal OEP had deteriorated. ARIN-PPML was the only list in which messages containing only humour were noted (e.g., Hennigan, 2008).

Use Cases: Use cases were consistently the subject of fewer messages than administrative or technical actions. Dividing use cases by internal or external sources, and by their positive or negative reception helped explain their use in OEPs. Discussion of a small number of internal or external use cases which were not supported appeared sufﬁcient to bring an OEP to poor outcomes unless those discussions provided an explicit resolution of the unsupported cases

(such as a plug-in, future bug, errata, or conﬁguration option).

The following summary was compiled using Thunderbird, employing its ability to visually represent series of e-mail discussions as threads showing how each message relates to its neighbours in each conversation, based on mechanical references built into the message format standard. In addition, each conversation was inspected for replies which were functionally or semantically linked, but which not mechanically linked. Questions were explicitly identified based on the presence of the question mark punctuation, and in addition, other rhetorical forms demanding responses—such as objections or pleas concerning scope (missing use cases)— were also noted. Each message was then examined for whether its substance related to one or more of four categories of conversation: internal use case, external use case, administration, or technical content. Substantially all messages unambiguously fit into at least one of those four categories, as discussion of such were the main functional purpose of the mailing lists. A fifth 120 category, of jokes, was observed in some discussions on the ARIN list (the list also facilitates social discussions among Internet operations professionals, so this was not unexpected) but did not prove analytically useful.

4.8 Summary of observed communication patterns

From Figure 4.1, some communication patterns emerge. First, most messages did not receive replies, and successful OEPs may have more replies than non-successful OEPs. For example, there were many responses in ARIN 2008-4 but proportionately fewer in ARIN 2008-7. This is unexpected if the communication systems were viewed as collaborative spaces, but expected if the communication systems were viewed as broadcast channels in which recipients ﬁltered their own participation. Most communications did not explicitly seek replies.

Second, most requests for information received replies, even if such replies were dismis- sive. Successful OEPs had more replies than non-successful OEPs. This pattern agrees that participation is important to OEPs. For example, ARIN “Annual Whois POC Validation” had more replies than ARIN “Whois Authentication Alternatives”.

Third, extended dialog between participants was rare in the sense that long threads of discussion were uncommon. Many, often terse, replies were made to few messages in short time periods.

Fourth, individual communications do not often fall into a single category or convey a single action. Typically, use cases were coupled to technical or administrative information.

Finally, few or many ‘–’, unanswered technical questions, does not appear to result in a non-successful enhancements, whereas ‘–’, unmet use cases appear more readily fatal. This indicates that, during the OEP, technical implementation are less important than potential use.

This observation agrees with the previous observation that consideration of use cases, and stakeholder participation through submitting use cases, is important to the OEPs. 121

RESPONSES:2 RESPONSES:0 RESPONSES:0 RESPONSES:48 TOTAL:25 TOTAL:23 TOTAL:28 TOTAL:72

...... ###...... +++##+# #.#..#...... #+##.^#..#.....

0 0 0 12 8 21 45

RR: RR: RR: RR: 2 0 0 35 R: R: R: R: .#^+#+#^. C C C C -

RESPONSES: RESPONSES: RESPONSES:0 0 1 2 6

RESPONSES: ^##

- 1 11 49 77 49 107 RNR: RNR: RNR: RNR: his category) 23 22 26 19 TOTAL: TOTAL: TOTAL:

TOTAL: CNR: CNR: CNR: CNR:

RESPONSES:0 0 1 0 27 RESPONSES: RESPONSES:0 RESPONSES:

3 23 26 33 RR: RR: RR: RR: 8 20 0 18

R: R: R: R: C C C C TOTAL: TOTAL: TOTAL: TOTAL:

0 0 0 6 1 1 0 8 RR: RR: RR: RR: 0 1 0 5 RNR: RNR: RNR: RNR: R: R: R: R: 40 55 49 54

C C C C

2 9 0 0

: CNR: CNR: CNR: CNR:

RNR: RNR RNR: RNR: 1 13 26 22 RESPONSES:0 RESPONSES:0 RESPONSES:0 .....#...... #.###..###

RESPONSES:4 -

CNR: CNR: CNR: CNR: 1 2 8 15 ) SUCCESS (continued) .+###..+#. #^+^#^#.+#^#.##+#####.+#^#.#.+^#.###^#+^+#.## - R:0 RR:0 TOTAL:6 RESPONSES:0 R:3 RR:0 TOTAL:9 RESPONSES:3 R:0 RR:0 TOTAL:11 RESPONSES:0 R:1 RR:0 TOTAL:17 RESPONSES:1

-- C C C C . -

+## FAIL TOTAL: TOTAL: TOTAL: TOTAL: : - SUCCESS 0 0 0 3 #....#.+##++^+^++++++++++++^++++##...+#.#. ##.....##.##.....#..#..#.#...... #...# - RESPONSES:0 RESPONSES:1 RESPONSES:0 RESPONSES:2 - #.#..#+##..#.+#+#.#+######..+.###.#....###.#...... ## ...... ##..#....#...... ####...... ##..##.##....###..##..#. ....#.. RR: RR: RR: RR: #+# SUCCESS - 0 0 0 1 : A request, objection, missing use case, or technical question that is not responded to (RNR) - 404109 # AL:7 Actions #: A communication that is not responded to (CNR) - ^: A communication that is responded to (CR) +: A request, objection, missing use case, or technical question that is responded to (RR) .: (typographic placeholder; communication is not in t - RESPONSES:0 RESPONSES:0 RESPONSES:0 RESPONSES:1 R: R: R: R: C C C C TOTAL:1 TOTAL:3 TOTAL:2 TOT

.....##

0 0 0 0 27181 .#.. 0 0 0 0

SUCCESS ) SUCCESS - [email protected] ... CNR:3 RNR:3 40848 FAIL .. TOTAL:1 TOTAL:0 TOTAL:2 TOTAL:2 -- -

RR: RR: RR: RR: RNR: RNR: RNR: RNR:

0 0 0 1 0 1 0 2

placement 1 2 8 11 ^++++#+^^#^+ ##...... CNR:16 RNR:0 .....#...##..#.#.....##.#..#.##..# R: R: R: R: - +#....#.. CNR:4 RNR:2 C C C C - ...... # RR: RR: RR: RR:

- - S error pages 327181 0 0 0 0 0 0 0 0 CNR: CNR: CNR: CNR: ++# secure 34607 ([email protected]) SUCCESS R: R: R: R: - button C C C C ” ..#+#

- 0 0 0 0 RNR: RNR: RNR: RNR:

Non ++^## 1 2 2 5 request or action - ome #...#.#...... ######.# “H - threaded windows . -- RNR: RNR: RNR: RNR: CNR: CNR: CNR: CNR: ..^####....+^^^.^^.#.#.##+^.^#^# 1 0 2 1 ox Firefox HTTP -- .+^^##^ : ...#+ CNR: CNR: CNR: CNR: -- ^^# - Apache Log rotation 44427 Apache SNI Apache SNI Secure 34607 ( #..#..#..#.##.#.#.....#...... ##.##..#...#.... Apache SNI 34607 (Bugzilla Firefox HTTPS error pages 3 - Firefox Firef - ...#.....#..#...... ##.+#...... #. .#...... ++...#...#...... -

...... #.. Case 2: I E #.#######..####.##.++#..+#+#++##..#.#.++##... A..#.#...... #.##... T...... ++....#...... ^#+#...... +...#.^.#....# - External use case considered : Categories I: Internal use case considered E A: Administrative T: Technical request or action J: A joke Case 0: I #...... E #.+#..... A ...... ##. T +##.##+.# Case 1: I #.. E ... A .## T #^. Case 1: I ...##.###.##....#....#.###.##.##...... ##.+...... ###.....+#.....#...... E ...... #...#.##.###...#... A ###.. T #.^+#.+ Case 1: I ...... #... E .#...... #... A #...###.....##...## T .##+#.###^##^^###.. Case 2: I #..# E #...... ##....#..#+...#+#+#.#^#####.#.#....#.....#...... #.++#...... #.##...... #+...... #...... A ##...... ##..#...###...... #.... T ^.#+#^ Case 3: I ...... E ...... +. A #.##...#.##.##...#...... #....# CNR:11 RNR:0 T ##..###.#.##..##+#.###.... Case 4: I .. E #...... A .#.##....#..#..####..#.#.###.#.#.#.#..#.#####.#.# T ###.#+#.+###...... ##^#.^#^##.##^+##+^+###.^.#.

Figure 4.1: Summary of communication types 122

- .#

- .... #.

:32 - --

:30 ONSES:0 RESPONSES ..#...... RESPONSES:0 RESP RESPONSES:0 - 21 30 11 58 RESPONSES:0 RESPONSES RESPONSES:0 RESPONSES:0

36 23 3 54

TOTAL: TOTAL: TOTAL: TOTAL: :20

0 0 0 26

TOTAL: TOTAL: TOTAL: TOTAL:

RR: RR: RR: RR: ...#...##.+#.#####.#.... 0 0 0 28 0 0 0 5 - ###^.^+##+^...^# - R: R: R: R:

RESPONSES:0 RESPONSES C C C C RESPONSES:0 RESPONSES:0 RR: RR: RR: RR:

:2 :8

0 0 0 2 0 0 0 0 14 14 7 38 R: R: R: R: C C C C

1 3 0 1 RNR: RNR: RNR: RNR: #...+^^^## 21 30 11 27 - TOTAL: TOTAL: TOTAL: TOTAL:

RESPONSES RESPONSES:0 RESPONSES RESPONSES:0

#..####.####.####.+...#..###+#####.####.

RESPONSES:0 0 0 0 13 RNR: RNR: RNR: RNR: -

CNR: CNR: CNR: CNR: :2 :8 :32 12 23 4 15 3 35 20 3 23

### #++##. RR: RR: RR: RR: - - SUCCESS 0 0 0 7 CNR: CNR: CNR: CNR: R: R: R: R: C C C C

TOTAL: TOTAL: TOTAL: TOTAL: TOTAL:

1 0 0 0 5 0 0 0 0 4

(continued) :3 RESPONSES RESPONSES RESPONSES:0 RESPONSES RESPONSES:0 #..#..+ PARTIAL

-- 51 85 4 75 5 RR: RR: RR: RR: RR: OCs) Part 2 March 2009 SUCCESS 0 2 0 3 0 RNR: RNR: RNR: RNR: .#####. nication that is responded to (CR) ##.##...##++ R: R: R: R: R: 14 14 7 14 - C C C C C

: RESPONSES:0 RESPONSES: RESPONSES:0 RESPONSES TOTAL: TOTAL: TOTAL: TOTAL: 0 1 0 1 0

TOTAL: CNR: CNR: CNR: CNR:

3 4 4 10 0 0 0 18 0 lternatives SUCCESS RNR: RNR: RNR: RNR: RNR: : A request, objection, missing use case, or technical question that is not responded to (RNR)

Actions #: A communication that is not responded to (CNR) - ^: A commu +: A request, objection, missing use case, or technical question that is responded to (RR) .: (typographic placeholder; communication is not in this category) RR: RR: RR: RR: RR: 12 20 4 6 3 2 8 0 14 0 TOTAL: TOTAL: TOTAL: TOTAL:

0 0 0 1 R: R: R: R: R: CNR: CNR: CNR: CNR: CNR: ...... #.....#...##...... egrity Proposal FAIL C C C C C

mail cleanup SUCCESS #. ..###.#....##..##.#..###..##.##.##.####..#..#.#.# ..##.+#.#.##...## - RR: RR: RR: RR: 4 10 0 10 0 - - 0 1 0 2

: tegrity Proposal FAIL R R: R: R: C C C C

RNR: RNR: RNR: RNR: RNR: l Whois POC Validation SUCCESS 0 0 0 2

##+^#^^^++####^# 45 67 4 33 5 - 7 Whois Int ois POC E ^ - hois In - RNR: RNR: RNR: RNR: CNR: CNR: CNR: CNR: CNR: 3 3 4 5 4 Caribbean Allocation 7 W 7 Wh 7 Annua 7 Whois Authentication A 7 Whois (Identify invalid P

------# #...... ##.##...... #...#..### - #.#.##+##+##### .#.#.###.####.....############.###.###.##. - CNR: CNR: CNR: CNR: - - ^##^#+^....+^^+#.#.+#^^#^^...... #.#.. ARIN 2008 - .+.###..#.###.###### - : #....

- ^#^^#^^#^#^######+#^^^^##^^#^^^#^^+^#^#^#^^^#^#. ARIN 2008 ARIN 2008 ARIN 2008 ARIN 2008 ARIN 2008 ARIN 2008 - ###^# ....##..#.....###..##..####...... ##+.###. : : #+^##^##+++^#^^ : ...^#....+.^.##+#.^...#..+.# : .## ...... ++#^#+# 7 -- 7 - 7 - 7 - Case 6: I ...##..##.. E ..#..#### A T .##+##....# J #...... -- - -- Internal use case considered #...... #...#...... #...... Categories I: E: External use case considered A: Administrative request or action T: Technical request or action J: A joke Case 5: I ...... #...... #...... #######.###.#...##.#..#.###...... #.. E ...#..##...##..########..##..###...... ##..###.#.#####.#... A .##..#..###...... ##.....###.. T .######.##^+^#^^+^^^#+^+^^^^##^+^#^#^^##^^^##^#^#^^###.#^#^## Case 6: I ....##...... #....+##... E .# A T ^ J ...... Case I ##....#... E .+##..#... A #...... ### T #++ Case I #...# E #...... ###..########...... #.#...... A #...... #...#.###...... #.. T ^^ Case I .#.####.#...... ##..#.....##.# E .####.#+# A .#.#...... #.#...... T .^^ J ...... #.#...... #...... Case I #.##....###. E #.# A #...... #...... # T ^##^^#

Figure 4.2: Summary of communication types, continued 123

Together, these observations indicate that participants were knowingly exploiting channels provided by the OEEs to focus or divert attention on particular ideas or idea sources of individual interest.

4.8.1 Information sources

As expected for software and policy work, much of the information exchanged was technical in the sense concerning the new software code within the enhancements and the existing software code with which it needed to interact. However, participants also referred to important informal discussions—via Internet relay chat, mailing lists, e-mails, in-person meetings—outside the formal documentation and infrastructure. In most cases, code was communicated and revised in the formal Bugzilla and discussion lists, although instances where code was developed almost entirely inside or outside each environment were observed.

Information from outside OEPs, such as other parts of the project or organization; other projects, products, organizations, etc. were sometimes referenced for authority. Use cases from third-parties to the OEP such as prior or prospective end users of the work of the project, or analogous works were used to support or refute ideas for which there was external prece- dent. In the case of software OEEs, competing web servers or web browsers provided external information. In the case of ARIN, information from or about registrars in other geographies, and internal policies, practices and perspectives of members could be viewed as external to the

PDP.

The timing and frequency of the exchanges appear important to the OEPs. Minimally, dialogs needed to be timed to convey requests of information or action, and their responses, to provide participants sufﬁcient opportunity to interact. Timing and frequency of different types of information differed with respect to the phases of work and decision-making. 124

4.8.2 Information ﬂows

Formal requests purporting to be about individual enhancements were, more often than not, components of larger groups of enhancements around common themes. Through implementation and discussion, ideas were found to generate other ideas, depend on previous ideas, or refer to information and changes contained elsewhere in the project (sometimes in the context of technical legacy). The bounds between the inside and outside of an idea were not consistent across ideas, regardless of whether the work involved blue sky ideas, internalizing external ideas, or catch-up work to comply with a standard. Operationally, the bounds were traversed by individuals trusted to work on, or review, ideas or code on a broader scope.

Ideas introduced to OEPs used rational arguments to overcome technical and conceptual resistance. The actual technical work contributions were mostly from individuals inside the project, with outside attempts at contributions being informally discouraged through claims of prior art (e.g., describing an internal effort is already implementing something better than the contributed work) or routing through an unfamiliar bureaucratic process (e.g., requesting contributors to re-submit through another mechanism). Most contributors who were not internal to the projects contributed exactly one instance of input (of one or more ideas or support or objections) to an OEP, without leaving evidence that they received or understood the effects of their inputs (they mostly did not contribute follow-up correspondence). Formal input from multiple parties brought support, questions, and objections. It was not superﬁcially obvious if minimizing the number of contributors to an OEP (except the ability of an internal developer to start with a blue-sky idea) is linked to success of an enhancement. One of the effects of a communication act was to relate (actuate) a part of the OEP with respect to the environment. Inputs were communicated from the environment to the OEEs and shepherds, while OEE outputs were communicated by shepherds to the environment. 125

4.8.3 Accessibility

Users’ ability to adapt and use speciﬁc inventions formed an important part of participation.

User input was infrequently directly solicited in early stages of implementation, but valued for testing prototypes. Individual contributors’ experiences with third parties served as proxies for direct information from users. Some users stumbled upon an idea, added their support, and were never seen again. Some users’ ideas and other inputs were effectively hidden from view through administrative consolidation of bug reports. Users cited such consolidations as support for getting the requested or contemplated feature implemented. Developers and contributors did not formally note such consolidations, except in cases of disagreement over whether the consolidated duplicates contained the same information or ideas.

Participants attempted to understand users and third parties through use cases, especially when adding an optional enhancement but also when substantially changing a non-optional function or feature. Contributors freely suggested additions and reﬁnements to improve the robustness of enhancements in situations and environments not contemplated by shepherds.

They also cited examples of how third parties used characteristics of the products which were related to proposed enhancements. This was also tied to the attention to legacy. Disclaimers occasionally lowered expectations.

4.8.4 Use cases as evidence

Some ideas could disable existing uses by changing interfaces or behaviors. Shepherds generally did not want to alienate existing users by adding new features which would break existing technical or cognitive usage patterns, although the Firefox “Home” button relocation provided a good counter example. Shepherds were, in general, very conscious of not forcing users to do particular things. Users cited evidence of external use cases to support adding features. As previously discussed, OEEs are intended to be transparently and easily accessible and extend- able. Analogous third-party extensions worked in favor of some ideas which “should be” built 126 into the product but against most which were left as extensions.

Some enhancements were non-successful since they were not incorporated into the core project, but were successful in that they were implemented as plug-ins to prove their use cases in that environment. By contrast, the Apache HTTP Server core development was consciously not concerned with breaking compatibility with plug-ins elsewhere in the project or from third parties, but they did show an awareness of the plug-in ecosystem.

4.8.5 Social factors

Some communications did not directly contribute to technical implementation, but facilitated the smooth operation of the OEEs.

Gratitude, apologies and compromise: Gratitude or appreciation was expressed infrequently (or not at all), sometimes to the shepherd, other times to other contributors, regardless of the number of work or idea items contributed by any number of contributors. Inputs were frequently acknowledged when used, but not formally appreciated. Apologies (mostly for technical misunderstandings) were extended more frequently than gratitude, but not much more frequently (perhaps twice per enhancement), and did not seem to be required for misunderstandings to be corrected. Compromises and negotiations appeared to work quite efﬁciently, in that even philosophical objections are handled objectively and with respect. Such graces did not readily associate with enhancement success or non-success.

Malice: Unsolicited input and questions from outside stakeholders was sometimes ignored, or trivialized as edge cases, improper usage, poor reading comprehension, misguided discussion, or inferior work. Followups were also deemed outside the scope of the original idea (as arbitrarily defined and documented), or outside the scope of the process (for example, suggesting a technical implementation without considering the problem). Users and discussions were also divided and contained in different forums. The support forums were not a sanctioned source of ideas for enhancements. Bugzilla items may be split or merged, or given lower prior- 127 ity or status, or combined with omnibus items containing problems which can never be solved completely. Suggestions may have been deemed more appropriate for a non-specified third- party. User comments about “CLOSED” or rejected ideas drew expressions of annoyance and threats, especially if users pointed out deficiencies, instead of constructive suggestions. Such behaviours were observed with both successful and non-successful enhancements.

Risk: Risk-taking was communicated into the OEEs by every action of every contributor.

Risk motivated discussions, being shared with others who inquired, demonstrated commitment by entrepreneurs or ideators, and validated ideas as plausibly desirable. Participants understood risks by exploring of known and prospective use cases, since disabling current productive use cases and limiting potential adoption jeopardized accessibility and usability. One tactic used to convince others of the acceptability of a new idea involved disclosing risks through disclaimers explaining how particular use cases and potential negative consequences could be handled within an implementation. Countervailing tactics dissuading adoption included: highlighting

(existing or prospective) use cases which would not be accommodated by a proposed enhancement; appealing to complexity with respect to unacceptable changes required of other parts of the system to support an enhancement; and emphasizing potential negative consequences and interactions of proposed changes. These do not appear unique to the OEEs studied.

4.8.6 Issues encountered

First, the OEEs recorded far more kinds of activities and content than could be concisely studied or analysed. In particular, while they shared features to receive and discuss input and ideas, they differed in how other functions were arranged. For example, the Apache HTTP

Server developers list facilitated operational discussions, as well as formal and informal voting to accept or reject ﬁnished inventions into the product (Rowe, 2009). It also enabled discussions about organizational structure (Erenkrantz, 2008). Firefox conducted votes and approvals through its Bugzilla, and discussions about structure and governance through a separate 128 mozilla.governance news group. ARIN members used the PPML for only part of the voting process, and also to discuss professional and industry matters. The model for the present research does not take this kind of variability into account.

Second, enhancements, bugs, and requests were inconsistently referenced by their generic bug number, component or other identiﬁer. The current method identiﬁed all explicit references to an idea contained in a numbered bug, but may incompletely capture all relevant parts of a conversation. The ARIN WHOIS discussions illustrated an almost ideal case without the fragmentation enabled by asynchronous discussions. However, even in that case, the concurrent but not formally linked IP version 6 discussions, and discussions on other regional Internet registrars’ policy mailing list analogues, in which some ARIN members also participated, may be analytically relevant data, but not data which conforms to the innovation environment and processes assumed by the participants themselves.

Third, ideas which did not enter the formal OEPs could result in enhancements, but are not directly testable by the current framework. For example, ARIN’s policy implementation activities and its ecosystem of third-party modules are not visible within the current data and act outside the OEEs studied. Therefore, only potential enhancements with direct veriﬁable outcomes as they pertain to the organization, and which are operationalized by or on behalf of the organization, are included. Excluded are such enhancements as suggestions for customer screening practices on the ARIN policy development list; asking how to build a social net- working engine, or general complaints about performance due to growing software size in the

Mozilla wishlist; or asking how to configure hardware for a specific anticipated traffic volume as in the Apache users list. In addition, technical support conversations were ignored analytically since user needs were satisfied by being supplied with existing information, but OEE participants are known to receive information from both development and support venues.

Fourth, Firefox and Apache HTTP Server both provided explicit ways for anyone to develop and add modules to the product by end users without notiﬁcation or permission of those 129 who maintain the core product. Thus, new ideas for enhancements may be funneled into either channel. The present research is insensitive to the differences between the two types of channels.

Finally, in addition to the cases detailed, six discussions about potential enhancements to the OEEs’ infrastructures were also initially noted as possible examples connecting OEPs to infrastructure in the opposite direction as H1a, H1b, and H1c. However, the contemplated changes would be enacted on incomparable timescales of weeks to years, and sought to change non-analogous parts of infrastructure. Under the current framework, Chapter 3 indicated that infrastructure has small effect on OEPs and enhancement outcomes, and this chapter has shown that the same infrastructure can produce both successful and non-successful outcomes dependent on communication patterns which varied freely. Therefore, studying infrastructure changes and their long-term implementation would not add much more explanatory power.

4.9 Analysis

• H1: User participation in an idea during or after the enhancement process, via consider-

ation of their use cases, supports adoption.

H1 is supported. Chapter 3 found that participation was important as a source of ideas. This present chapter found that participation, proxied through contributing use cases envisioning uses for particular enhancements prior to their completion, is associated with the success of those enhancements. Even if technically sound, ideas for enhancements did not generally advance until use cases speciﬁed or anticipated for third-party adoptees were understood and accommodated. Enhancements which disregarded use cases did not succeed.

• H2: Ideas championed by shepherds who communicate their risk-taking activities are

more successful than ideas whose champions do not communicate their risk-taking ac-

tivities. 130

While it was clear through the contribution of ideas, work, and prototypes that risk-taking was an important part of the process, nuances were observed.

Apache: Apache HTTP Server participants were risk-aware as expressed through its long process requiring many individual reviews and approvals. Iteration of implementation and review highlighted the many practical and use case details to consider and revealed technical errors. The OEE may be highly risk adverse as evidenced by technical conversations focusing on conformity (proposed implementations were criticized for not esthetically conforming to existing code or process), and by differences in adoption in their development and production platforms by a year or more. Apache HTTP Server’s developers guided novices to the support forum (via FAQ) to discuss alternative uses and innovations indicated risk-taking was to occur only at the periphery. By contrast, seasoned users and developers exercised restraint in their changes, always taking care not to disrupt existing use cases, or even to alter configuration file formats to retain compatibility. As shown in Case 1, established project leaders were reluctant to support efforts of outsiders, even to improve internal ideas. To an extent, well-defined external interfaces limited risks of outsiders’ activities to destabilizing the core platform, and also required new ideas to be patterned after well-known types.

Firefox: Firefox’s paid bureaucrats, like Apache’s volunteer leaders, were mandated to motivate progress since Firefox is the major component of the foundation’s mandate. Fire- fox fought to gain and retain market share, unlike Apache HTTP Server which was the default standard. Firefox faced competing needs to respond to diverse and changing end-user and web designer needs, and to keep the product accessible to potential new adopters. Fire- fox solicited and accepted anonymous input with simple interfaces outside mailing lists and

Bugzillas, Apache’s Bugzilla and mailing lists were behind technical barriers. Compared to

Apache and ARIN, Firefox’s third party interactions were less isolated, more diverse, and provided more opportunities for participants to take risks through contributing testing or use cases.

Although iteration in conceptual and implementation stages was common to all three OEEs, 131

Firefox shepherds seemed to take the most extreme risks in terms of violating OEE social norms, to make or prevent large-scale changes, even though Firefox had the largest practical constituency (and lowest barrier to ﬁling objections and use cases) of all three OEEs studied.

ARIN: Similar to Firefox, but less so to Apache, ARIN participants were asked to bring policy proposals, or brought them on their own, but proposals were carried by bureaucratically assigned shepherds from the elected Advisory Council. Mechanically carrying assigned ideas seemed to carry little practical risk, since the ideas were not the shepherds’ and were supported by at least some members of the community (the proposer). However, to advocate a new

ARIN policy—to change a norm about managing common resources—was a risky activity to shepherds and stakeholders since the sanctioning and affected group is a relatively small network of face to face peers. Their individual, open votes, were judgments of the shepherds’ professional skill and judgement about operations and policy, and of their perspective of the diverse community’s best interests. Reputation, both on-line and at meetings, was important as evidenced by individuals expressed aversion to resuming past disagreements, on the list and in person. Also, ARIN shepherds could not normally resign their assigned policies, unlike

Apache and Firefox bug assignees could hand off or reassign bugs fairly freely. Of the ARIN policies examined, none originated from outside the stakeholder community, nor bore on ideas it had not previously considered. Therefore, it was difﬁcult to examine high risk ideas in ARIN.

ARIN shepherds and ideators made fewer revisions in policy than Apache or Firefox shepherds made to code, even in the face of stakeholder suggestions. This indicates high conﬁdence in their ﬁrst drafts, as supported by relatively few follow-up communications from shepherds once a policy has been proposed. Although the tools to compose an English language policy are presumably more accessible than the tools to amend a large software platform, the software platforms are compartmentalized and require only investment to understand a small area, whereas the entirety of the ARIN policy manual must work as a logical whole internally, and also with established practices and procedures of its thousands of operator members. There 132 was also no opportunity to privately test proposed policy changes before public disclosure.

During the ARIN PDP, only policy proposers (and the AC) were empowered to amend their proposals. By contrast, the revision control systems in Apache and Firefox are enabled all trusted contributors to amend any ideas or projects within their responsibility. Operationally, trusted contributors were not observed to substantially amend others’ ideas in this way, but limited their actions to cleaning up source code arising from substantially completed OEPs.

H2 is supported overall. The possible shepherd is not “never the risk bearer” (Schumpeter,

1982, pg. 137), but good communication of risks taken by shepherds was associated with successful enhancements. Since risks brought ideas and use cases into the OEEs, shepherds’ risk-taking activity was required for successful OEPs. Cases 1 and 3 showed that risk-taking activities which are not communicated into OEPs did not form durable parts of those processes.

Therefore, ideas with shepherds who share that they take risks to improve their enhancements, to match adopter needs, have better opportunity to succeed. This, however, is not a remarkable conclusion, and it is satisfying to the potential generalizability of the research reported herein that similar results would be obtained through conventional SWOT analysis.

4.10 Summary

This chapter examined in detail typical and extreme communication and implementation activities in the OEEs studied, in cases of both enhancement success and non-success. It established that communication and implementation are strongly linked to each other, and to the success of OEPs. The data has shown that taking risks for the sake of the idea alone is insufﬁcient to advance an idea, and that risks are required be taken to meet potential adopters’ use cases in order for enhancements to be effective. This interpretation is consistent with an overall interpretation that in these cases, enhancements and the circumstances of their communication, must be for the adopters, and not for the sake of shepherds or for change alone. 133

The next chapter relates these observations to the operational hypotheses and overall framework of this thesis posed in Chapter 1. 134

Chapter 5

ANALYSIS

This analysis chapter reviews key ﬁndings from the previous three chapters. It does so in order to frame and posit a modest new theory to address the primary research question: How do communication patterns during enhancement processes relate to the success of those processes to yield enhancements? The proposed theory, to be illuminated in some detail, is:

Theory 1: Enhancements are contained in the communications surrounding a new idea, rather than in the technical embodiment of the idea.

Therefore, enhancements arising from well communicated ideas would be expected to be more successful than enhancements arising from poorly communicated ideas.

5.1 Review of key ﬁndings

The research has examined the infrastructure, communications, activities, and enhancement characteristics as they might relate to each other in three open enhancement environments.

Subtracting features of non-successful cases of enhancements from successful cases, aspects of

OEPs (structure, implementation, communication, and outcome) identiﬁed essential elements of successful OEPs. Some similarities and differences deﬁne the OEPs studied.

5.1.1 Comparing the three open enhancement environments and their processes

Similarities

Despite a diversity of infrastructures, the OEPs studied contained similar elements and produced similar outcomes. The substance of the OEPs—how shepherds and participants collected, communicated, and implemented ideas—followed common and clear pathways to suc- 135 cess as well as to non-success. Success required the originator of an idea to clearly communicate, to potential adopters, the problem solved by the idea. This must be done prior to supplying an implementation since OEPs increasingly restrain options as they advance. Further, the iterative OEP must consider information about how potential adopters might use an enhancement arising from the idea. All else held equal, ideas and OEPs that are discussed tend to do better than those existing in technical or conceptual isolation. Therefore, order of communication in the OEP is important.

Despite being computer mediated and physically impersonal, the OEEs employed familiar patterns of work and organization. Their potential to scale to encompass an unlimited number of contributors on each project (being unbounded by monetary considerations) yielded typical sizes of working groups of just a handful of individuals. Even the most signiﬁcant enhancements to the organizations were actively developed by mere pairs of contributors drawn from available pools of dozens of skilled volunteers and volunteer leaders. Although the formal processes and structures differed among the OEEs, they collectively organized around groups of similar size. Around 50 individuals out of 3,000 members actively developed ARIN policy enhancements. Apache projects had between 50 and 100 members in their Project Manage- ment Committees. Even with the larger organization and broader base in Firefox, no more than

100 individuals were ever observed to contribute to an OEP (up to the broadest sense of contributing by subscribing to a Bugzilla item), while development in modules was lead by small committees of rarely more than a dozen.

Those collaborative group sizes were not unexpected since Dunbar (1993) found that the average size of small level social groups to be around 30 to 50 individuals and intermediate level social groups to be approximately 150 individuals as predicted by individuals’ physical brain conﬁguration. The group sizes observed presently were smaller than those observed by

Dunbar. CMC lacks some physical social cues of conversation while international collaborations may present language barriers. The instant group sizes may be larger than Dunbar’s 136 due to the stronger requirement to be explicit in communications to remove ambiguities and inefﬁciencies arising from the above factors. An additional factor is that the working units under consideration were transient and ﬂuid. Each new idea initially draws attention from one or more experts or leaders in the component concerned, some contributors, stakeholders and bureaucrats. Meanwhile, each project’s continued work as a whole requires participation by particular individuals variously as technical experts, quality assurance testers, usability testers, reviewers, etc. across several concurrent enhancement processes. Non-monetary resource limits obviously remained.

It was observed in the Apache and Mozilla Bugzilla recorded that project leaders had communicated their choices to delay work on speciﬁc enhancements due to insufﬁcient time or attention in order to attend to immediate and important tasks. Other ideas and imminent product releases both competed for attention. ARIN exhibited this problem, but to a lesser degree, with respect to preparing policy proposals for policy discussions at their semi-annual meetings.

Differences

ARIN’s Policy Development Process differed from the two software OEPs, employing formal- ization to ensure that all policy proposals were considered on a timely and fair basis. Super-

ﬁcially, ARIN’s PDP lacked sub-categories of statuses such as “enhancement” or “bug” and priority levels found in software the OEPs. More fundamentally, ARIN focused on desirable ideas through deliberation, as found in Apache and Firefox, in preference to choosing based on simple resource metrics or proxies.

And unlike Apache and Firefox software, ARIN’s body of policy is differently difﬁcult for participants to experimentally manipulate in distinct ways. Any stakeholder or contributor can modify and experiment with a copy of software source code to generate isolated prototypes, but there is no copy of the Internet infrastructure and associated stakeholders with which to do the same experiments. However, ARIN’s policy encoding (in English) enabled contributors 137 to more easily experiment conceptually without needing to coordinate synchronized copies of source code with other collaborators to achieve insights about potential changes.

Communications during an OEP must therefore consider not just the formal structure of an OEE, but how each infrastructure engages participants. Compared to Apache and Firefox projects—in which instigators communicating about initiating administrative processes formed critical elements in the progress and success of ideas—ARIN’s administrative processes occurred automatically. Hence there were few to no discussions about bureaucracy, although the administrative process reminded participants of its presence through the standard notices arising from formal procedure. ARIN’s formal timelines should have insulated ideators and shepherds from some potential negative effects from reputation and human relationships. However, policy approval was operationally controlled entirely by elected but well-established individuals of the technical and policy community. Also, ARIN considered relatively low volumes of dozens of new ideas per year in a substantially labour intensive and time-limited process for each enhancement, rather than the several hundreds to thousands of new ideas generated around Apache HTTP Server or Firefox, each of which required minimal manual processing.

Conceptual prototypes of proposed ARIN policy implementations elicited similar kinds of dialog as those observed when prototyping software enhancements. Ideators, shepherds, and community members considered reports about components that could work as intended, components that could not work, missing resources and considerations, and consequences to broader features of the system were considered. Leaders and bureaucrats in all three environments used tacit knowledge to assess, verify, and merge contributions into the main product.

Development of a new idea in software and development of a new idea in policy were similar.

A software enhancement was expressed in a series of logical propositions which became massaged into the local style of the computer procedural and functional source code, whereas a policy enhancement was expressed as a series of logical propositions which become massaged into the local style of the administrative procedural and functional operations manuals. The key 138 difference appears that the paid ARIN bureaucrats appeared to be willing to do a lot more work in the massaging than the Firefox or Apache volunteers (and paid bureaucrats) who preferred to ask the contributor or shepherd to make enhancements ﬁt. (This difference is not hidden, but in fact is well communicated during all the OEPs studied.)

Immediacy of results helped contributors understand how the systems would behave with changes in place, and shaped how their ideas and the expression of such ideas changed. ARIN-

PPML discussions needed no machine translation (compilation) to mentally work through conceptual issues, while Firefox software development required a compilation step, and Apache

HTTP Server enhancements needed both a compilation step and usage of a test scenario to serve web pages. This was reﬂected in how ideas and enhancements were iterated as mere thoughts in ARIN-PPML, but as tested software code in the software projects.

5.1.2 A modest emergent theory

This research set out to “explore the linkage between patterns of communications content and patterns of enhancement” positing that some combination of infrastructure, implementation activities, communication patterns, or enhancement patterns inﬂuence enhancement outcomes.

This section builds on T1: that success of an enhancement arises from the bi-directional communications surrounding a new idea, rather than in the experience of the embodiment of the idea, or in the technical embodiment of the idea.

Communication being at the heart of innovation is not a novel proposition. Rogers (1962),

Gladwell (2000) and others have explored the supply side push of information and innovations in various ways. The bi-directional focus concerns the communicative role of potential adopters and other stakeholders during the OEP leading up to an enhancement becoming available to adopt.

Plainly, an idea for an enhancement must precede adoption. Ideas must certainly exist before the usage of widgets for particular purposes (but widgets can pre-date ideas for new 139 uses). Concepts must be adopted before a speciﬁc policy text, and the policy text must be adopted before its implementation as procedures concerning particular situations or resources.

But these conceptual adoptions must be expressed as support or argumentation back into the enhancement process to inform it that a use case is available and that the risk (to put effort into the enhancement) is worth taking.

By way of example, Case 3 (the needless Firefox “Home” button relocation) and Case 1

(the Apache HTTP Server secure SNI with unclear code logic) enhancements showed that without communicating the reasons for a proposed technical change, the idea was not adoptable since potential adopters with veto power (not necessarily users) were inhibiting from foreseeing prospective beneﬁcial use cases for the enhancements.

More broadly, eight themes emerged:

• Theme A. Infrastructure facilitates but does not inﬂuence with enhancement outcome;

• Theme B. Poor internal communications results in poor outcomes;

• Theme C. Poor communications with external stakeholders results in poor outcomes;

• Theme D. Poorly timed communications results in poor outcomes;

• Theme E. Poorly timed implementation results in poor outcomes;

• Theme F. A high rate of non-adoption is to be expected;

• Theme G. Lack of internal and external iteration results in poor outcomes; and,

• Theme H. Enhancements which are not communicated as fulﬁlling their use cases do not

succeed.

They are framed in non-success instead of success since non-success is numerically the more common case in general, as evidenced in Chapter 3. 140

5.2 Eight emergent themes

The following eight themes emerged when considering the data supporting (or not) the framework from Chapter 1. Although they could each be worded as a hypothesis in support of

Theory 1, they are left as statements of relationships as observed during the compilation of this thesis.

5.2.1 Theme A. Infrastructure facilitates but does not inﬂuence enhancement outcome

As Chapter 3 showed, the OEEs’ formal infrastructures did not inﬂuence the overall success of ideas to become adopted enhancements. The infrastructures provided a common mechanism to receive input from users and stakeholders, but the participation rate was universally low. A large majority of ideas available to the OEEs in all infrastructure conﬁgurations did not enter a formal OEP. A large proportion of ideas fell out at each stage of all OEPs. And the “features” communicated in marketing materials at the end of the OEPs may or may not relate to the actual enhancements contained in the product marketed, regardless of how they entered the product.

As Chapter 4 indicated, organizations attempted enhancements commensurate with their objectives. The infrastructures and procedures applied to collect ideas and implement enhancements were all comparable, despite a diversity of formal infrastructures employed.

The formal infrastructures specified the procedural and workflow aspects of an OEP, and hence where communications should occur. As Chapter 4 showed, compliance with a formal workflow and communications requirements was fortuitous at best, and muddled via unex- plained enhancements and active circumvention of the formal OEPs at worst. Chapter 4 also presented evidence that shepherds who complied with the generic intent of the infrastructure

(to facilitate an OEE) generally achieved more success than not. Each infrastructure contained all the information about every known potential enhancement, but did not favour particular en- 141 hancements to succeed. Enhancements were required to be communicated from infrastructure to stakeholders and potential adopters by shepherds.

5.2.2 Theme B. Poor internal communications results in poor outcomes

Recall from Chapter 4 that bureaucrats and participants exhibited strong roles for themselves in regulating their own enhancement processes. Participants were concerned about the ability of both internal and external stakeholders—present and future—to contribute and participate in OEPs and OEEs. Thus, infrastructure patterns affected communications patterns and implementation activities.

Separating communication patterns from infrastructure, cases from Chapter 4 indicated that individuals implementing an enhancement sought, if not required, inputs from key internal stakeholders to proceed with technical work, and that communicating progress made was crucial to achieving further progress and input. Although the nature of the use cases communicated differed in details for the three environments, they shared the feature that open communications generally resulted in generally positive implementation activities and enhancement adoption.

Further, when the participants were not discussing discreet enhancements, their system level of focus and thought reveal that within these OEEs, how the enhancements are to be used by adopters takes higher priority than the institutions driving the enhancement. Participants discussed the importance of systems of modules continuing to function for users, such that adopting ideas that break existing functionality required substantial justiﬁcation. Failure to engage well in such internal communications (as in the Apache secure SNI case) resulted in delays in implementation and frustration for contributors. This may be a signiﬁcant contrast to efforts in which producers push enhancements and new features into the marketplace without primary regard for end users’ expressed use cases for the enhancements, whether expressed directly or by proxy. Web browser software and web server software from other publishers— including technically capable organizations such as Microsoft, Apple, and Netscape—have 142 been imposed on users without users’ priorities at the forefront with varying degrees of success.

Failure to internalize stakeholder ideas and use cases was repeatedly found to lead to dissat- isﬁed participants and non-successful enhancement outcomes. The converse was also observed.

In this analysis, accurately identifying stakeholders in the OEP depended on the sensitivity of data collection to the enhancement process it sampled. As Poteete and Olstrom (2004) pointed out, differences in roles and responsibilities of participants in ongoing collaborations can be subtle and informal. Since historical data is not amenable to directly asking prob- ing questions to distinguish between differences in responsibilities and practices, identifying stakeholder roles and their inﬂuences required comparing recorded contributions against the roles and responsibilities as laid out in formal organizational charts, and against the informal roles assumed by participants. Participants would have also used similar tactics to understand the OEEs. It was observed that failure in leadership or individual failure to faithfully ful-

ﬁll the required roles limited stakeholder access to bureaucrats or data for discussion, which in turn restricted information about use cases during OEPs. Shepherds acting as adopters or stakeholders generated important use cases for discussion and also beneﬁcially delayed some implementation processes to produce more fully contemplated and robust enhancements.

By contrast, internal communication could become ignored. For example, the Bugzilla systems automatically e-mailed monthly lists of open bugs to subscribed participants. Apache

HTTP Server’s Bugzilla contained over 1,000 unresolved items as of Septermber 2009, while

Mozilla Firefox’s Bugzilla contained many times more. Many messages on ARIN-PPML did not relate to particular policy proposals. If no participant saw a patch or idea in Bugzilla, it could not follow a path to successful outcomes and was effectively ignored.

5.2.3 Theme C. Poor communications with external stakeholders results in poor outcomes

The data has shown that poor communication between the inside of an OEP, and the potential adopters on the exterior, resulted in poor enhancement outcomes. It appears required that the 143 shepherds both communicate the purpose and properties of an enhancement to adopters, as well as to receive input from potential adopters, during the OEP. Successful enhancements at least required adopter buy-in, but did not appear to be completely driven by adopters. (Again, this is not the only obvious conclusion, since enhancements arising from the three OEEs are used by hundreds of millions of individuals on a daily basis, many of whom have no knowledge of

Apache, Mozilla, or ARIN.)

Explicit evidence came in the form of the projects’ end user support forums in which allies of the shepherds communicated how to use the existing features of the products to adopters who encounter difﬁculties. The observation that the the number of interactions with adopters occurring through the support forums (from June 2008 through July 2009: apache-users:

8,732 messages; mozilla.support.ﬁrefox: 24,678 messages; ARIN-discuss: 1,493 messages) is not small when compared to the number occurring through the development forums (from

June 2008 through July 2009: apache-dev: 14,003 messages [of which over 800 messages were administrative voting and release notices, 2,000 were automated commit notices, and thousands of messages were automated or semi-automated other administrative messages]; mozilla.dev.apps.ﬁrefox: 3,875 messages; ARIN-ppml: 6,765), indicates that an enhancement does not become useful (or an enhancement) until the user or consumer makes it so. This observation complements the previous observation that the majority of original ideas for enhancements come from end users and not the bureaucrats or paid developers or shepherds in charge of the products. In the case of ARIN, the end users (Internet operators) were substantially the “developers” of policy, so it was not surprising that relatively few messages (about philosophical issues and interpersonal drama) were taken to ARIN-discuss. By contrast, Firefox end users were substantially not the developers.

Even internally, contributors with new ideas routinely created use cases based on their expectations of external adopters’ needs. In so doing, the contributors were revealed to temporarily play the role of the user to internally simulate demand for a enhancement, or to advance its 144 development. Structurally, the communication tools (Bugzillas and mailing lists) were set up to push conversations and information out to stakeholder subscribers to solicit input from at least the interested or active subset of stakeholders. However, actual conversations and information exchanges were frequently limited to a handful of even those stakeholders, and infrequently directly engaged external stakeholders who could only come across conversations by chance when actively searching for information about related concepts and functionality.

Even though it represented a narrow view of the environment in which adopters would use each enhancement, this dialog, among contributors internal to a project and between internal and external contributors, was observed to provide crucial information to those implementing enhancements about use cases to consider and how the enhancements would affect current users of related parts of the platform.

This observation implies that enhancements forced to be adopted may or may not be seen as enhancements to particular users.

Browser and web server platform upgrades are only packaged as bundles of enhancements which have been tested and released as of particular dates. Users cannot easily choose to just have just particular new enhancements without editing and building their own versions of

Firefox or Apache HTTP Server from the source code. And there is only one authoritative copy of the ARIN resource allocation policy book, and only one authoritative copy of the ARIN registry. Even though changes made to these platforms are documented in communications intended for adopters, it is famously not the case that users of products read or understand accompanying documentation.

Individual users are therefore not adopting all new features of a product, only the small subset they use. Enhancements not successfully communicated (through documentation or the user interface) are unavailable for adoption and are not successful enhancements as de-

ﬁned. (Recall the issues observed with moving Firefox’s “Home” button broke compatibility with third-party plug-ins, wherein bureaucrats thought the project’s goals more important than 145 their adopters’ existing use cases.) To the extent that only a small fraction of a product or a platform’s capabilities is used by any individual (although their potential for use may or may not impart psychological value), Apache HTTP Server, Firefox, and the ARIN policy manual largely consist of non-successful enhancements. Users have the opportunity to know about the capabilities of new versions or products from Apache, Mozilla or ARIN, yet do not use the majority of existing functionality. They seemingly prefer to work with pre-packaged bundles of potential functionality (e.g., the Linux-Apache-MySQL-PHP (LAMP) stack is a standard for packaging Apache HTTP Server with useful complementary software; Firefox is provided with NoScript and AdBlock Plus pre-conﬁgured among several Linux distributions; and most

ARIN members obtain their logical views of the Internet from their upstream Internet service providers and do not seek out uses for the policy book unless a need arises. In these cases, the bundler is responsible for communicating technical advances to end users, and for ensuring that they work reasonably well in the end users’ environments and use cases.

Similarly, plug-ins to Firefox, Apache HTTP Server, or IP routing tables, may update at the users’ choice or automatically, on an individual basis. Unlike the core platforms in which complete new versions may be imposed by bundlers or the project leaders, there’s no hegemonic or monopolistic capability to force users to adopt new versions of plug-ins. Their issuance alone may be the only attempt at communication about new capabilities between shepherds and users; complaints about undesired upcoming changes or enhancements indicated the effectiveness of things other than technical products as vehicles of communication. When enhancements were only communicated for the beneﬁt of shepherds and bureaucrats, users revolted.

In all cases, alternatives to the platforms studied were available, but limited (users can choose other web browsers or web servers, operators can locate some network infrastructure in geographies for which ARIN is not responsible). Innovations from CMA data were drawn from companies which were leaders but were or were not de facto monopolies or standards.

It is unclear if these ﬁndings would be relevant to situations where the platforms or products 146 are closer to being highly substitutable commodities. A guess would be “no” since internal process innovations wouldn’t clearly beneﬁt from information from users about how users further innovate with a standard commodity output.

5.2.4 Theme D. Poorly timed communications results in poor outcomes

Shepherds, stakeholders and potential adopters required time to adequately consider ideas. But any particular idea may require different more or less time to gain those attributes of deﬁnition and understanding. The cases studied have shown that seemingly simple ideas can take a short time to communicate, but a long time to adopt, and vice versa.

Some OEPs prescribed speciﬁc periods of time (ARIN PDP, Apache release voting, Firefox release schedule) to discuss enhancements, so infrastructure could inﬂuence timing and content of broad communications activities. However, details of discussions were not prescribed, and for two of the three OEEs, OEPs could be drawn out forever. ARIN PDP prescribed a timed process during which each formal policy proposal should conclude, but did not limit the period of discussion leading up to a formal policy proposal, nor the amount of re-work that members, the Advisory Council, or the Board may contribute. Although templates were provided to initiate formal proposals, the processes did not enforce clear content or discussion.

Variability in the length of time required to develop or adopt an idea indicated that the changes in the OEEs and/or the external environments allowed or disallowed particular enhancement to succeed at particular times. That a particular enhancement could be rejected and then succeed, or be adopted then be rejected, points to the importance of dynamic internal and external conditions. It was observed that available resources were important timing considerations, as evidenced in the Apache Secure SNI case where both internal (software code) and external (OpenSSL libraries) resources were lacking at different times, or in the Firefox threaded document windows case. Such enhancements were initially postponed for lack of resources and other priorities, and then eventually resumed when conditions changed. The OEPs 147 changed the environment in terms of resources available at different times (e.g., new source code or concepts developed, social capital/support, etc. from previous chapters), and informed the environment of potential new needs. Changes also occurred when decisions are made about whether something is or is not a legitimate new need in a current context. Externally, ideas may have been ahead or behind their times, especially if their potential uses and modes of adoption were not communicated or understood well. IP address allocations (and advanced management techniques) had little value until IP addresses became scarce, secure communications between web browsers and web servers was not needed until malevolent Internet users began to snoop.

During an OEP, ideas and use cases could accumulate to change the substance of the enhancement. As the conduit of both resources and communications, the infrastructure in which an idea existed ultimately sets conditions of if and when an enhancement’s potential resource requirements merited discussion, and how the capabilities it would provide will reach users.

As one of several practical conduits for resources and communications, a structural limit on the timing of communications through ofﬁcial channels did not preclude communication outside the formal process. Simplifying or complicating potential interactions brought about by changes could advance an idea toward adoption.

If infrastructure sets enhancement success, and if the successful progress of all ideas or enhancements through the OEPs were desirable, the infrastructure would be conﬁgured to reliably cause all enhancements to succeed. But not all should. The infrastructures deliberately allowed enhancements to not succeed at multiple opportunities (and were seemingly designed to inhibit or discourage communication about non-successful enhancements), even in ARIN’s

PDP which commits to deliberating each well articulated idea. Thus, while infrastructures provided broad constraints about how enhancements may be described, the infrastructures were not purposefully selective of particular enhancements.

The Bugzilla systems privileged the eldest, not the most articulate, record of each idea.

Clearer articulations (perhaps emphasizing a problem and not an implementation) were ig- 148 nored due to infrastructural procedures to mark duplicates, and enabled some records of poorly articulated ideas to hinder their dependent ideas. ARIN PDP may implicitly privilege ideas from participants with the most experience, related historic knowledge, and perhaps social capital, through its popular elections of potential shepherds to the ARIN Advisory Council.

In cases where OEPs encountered legacy issues, understanding such issues required existing use cases to be communicated into the OEPs. Overcoming legacy issues without supporting previous use cases required agreement on signiﬁcant value gained as a result of adoption which would surpass the cost incurred to eliminate support for the legacy use cases. The ARIN infrastructure which enabled and encouraged shepherds and ideators to consult with end users and stakeholders worked to achieve hange while acceptably upsetting legacy use cases. In contrast, the Firefox infrastructure, which allows changes to originate from and circumvent various parts of its own formal OEP, coped less well with legacy. As an explicit infrastructure project, the Apache HTTP Server OEP placed a high importance on legacy and reserved potentially disruptive changes for punctuated and widely communicated major releases, to the extent that adopters complained about the slow pace of administrative progress on enhancement which had been identiﬁed as being valuable and technically implemented.

In all three OEEs, informing users early was important since all successful enhancement proposed to add to or change the way someone does something (potentially for the worse), and all operated as though stakeholders should generally be given the choice of timing potentially disruptive changes as a result of product enhancements.

5.2.5 Theme E. Poorly timed implementation results in poor outcomes

Just as the time when information was communicated appeared important during the OEP, so appeared the timing of implementation activities. The implementation activities both specified timing, and were specified by timing, as evidenced by the exchanges of information requested and initiated by stakeholders. Implementing an enhancement without having sufficient infor- 149 mation on hand about potential use cases, or without sharing enough information to enable potential adopters to anticipate use cases, resulted in poor outcomes. It is therefore potentially difficult to separate implementation and communication activities, as stated earlier.

The OEEs encouraged contributors to present the problem ﬁrst and took a negative view of code presented ex nilho to solve packaged problems. Other contributors needed to understand the attempted enhancement’s purpose before being able to evaluate whether the code could deliver on its purported capabilities. This is a clear indicator that, among enhancements in development or to be adopted, the ability of others to mentally model using an enhancement was a critical step to adoption, and that this cycle of modeling, adoption, and building needed to be repeated in at each stage of the OEP. No technical change in the form of a product needed to be in hand (although prototypes were helpful) before judgment was passed on whether a prospective enhancement was good or bad. This is evidenced through discussions about potential enhancements, and the OEP itself. The enhancements were thus contained in the communication. This is crucially important since the cases of poor outcomes studied all shared the characteristic that the enhancement itself (which would result in a change to the way users did things)—whether the technical change worked, or not—was not communicated adequately in some way to adopters. Such lack of communication before implementation created a dissonance and ambiguity between use case expectations and reality.

In all three OEEs, the timing of when an enhancement could be made generally available was formally speciﬁed, but actual work timelines were left to individual shepherds, contributors, and bureaucrats in practice. The OEEs were therefore not always internally consistent.

Shepherds could seek input whenever they wanted to, but not all did. Shepherds who sought to follow an inclusive and iterative implementation pattern actively used communication tactics to obtain input. Shepherds who sought exclusives and unresponsive implementation patterns actively used different communication patterns to exclude input. The availability of this choice supports the view that the communication and implementation patterns are conditioned 150 by the information wants of particular shepherds and stakeholders, not necessarily the information needs to generate generally successful enhancements. Further, in releasing software containing particular enhancements, which may or may not reﬂect input from end users, such enhancements themselves were reﬂections of the enhancements for users which were or were not communicated by the artifacts. An artifact which did not meet a user’s desired use case at the time communicated that the enhancement was not available to that user, and vice versa.

Implementation activities could conceivably receive input about speciﬁc use cases from additional sources. Shepherds considered their own and contributed cases when doing the work.

However, implementation activities generally focused on producing an outcome for the general case with particular use cases being accommodated through options and interfaces to be used by the end user, even though such details were communicated into the implementation process in some cases. Implementation which occurred before all this input could be collected resulted in enhancements which were not robust, not adoptable, or insufﬁciently valuable for the cost of the required changes. Enhancements which collected too much diverse input in effect became multiple enhancements with multiple vaguely related purposes co-occupying a single discussion and formal bug number. (Sometimes these spun out into follow-up enhancements as opposed to being incorporated into the main.) There appears to be an optimal middle ground in which the right amount and timing of input about a single enhancement, prior to and during the OEP, becomes a factor for success.

There were no cases observed where an enhancement or intermediate product required the passage of too much time to be adopted and resulted in poor outcomes. Secure SNI came close, but old code intended for an older version was revived in preference to starting from scratch. Work on Firefox threaded document windows ﬁnally began after a long delay in part because project leaders thought performance-related enhancements would not meet particular performance use cases identiﬁed internally and by end users. 151

5.2.6 Theme F. A high rate of non-adoption is to be expected and possibly desirable

From the rare opportunity to examine detailed cases of non-success in OEEs in which participants did not rationalize outcomes post hoc, a number of observations are prudent.

Roughly one-third of the cases of distinct enhancements considered in detail were not cases of adoption. Chapter 3 suggested that it would not be unusual for more than two-thirds of all ideas or enhancements in the OEEs to not progress past each step of the OEP. By far, most efforts applied to OEPs were concerned with handling non-non-adopted ideas rather than adopted ideas. Participation, contributing non-adopted ideas and not new use cases through messages to mailing lists, forums and Bugzillas, was therefore deeply embedded in the communications during an OEP. The communications in OEPs correctly worked in most cases to prevent the adoption of unneeded enhancements.

Enhancements purporting to solve no general problem, or viewed as more costly than valuable, had good reason not to succeed, as their inclusion provided no net beneﬁt to the project or users. The merits of enhancements may be discovered while stakeholders communicated during an OEP. A low adoption rate of individual new ideas is anticipated among widely deployed products (such as web browsers) because such products have many dissimilar uses and because thoroughly thinking through changes to such rich systems requires rare knowledge and effort.

Ideas to improve general purpose platforms should be plentiful due to the variety of further reﬁnements of uses from the general case. By contrast, a higher adoption rate of new ideas (but fewer new ideas in general) would be anticipated for narrowly deployed ARIN policies. Much individual knowledge and experience was required to devise new ideas due to higher barriers to entry, and because the entirety of ARIN is capable of, and intended for, only a narrow range of uses. The innovation in a piece of policy was in how it was understood and applied since there is no authoritative machine (as there is in software) to transform anything.

In the general case, having a pool of ideas on hand, even duplicates, provided a data source somewhat like a polling mechanism, wherein the strength user demands for particular changes 152 may be indicated over time (this occurs in Bugzilla via duplicate reports of particular ideas or bugs). A low rate of adoption could also be beneﬁcial since its public observation and the reasonable expectation of failure lowers the social risk of suggesting new ideas. OEPs providing many routes to discreetly announced non-successful outcomes (Bugzilla statuses) seemed to generate more opportunities for new input (as old input became less discoverable through being marked as inactive). ARIN had fewer routes to non-successful outcomes (all explicitly public), had fewer ideas and participants, but had a high rate of participation in generating ideas among members.

It is institutively very desirable to encourage failures (if they are to occur) to occur early in the OEPs to minimize resources (attention, time) invested in non-viable ideas. With respect to communications, this may be reﬂected in several features of the OEPs. The ﬁrst is the formalism required to get an idea into the formal OEP (implying that the idea source must know the basics about the system which the idea is intended to affect). The second is the initial peer review and categorization process itself, where a contributor familiar with the project has the opportunity to reject an enhancement conceptually or administratively. The third is the implicit competition for time and resources for development during discussion, since many simultane- ous ideas for enhancements may be desirable for different reasons for different stakeholders.

(An observation: good ideas may be acknowledged as such and then sent out of the core OEEs as isolated modules for testing or development before formal inclusion, providing a way to measure potential success and to obtain the capabilities of the enhancement, with minimal resource investment. This scenario was only possible when the idea source was sufﬁciently technically competent to implement the idea, by risking their own time and resources, and when the change proposed did not need to fundamentally modify the core.) Each project itself minimized its own risk through OEPs requiring time for thoughtful consideration of proposals.

As discussed, OEE infrastructures provided many opportunities for ideas to exit OEPs, and even catalogued non-successful enhancements. In all cases studied, participants acted in 153 the belief that, by adopting or not adopting an enhancement, they made the correct and best decision for their OEEs. Even in case of conﬂict about whether an outcome was positive, poor individual enhancement outcomes did not discourage established contributors from continuing on the project, while one-time contributors whose ideas were rejected or not rarely returned for supplemental discussion about the same idea. Thus, for them, their original communication into Bugzilla constituted the enhancement.

Through the OEPs, the variety of paths leading to not adopting an idea, and to initially adopting something that was ultimately rejected, show that the timing of information and consideration is important to success or non-success. Permissible but malicious implementation and communication patterns known to impede OEPs were exploited to temporarily reject enhancements. Even though outcome timing was held mostly constant in the current study, and even though the OEEs themselves attempted to follow consistent internal schedules, the data supported and demanded a more through analysis of operational schedules in future work. The high non-success rate—and the relatively low penalty for most individual failures, along with improvement through iteration—recalls the patterns of a creative arts industry where, for example, mockups and comps are a routine and expected part of professional and industry practice

(e.g., Lee, n.d.). Similar patterns hold in sophisticated engineering design and manufacturing processes where pilot activities are used to shake out problems at low or known risk.

How an idea was communicated initially conditioned how it would be considered and worked on. Failure to communicate an idea well resulted in its non-adoption. Most ideas were not communicated sufﬁciently well on any number of dimensions for consideration; the successful ideas required amendment or clariﬁcation. Ideas for technical changes received technical attention and work, whereas ideas for use case/social changes received social attention and work. Technical ideas dressed in social communication (e.g., the ARIN WHOIS accuracy enhancement), or social ideas dressed in technical communication (e.g., the new Firefox security dialog) tended not to succeed, or to experience OEPs with more communication exchanges. 154

There are many paths to accomplish any specified use case, the route taken depended on how an idea was presented. Narrow ideas communicating only benefits to few use cases should not become enhancements in the general case, and users requesting such inventions were observed to be diverted to configuration or plugin modules which would not have to be imposed (as a source code maintenance or runtime cost) on all users.

Even implemented ideas were not consistently communicated well. The OEEs acknowledged that users routinely fail to ﬁnd documentation about their desired capability, even though the capability existed, as did established support forums to help users with adoption. From the shepherds’ perspectives, it is plausibly desirable for users not to attempt to adopt, at one time, all the features of a product, as providing technical support for such a case would be costly.

For any idea, there were fewer ways to succeed than not at implementation. The pattern of an enhancement was associated with its success or non-success, as shown in Appendix 3

(resources meet or do not meet limits). For any successful idea, questions about perceived limits or potential resource creation may come in and/or be ignored fairly routinely. How the shepherd chose or ignored stakeholder input related to success. Ignoring collaborators or more senior contributors did not result in successful enhancement outcomes. Ignoring duties as a bureaucrat can stunt OEPs. Ignorance of user inputs or formal processes or not may lead to a change which attempts to do too much, or to do not enough (costs outweigh potential beneﬁts).

5.2.7 Theme G. Lack of internal and external iteration results in poor outcomes

Ideas changed and were changed in modestly different ways as they were communicated through the OEP. Iterating through ideas, use cases and implementations, of whatever scale, appeared important to the success of OEPs, and the lack of iteration appeared to result in non- success. This is not a surprise since prototyping is a well-used process, but it did illustrate the importance of effective communication about the intermediate versions.

Under preferred circumstances, Firefox integrated enhancements demanded by prospective 155 users to increase adoption to gain more income (via Google searches). Ideas for new enhancements were communicated through an explicit array of formally stated bureaucratic processes, and milestones along broader plans. Ideas to enhance existing parts of Firefox might receive much less attention. In either case, the availability of, or need for, use case and other information was a consequence of contributors working on an implementation. By contrast, the

Apache HTTP Server project released new versions when warranted by accumulation of sufﬁ- cient changes to minimize disruption to its users. Ideas were judged and integrated by Apache

HTTP Server developers on the basis of quality and testing since the projects lacks an explicit

ﬁnancial incentive to increase adoption. This provides substantial contrast between the two projects with respect to how they ingest and iterate ideas in their OEPs.

The projects’ views of shepherds were indicated by how new ideas were expected to be presented and communicated. For example, Apache HTTP Server’s external log rotation trigger and non-secure SNI, Firefox’s “Home” button relocation, and ARIN’s historic WHOIS information database, all started out as descriptions or implementations of relatively minor technical changes. After explaining that the idea would require changes contained to discreet known bounds and having isolated potential effects (and all use cases considered), it was relatively easy to justify the changes in order to accomplish speciﬁc new behaviour in the platform as envisioned from within the platform’s own perspective. However, changes presented by shepherds to enable the platforms to do new things from external perspectives (by third parties) were communicated as unﬁnished concepts seeking potential users of the changes proposed.

For example, Firefox’s security dialog revisions underwent extensive iteration prior to attempts at implementation. Overall, changes without much iteration could be described as changes with little immediate potential effect (merely incremental), while changes which involved much iteration and much envisioned potential effects (beneﬁts) for users would more comfortably be described as attempts at enhancements in a more profound (radical) sense.

The internal portion of these observations reafﬁrm previous ﬁndings in the literature. Moe- 156 naert and Deschoolmeester (1992) found that within companies where marketing and engineering functional groups both participated in the innovation process, the effectiveness of their communications was related to particular message attributes: familiarity, surprise, recency, project relatedness, actionability, timeliness, contextuality, validity, technical understandabil- ity, completeness, synthesis, clarity and accuracy. Such attributes informed how stakeholders hearing about a new idea would judge the new idea’s usefulness.

Iteration, then, would appear to be key feature of successful OEPs.

But would lack of iteration necessarily lead to non-success?

Superﬁcially, lack of iteration would indicate that the idea has not been situated (conceptually or mechanically) where the user could use it, and therefore the idea would not become an enhancement because it would not have changed the way that anyone does anything.

More substantially, the opportunity to contribute to an enhancement is necessary, but not sufﬁcient, for an enhancement to be adopted. The evidence for this is clear, in that there is no technical or social expectation that each of the dozens of millions of users of the Open

Source software studied obtain and compile their own custom version of the software, nor do all custom versions succeed. (The technical and knowledge requirements for each user to compile the software are somewhat steep even if the starting materials are available at no

ﬁnancial cost. This method of software use and adoption is not emphasized by either of the software projects studied, whereas download and install was emphasized.) What is observed is that the adoption or customization to the local usage environment by each user occurs through augmentation of the software through third-party modules. Even where the technical options exists to customize the software, it must be communicated that the option exists to adapt and customize in those ways (as shown by many questions about conﬁguration on the support lists).

Iteration recognizes that contribution of an ideas alone is not sufﬁcient for it to be adopted.

The data showed that many suggestions were contributed to each OEE, but few were adopted.

On its own, a project rejecting a user’s idea did not render the product any less functional for 157 the user than prior to the suggestions being made. Nor did rejecting an idea render the rest of the OEE more or less readily adoptable for the user. Communication of prospective use cases was necessary, but insufﬁcient, to communicate an enhancement through to the end to a user as alternative. Consideration and adoption of prospective use cases was both necessary and sufﬁcient to get an idea approved in some intermediate stages.

Recall that a use case essentially describes how a capability might be employed by a user to achieve their desired outcome.

”The system is described [by] a number of... behaviourally related sequence[s]

called use cases... A use case is a special sequence of transactions, performed by

a user and a system in a dialogue. A transaction is performed by either the user or

the system and is a response initiated by a stimulus.” (Jacobson, 1987)

Iteration, then, helps both users and shepherds understand and define the capabilities desired from enhancements. The contribution of intermediate work (prototypes, design outlines, prospective use cases) supporting desired capabilities indicates the viability of the idea to that point, as well as the willingness of an shepherd to lead in taking a risk. In both cases of successful and non-successful enhancements, expression of support through a work contribution enabled supporters to follow a leader rather than being the first to prospectively adopt a new idea. This also enabled other use cases to be brought to the fore. The data also showed that it was possible for an entrepreneur to abuse the benefits of perceived risk-taking by creating a more or less complete enhancement which had features of having gone through a few iterations, with different degrees of success. Iterations seemed very useful for receiving user input about use cases, but (by example of non-secure SNI and Firefox “Home” button cases) are not strictly necessary to get an idea to a particular stage of an OEP. Iteration, or its circumvention, provided no guarantee of ultimate success. This matches expectations from Nonaka and

Takeuchi (1995) in which ideas and development must explore the area around, and converge 158 on an implementation goal and gain knowledge, without drifting toward undesired directions.

5.2.8 Theme H. Enhancements which are not communicated as fulﬁlling their use cases do

not succeed

Finally, we return to the most basic interpretation of the data: Enhancements that are not communicated as able to provide capabilities sought by potential adopters, will not succeed. 1

Needs arise from the intersection of those use cases deﬁned by the shepherd and the adopter.

Communication of use cases is central to the OEP. All of the enhancements which experienced non-successful intermediate or terminal outcomes shared the feature that the capabilities communicated, and the capabilities sought, did not match. Of such enhancements studied, there was no urgency to approving Apache HTTP Server’s new log rotation trigger since users could already manage their log ﬁles using less elegant but working solutions. Similarly, support for

SNI was not a capability users could request until their browsers also supported that feature.

Firefox’s security dialogs required years to ﬁnish because neither the users’ vision of desired capabilities, nor the shepherds’ vision of capabilities which were feasible to provide were clear.

Moving the Firefox “Home” button fulﬁlled the shepherds’ needs by adding capabilities for the shepherds, but did not add any desired capabilities for any user (and in fact, removed capabilities). Firefox could not gain threaded document windows because the shepherd believed that the capabilities sought by the users (make errors not catastrophic) was already present. And

ARIN could not take away perceived legal rights (potential capabilities) of some non-members under the guise of enhancing its own data management capabilities for its members. The en-

1Again, this should not be the default or obvious conclusion since non-open enhancement environments have shown that enhancements that do not communicate the use cases they fulfill, or that fulfill their use cases poorly nonetheless succeed by some criteria. For example, Microsoft’s Internet Explorer browser was and is provided at no cost to users of its operating system, and has succeeded locking in corporate users to Microsoft’s broader product stack, while at the same time its many unneeded features have enabled users to easily make poor and costly decisions about computer hygiene. On the Internet in general, there are countless examples of benevolent and malicious uses of enhancements in ways which were not communicated or intended. Whether this, and previous apparent exceptions to Theory 1 about communicating enhancements differentiate open from non-open enhancement environments is left for future work. 159 hancement is embodied in communication about how it could fulfill (or impede) use cases.

5.3 Summary

Enhancements are therefore bi-directional processes, and not strictly limited to artifacts or changes in individual conduct. Norman (1988, pg. 47) renders a broader process—“seven stages of action”—in which human goals trigger intentions and actions on the environment, which feedback is then observed and evaluated (in this case, only through CMC) for outcomes which correspond with original goals. Shepherds needed to know potential adopters’ about use cases in order to build enhancements to exercise desired capabilities. That particular enhancements may both be adopted and rejected by the same group of potential adopters, under different circumstances or communicated differently, implies that implementation and communication about those circumstances must be tightly linked. That some ideas were only adopted after years of being known demonstrate that the choice to adopt enhancements rests strongly in the communication of ideas and use cases, and not in the not as yet existing or adopted artifacts.

Enhancements suggesting a specific way to achieve a particular outcome were communicated differently than enhancements simply offering new capabilities on which users must further innovate. With a prototype specified (recall the Firefox “Home” button relocation and non-secure SNI examples), the observed use of communicating an invention was to gain specific narrow functionality under moderate risk and investment for the shepherd. Where the details of specific use cases were outside the scope of the project (recall the Apache HTTP

Server log rotation and historic ARIN WHOIS examples), the appeal was proposed benefit to users’ future third-party enhancements. Where external use cases were claimed to have been considered in the design of the invention (e.g., first ARIN WHOIS contact information accuracy), the appeal was to meeting demonstrated market demands. Where input with respect to further use cases are specifically sought for the incomplete enhancement, the appeal was to a 160 community spirit of cooperation to further philosophical and operational objectives (recall the changes to the Firefox security dialog).

With just the idea of an enhancement communicated from the outset, (recall the Apache secure SNI, the second ARIN WHOIS contact information accuracy policy proposal, and the multi-threaded Firefox cases) the appeal was more strongly one of asking the platform to take a risk to advance toward a new or substantially altered paradigm of how the platform should relate in general to broader things around it, for substantial global benefit. Specific use cases were cited, but their collective benefit from non-specifiable new kinds of use were the main selling point.

The external information and third-party use cases which were brought into the communications around such enhancements were necessarily broader in scope and from a more ex- pansive base of users than ideas or enhancement which only sought to change details around the platform and its immediate third-party system of modules. Firefox’s popularity is due in part to its ecosystem of plug-ins which adapt the browser to many individual users’ use cases.

Even when the software product comes to meet its users needs and original design goals, the software could continue to gain new features as its developers try to maintain and expand the attention of the product’s users. Apache is more conservative in this regard, in that new features are by default not made immediately available to users.

Thus, implementation and communication are highly linked to each other during the OEP, and to the success of the OEP. However, infrastructure enables, but does not determine, enhancement success. As observed, enhancement patterns inﬂuence communication patterns and are inﬂuenced by communication patterns. But not all enhancements in the same OEEs succeed. The non-successful cases showed that—all else being equal—at each phase poor implementation patterns or poor communication patterns resulted in poor enhancement outcomes.

The inﬂuences therefore appear holistic, in that each phase of the OEP is necessary but insuf-

ﬁcient to the overall process. Backtracking, each genuinely successful enhancement outcome 161 was enabled by a previous successful enhancement outcome and a history of cooperative iteration and communication considering use cases. Each falsely successful or non-successful enhancement traversed at least one phase in which use cases were considered, but not met due to technical or plausibly personal and political concerns. ARIN’s scheduled PDP workﬂow prevented individuals in process from scuttling an idea through communication, unlike Firefox or Apache, but yet produced rejected enhancements which later became successes.

The data show that an iterative enhancement process in which communication and implementation are responsive to both internal and external use cases is essential to successful enhancement outcomes. Formal structures undoubtedly facilitate these interactions, but do not appear to shape the outcomes of the human processes required to achieve successful enhancements.

The ﬁnal chapter examines how this knowledge might be used in future work. 162

Chapter 6

CONCLUSIONS AND LIMITATIONS

This thesis has examined shepherds’ actions and expressions before, during and after open enhancement processes, their methods, challenges and objectives. The non-success of enhancements can be predicted through three related indicators: poor communication, poor participation, and poor consideration. Participants used the same information for work as researchers would use for study. How does that knowledge inform possible improvements to theories of innovation, or indicate better study open enhancement environments?

Chapter 4 outlined the features of successful and non-successful OEPs, concurring with

Chapter 3 that participation of stakeholders is key. Chapter 4 also indicated that participation in OEPs must come via communicating about how enhancements are to be used by potential adopters. 1 Together, these ﬁndings tell us that the patterns of success or non-success of enhancements are not particularly complicated, as partially theorized in the previous chapter. They also reveal some considerations for studying OEEs as highlighted en route through

Chapter 4, and as discussed in the present chapter.

6.1 Some plausible patterns for communicating enhancement processes

This section outlines plausible patterns for studying or participating in OEEs based on ﬁndings summarised in Chapter 5 in the context of structural features of the OEEs developed in Chapter

4. It also highlights signiﬁcant limitations and advantages of the research methods employed.

1Appendix C outlines some very simple relationships between the inputs of an enhancement or innovation process and the outputs, agreeing with Chapter 4 that enhancements must meet multi-faceted needs to succeed. Ap- pendix C also shows that the OEE enhancements studied in depth are not very different from broader innovations. 163

6.1.1 Rule 1. Communication must be appropriate to the enhancement it communicates at

each phase

An OEP is not just an interactive period occurring where individual consumers and shepherds meet, but a potentially orchestrated and purposeful series of roles occupied by both shepherds and consumers to understand and provide a capability. The current research has deﬁned clear circumstances and parameters in which individuals occupying particular roles in the OEP— shepherd, stakeholder, bureaucrat, user—can communicate their activities, perspectives and information into an OEP. Not just that, particular kinds of enhancement—technical inventions, new concepts, and new understandings about use cases, etc.—tend to draw particular kinds of implementation activity and associated communications patterns. Some kinds of activities and associated communications are more effective at getting ideas through the OEP than others.

Understanding ways to guide OEPs toward desired successful outcomes (or away from undesired outcomes) through cooperation may provide inputs into critiques of analogues like policy stages theory (as reviewed by Smith and Larimer, 2009, pp. 29–31) in which stakeholders, issues, and interests are even more varied than policy made in software. No apparent generic methods emerged applying to all kinds of enhancements, but strategies for communication and for study may be devised by taking the above into account and avoiding conditions leading to non-success.

6.1.2 Rule 2. Communication must embody the enhancement it communicates

Having isolated OEPs in which particular parts of the OEP are altered or absent, each of several deﬁciencies would independently cause non-success: lack of procedural support from a project’s leaders; inadequate adherence to community policy; and the lack of reﬂexivity to adopter input through inadequate consideration of internal or external use cases. Therefore, how a process reaches each phase through communication is as important as reaching the phase itself. 164

The most economically (in the broader scope of resource usage) productive form of communication for knowledge building occurs through two-way exchanges of information in a repeating stimulus-response cycle (Cherry, 1966, pg. 17) among representatives of all kinds of participants and stakeholders. Attempts at generally one-way broadcasts with all stakeholders, such as to the dozens of individuals who subscribe to bugs, or to the hundreds who subscribe to mailing lists, was neither sufﬁcient nor necessary for successful enhancements.

ARIN PDP infrastructure was set up to collect input, but not structured input, during discussions. However, the participants nonetheless converged on similar iterative cycles to those of Apache’s and Firefox’s Bugzillas to repeatedly clarify ideas and needs. Even though they were implementing policy (not software), ARIN PDP participants chose to have highly technical discussions, volleyed use cases, and produced work in a structured incremental manner

(instead of discussing only philosophic or political dimensions and leaving the technical discussion to the implementing bureaucrats), whereas such activities were built in to the software

OEPs. The choice recognizes a perceived advantage or optimum to this pattern of OEP. As expected, both participants and researchers depend on tacit and explicit knowledge in OEEs to identify and interact with relevant communication items, but face the unexpected challenge of having to locate particular items of data in supposedly open systems.

6.1.3 Rule 3. Shepherds and adopters must agree on the concept of an enhancement

Some enhancements were initially not successful, and then succeeded, while others initially succeed, and then were rejected, suggesting the difference between success and non-success comes from process, implementation, and context. Enhancements which received input from very few particular individuals (due to apathy or bureaucratic shenanigans) seemed to proceed slowly or did not succeed. This implies that OEPs did not choose an arbitrary order, but ended up using something resembling a required order. Enhancements which deviated tended not to succeed, regardless of the point of departure. Focusing events—such as criticism of the 165 process or the revelation of external information which brought together different perspectives or capabilities—were observed to unstick OEPs.

As an example, Apache HTTP Server bureaucrats only relented to accepting outside help to implement secure SNI when their administrative negligence was pointed out. Through

Google’s release of its Chrome browser, Mozilla was forced to tacitly acknowledge its performance deﬁciency and to enhance its Firefox browser to meet the new performance expectations thus set by Google. ARIN’s goal of having accurate WHOIS records was initially defeated when legacy resource holders on the periphery complained about being potentially forced into legal agreements under duress. Focusing events also occurred when shepherds changed.

Again, these ﬁndings about the need to communicate clearly about new concepts ought not to be surprising. But also again, having complete access to archives of previous communication items does not provide consistent beneﬁt to participating in or learning about open enhancement processes.

6.1.4 Summary

Adoption requires a user to invent or modify an existing or prospective use case to receive the beneﬁts of new capabilities. There are obvious advantages to sensitizing OEPs to such use cases at each stage of OEPs before investing in more complicated work. Regardless of the presence or lack of technical content, enhancements which expressed and encouraged the idea of expanding the number of accessible use cases tended to succeed. Enhancements which effectively contracted the number of accessible use cases had a harder time. The individual case studies identiﬁed examples of corrective measures to reverse potential non-success, and also to prevent subjectively undesired enhancements from succeeding. These points should be obvious from the perspective of end users adopting innovations. However, this present thesis has found that the communications about how an enhancement meets use cases, and the many intermediate adoptions of an idea, are relatively simple, yet relatively easy to guide or subvert. 166

Organizational plans should therefore take these communication needs into account with respect to ensuring their communications interfaces in OEPs support the interactions described above.

6.2 Warnings

The most important interpretative warning is as follows. This thesis has focused its attention on non-successes more than successes. It has shown that the vast majority of ideas entering the

OEEs are not implemented, and it has highlighted several potentially unﬂattering ways in which ideas do not progress in OEPs. But it must be recalled that by almost any standard of success, the OEEs studied have yielded outcomes useful to many millions of individuals world-wide.

The OEEs’ models and assumptions tend to succeed in bringing ideas to beneﬁcial fruition most of the time, and most of the OEEs’ original creative content, from ideas to features, come from stakeholder communities.

6.2.1 Validity and reliability

Krippendorff (1980) divides validity of content analysis studies into several types: Internal validity (reliability) that the ﬁndings relate to the data; external validity that the ﬁndings in the subset of the universe studied relate to the whole universe; semantic validity that the analysis has collected and interpreted symbols in the same way as the participants in context; sampling validity that the subset studied fairly represent the whole (the cases chosen herein were deliberately non-representative); pragmatic validity that the method works under a variety of circumstances; correlation validity that independent methods on the same data produce the same inferences; predictive validity that facts match those inferred; and process-oriented validity that the analytic model matches the relations it studies.

On internal validity, this research employed data largely in the mechanical, temporal and 167 conceptual forms employed by the participants in the OEEs studied, and used the participants’ actions and categorizations as indicators. Identifying how successful or non-successful enhancements could be reversed focused attention on the small number of relevant phenomena and their indicators.

On external and sampling validity, the OEEs studied are similar in that they employ open processes to develop ideas, but differed in scope, organization type and resources, as detailed in Chapter 3. Among the organizations studied extensively were a not-for-proﬁt organization, a for-proﬁt organization, and a quasi-governmental organization, along with several efforts headed by individuals or small groups. Among the OEPs studied were processes involving single and pairs of individuals, small groups, and large groups, with minor optional potential effects on few knowledgeable stakeholders, through to major compulsory effects affecting hundreds of millions of end users. The OEPs studied are not known to be representative of the distribution of innovation processes from the whole universe of innovations, nor of processes involving Internet technologies, but they do arise from a large range of strata. Chapter

4 addressed sampling and bias in detail.

On semantic validity, the largest gap between the indicators and the participants’ views was the categorization of OEE structures and formal processes into the traditional governance branches which the participants did not do2. In all other respects, the explicitly terse and functional nature of the norms of the mailing lists and Bugzillas (and the fact that one of their intended uses is to enable interested readers to understand the projects’ development processes) minimized the opportunity for analysis to interpret symbols in the communication pieces differently from the participants. In addition, the present analytic interpretations of the communication items was readily conﬁrmed since many of the communications generated by participants on the mailing lists and Bugzillas were explicitly interpreted and explicitly responded to by other participants.

2 likewise the classiﬁcation of motives, limits, resources, etc. into artiﬁcial industrial, social and intellectual categories (Appendix C) 168

On pragmatic validity, methods used in this thesis generated consistent and useful results on formal data sources documenting OEPs, but encountered slight difﬁculty with respect to systematically identifying relevant adjunct conversations in unofﬁcial channels. Similar records of organizations which need not rely on mailing lists and Bugzillas to overcome geographic limitations may or may not be amenable to content analysis as deployed presently. The limited ARIN meeting transcripts studied suggest that in person interactions communicate less information about OEPs than the on-line records of CMC. It would be possible to explore this question in future via other meeting transcripts and recordings, such as those public records generated by the Mozilla Corporation at their physical corporate headquarters, or transcripts of the Apache conferences. In addition, since ARIN counterparts for other geographic zones employ very similar procedures as ARIN with respect to public deliberations about policy, it would be possible to further test pragmatic and other validity of the framework and methods employed herein. The present type of study should also be readily reproducible for other Open

Source and civic organizations, and plausibly in corporate environments where similar CMC documentation and communication standards are also employed. Any data arising from such environments should be comparable, while compliance with standards may not be as well en- forced. However, while case studies of working documents by multiple authors are like stories and narratives, it is unclear if they embed the same kinds of information about values as are available in a pre-meditated or familiar ﬁrst person narrative. It is unknowable who else read or was informed by the mailing list messages or Bugzillas, nor how access to such information would affect future OEPs. Such ambient information gathering by participants was important in the example of Apache logs.

On correlation validity, Chapters 3–4 showed three different approaches arriving at the same conclusions: that stakeholder communication is crucial to the OEPs; that ideas have more opportunities to fail than to succeed; that success requires more than just making an idea or invention available; and that enhancements are substantially not contained in the technical 169 details. Chapter 43 added that enhancements and innovations must meet user needs to succeed

(Chapter 3 did not examine this part of the problem). These ﬁndings generally agree with innovation literature that adoption occurs to satisfy perceived needs at acceptable costs.

On predictive validity, the data appears clear that failure to communicate about an enhancement with stakeholders consistently results in non-successful but reversible outcomes. The cases studied, selected for their probable extreme deviances from the usual cases, also suggests that entrepreneurs communicate their ideas in different ways based on their perceptions of the scope of their proposed changes. However, more examples would be required to estimate how much of an effect communication has on success in the more usual cases.

On process-oriented validity, the overall model attempted to relate elements reflecting their modeled configuration: OEEs provide an infrastructure in which persons contribute and work on ideas to produce or enhance a product which benefits a broader community. The content analysis took the same perspective as interested stakeholders (not as full participants) and observed records of interactions among individuals and institutions in the same manner as the organizations intended to present their processes to their participants and the public. However, the present study did not systematically pursue unofficial information sources and communications pertaining to particular innovation processes, even though a particular case showed that it was possible and informative to do so. Limited study of relatively smaller Firefox and Apache add-on projects shows their idea sources and overall enhancement outputs generally resemble those of larger projects. While it is possible that such projects would employ radical OEPs and more extensive unofficial or undocumented communications, they consistently produce the same kinds and rates of observable results as those projects studied in detail. Thus, the communication channels recommended by the organizations (mailing lists and Bugzillas) provided sufficient, if not comprehensive, data sources to study the phenomena at hand. In addition, this present analysis has employed a more analytic perspective, via background and related

3 and Appendix C 170 literature about innovation and human interaction, than would be used by general stakeholders.

Stepping away from the content analysis itself, Barringer et al. (2005) raised two kinds of concerns about the validity of inferences obtained from post-hoc narrative data: structure and scope of the data source with respect to representing the phenomena we seek to study, and a possible self-desirability bias in self reported actions and requests communicated.

First, success of innovations was externally conﬁrmed through public third-party sources.

Data were also found within the working documents and discussions about OEE enhancements, while conﬁrmation of success came in the form of changes to products, new and amended policies, product documentation and literature, and third-parties reporting about the enhancements.

Second, some public working documents and communications were self-promotional (of the enhancement, project, or product) so there was the clear potential for self-desirability bias.

Alexander’s principals of salience were expected to bring information perceived by informants to be the most important to the forefront (1988), since individuals are likely to report truthfully on retrospective events which are salient (Nisbett and Wilson, 1977). (If an informant misin- formed about the importance of a feature by bringing it to the front, the informant’s perception or belief remains that that feature is, was, or should be important to the system surrounding the informant’s innovation.) In all cases, the features being compared, as described in the data, are the most important features (to the informants) relevant to their innovations at the time of the narrative.

The OEE data did not suffer from incomplete recall, with the exception of data gathered from marketing materials which likely had these, and other issues.

Even though counting provided an important and valuable tool informing the present research, it must be recalled that the quantitative coding was not the deciding basis of the conclusions drawn. Quantification simply provided a hint about where in the rich data to look, and confirmed that observations made of the qualitative data are in the correct direction. This research was not intended to generate a standalone mathematical model with which to turn cre- 171 ativity into an exact science. Its methods and findings supplement other tools and knowledge already used in the decision-making and evaluation processes with another perspective offering complimentary supporting or opposing evidence.

6.2.2 Further assumptions and limitations

This study examined several processes and features of OEPs with public data about the structural, technical and communicative features and transactions of the OEEs studied, as a proxy for more general innovation processes. And it attempted to ﬁnd evidence of explicit social lubricants for the innovation process, but such did not occur frequently. The reports studied were of public actions and public expressions of values and information, rather than of private internal thought processes or the beliefs guiding them.

It also examined the outcomes of parts of OEPs, to the extent that enhancements and adoption were considered only up to the point that new widgets became available to the public.

Although it detected adoption and complaints from end users, it did not generally consider data about consumer adoption, marketing, or the OEE’s support of further user innovations.

6.2.3 Assumptions

This work only employed information readily available at the periphery and target groups (Naz- manian, 1983) of the OEEs. Several assumptions of the current research were stated in Chapter

2. Even though the data recorded decisions, actions, and public rationales of individuals central to the organizations and projects studied, the data did not include the organizations’ broader plans and other strategic or tactical documents which doubtlessly informed leaders’ decisions.

(Participants’ application of such documents would hopefully be constant across all innovation processes within each organization, but the observed obvious violations of procedural policy in both Apache and Mozilla puts that hope in doubt.) Since such documents are openly available, it would be possible in future work to consider their effects in detail. More deeply embedding 172 the analyst within the participant community would provide better awareness of how enhancements are communicated via secondary venues of communication such as chat rooms, blogs, and other venues.

The present analytic view assumed that bureaucrats, contributors, stakeholders, and users played static roles through time. However, personal and project relationships are much more complicated since individuals occupy different roles in different contexts, and individuals were observed to refer to individuals’ other past and present roles. This work assumed that each piece of communication arises from one clear role only, but as disclaimers about hats in ARIN messages showed, this is not always clear among participants. Indeed, a compelling alternative avenue of investigation could attribute some non-successful enhancement outcomes observed to conﬂicts in perspective about stakeholders’ roles in the OEEs. Interfaces and past behaviours may create unmet expectations that stakeholders would respond in particular ways.

It was assumed at the outset that all three OEEs took a consistent (and irrelevant to OEPs) notion of profit as a motivator to pursue enhancements. Implicitly, other indicators of success such as the number of users and the breadth of capabilities, not monetary gain, would indicate success. The profit motive was not observed to trickle into individual OEP discussions, in general. However, in the case of the ARIN WHOIS integrity discussion, financial resources were discussed with respect to their provision of services for a fee. An Apache leader explicitly denounced the idea of speeding up an OEP via external monetary resources.

Firefox contributors worried about competitive pressure from Google’s Chrome, adoption of which could deprive Mozilla of some commissions earned through its search box. Therefore,

financial motives condition all three not explicitly profitable organizations in ways which have not been meaningfully taken into account by the present model. Similarly, outside the current model, Apache faces (and provides) competition for its HTTP Server through other web server platforms, ARIN competes with other Regional Internet Registries for influence in global In- ternet regulatory affairs at Internet Corporation for Assigned Names and Numbers and Internet 173

Assigned Numbers Authority, and for technical and procedural excellence.

The present research took advantage of commonalities of all three OEEs through very similar high-level ideals about infrastructure and operations, but which had differing implementations on the ground. Selecting environments which were similar (constant) enabled differences to potentially manifest as different OEP patterns. Even though the structural differences did not appear to affect work on enhancements or communication, this research pattern enabled those differences to be tested. Doing so may have also unintentionally focused attention on mechanisms of interaction which are designed into the CMC interfaces and system models, rather than other patterns on which the participants may otherwise have freely agreed.

There is another disadvantage. The study is internally consistent in that it considered ideas which were adopted in substantially the same time period. However, that forced it to assume that that the time period studied is representative in general for all three OEEs, and that they have all changed in comparable ways (if at all) during the study period. Clearly, this cannot be the case. To the extent that all three organizations are part of a common technological environment, some factors undoubtedly affect them all in common, such as increased usage and demand for web-based services. However, it cannot be assumed that they are all being inﬂuenced in the same way, nor that they did not inﬂuence each other. ARIN is unlikely to be driving demand for web browser advancements, but scarcity of IP number resources clearly drove the Apache SNI enhancements. As observed from its ecosystem of plugin modules,

Firefox is conﬂicted about how to support new kinds of interactive and advertising content, by both enhancing performance to cope with more technically demanding web content, and also permitting tools blocking access to the same content. In addition, such tools act against on-line advertisers who stimulate demand for high performance managed web server platforms such as those developed by Apache (which its log rotation trigger supports), and also demand for In- ternet Number Resources allocated by ARIN. ARIN, meanwhile, enacted a policy to stimulate demand for IP addresses in the Caribbean region, and simutaneously enacted measures to cope 174 with poor IP address allocation and tracking policies in the past which have resulted in a short- age of available IP addresses to be allocated, etc. In short, while the present research provides tools to evaluate or possibly predict the success of particular OEPs, and while such processes may be common across the OEEs studied, it could not provide direct or interactive access to the tacit elements and relationships around the OEEs. The framework has assumed that relevant factors of motivation are constant or irrelevant, but the data also showed that (not strictly rational) personal and group motives were associated with procedural success and impediment.

6.2.4 Limitations

Besides the irrational actor limitation, a number of procedural limits should be noted.

None of the categories of variables examined in the study are holistic or systematic. Each attribute of the OEPs was taken from a narrow perspective of working through particular enhancements.

Participants in both software and policy development can make objective, rational decisions about individual potential enhancements, and they sought data to do so. But in both environments, some consequences of decisions could not be correctly anticipated, and some data was not easily available. In Firefox, logical reasoning and supporting data did not necessarily stop the pursuit of bad ideas (recall the “Home” button relocation), nor necessarily aid good ones

(threaded document windows). Source code is both veriﬁable, and falsifyable, which should facilitate objective discussions and decisions about courses of action. However, some changes were judged to be good or bad based on aesthetic, personal and political considerations, rather than based on technical data and merits. Individuals from a diversity of industrial and technical backgrounds contributed judgments and decisions to all three OEEs; judgements based on architectural, equitable, or efﬁciency merits were overridden by values and symbols. Also, social pressure was applied to support detrimental decisions, which even overcame the judgment of project leaders at times. 175

Finally, the present research focused only on the technical process of bringing ideas to fruition, and on neither the market research which may inform product or organization plans, nor the subsequent marketing activities. Since formal and informal marketing research seeks to understand consumer needs (beyond those which are easily articulated as use cases for technical functionality) and informs both strategic plans and users’ perceptions of the role of technical products and organizations, information about marketing and advertising, etc. should be considered with respect to their roles in deﬁning prospective user needs and use cases. Indeed, if enhancements and innovations are communicated primarily through words and not artifacts, this present research has been blind to a great deal of such data about innovations being communicated to potential consumers.

6.3 Gaps ﬁlled

Returning to the motivating knowledge gaps identiﬁed in Chapter 1, we have learned two groups things.

The first is a method to comprehensively explore communications during an innovation process beyond those indicated by explicit inputs and outcomes. The exploration required identifying and categorizing relevant data that had not been easily quantified previously, but doing so identified the ranges of stakeholders and types of communication involved in OEPs.

The research also used examples in which different types of innovation were communicated differently to show that the choice of communication tactic strongly inﬂuence success or failure of enhancements.

The second learning arises from identifying, and in some cases disregarding, several structural factors of innovation. Chapter 3 found that no obvious factors of the OEEs inﬂuenced outcomes as much as how individuals participated. While we have known for some time that transacting technological knowledge was important to innovation for producers, this research 176 has illustrated in important complement in the form of (potential) adopters who share similar knowledge. These ﬁndings in concert further complete our understanding of the role of consumers in innovation, but also raise questions about the effectiveness of innovation policies that primarily stimulate producer innovation infrastructure.

6.4 Future work

The data and indicators used were explored qualitatively with respect to particular enhancements, but are amenable to more quantitative analyses regarding how particular individuals carry out OEPs at OEEs—or within particular projects or modules—over time. In addition, the data may be explored to understand the effectiveness of individuals formally responsible for guiding enhancements at the OEEs, as well as the communication styles of individuals responsible for particular kinds of enhancement. The quantitative aspects of the OEPs counted (ideas, characterizing innovation outputs, and timing of information and work contributed) represent only a fraction of the total number of variables available and encountered in the present research

(some possible additional aspects of the source texts to quantify were outlined in section 7.2.7).

No doubt, the present work does not adequately characterize the motives of participants, or to comprehensively explain how or why some shepherds choose to take enhancements outside of formal processes.

In addition, each of the quantitative components characterized here deserves detailed examination, if they are to be manipulated reliably as a tool to support OEPs. Chapter 5 demonstrated one potential method to understand more about how different kinds of innovation may be grounded in terms of needs and capabilities, but this work as a whole did not identify how communication styles may relate to that grounding.

Identifying the external/internal boundary in roles and responsibilities during OEPs as characteristics of the participants would provide opportunity to examine the scope of participation, 177 or the “community”, as a relevant unit of analysis. Although the present research identiﬁed the multi-dimensionality of shepherds and stakeholders within individual OEPs and within OEEs, the data did not examine personal aptitudes, attitudes or preferences in shaping their participation. It is likely that maintaining will, expertise, and authority to volunteer must arise out of some combination of individual factors related to conditions of the OEEs.

Within the best case scenarios studied herein for electronic democracy systems, the ”electronic” nature of the communications provided new ways to organize stakeholders and their goals, but it did not do so as a modiﬁer to concepts relating to democracy as the project charters might envisage. Enhancing democratic decision-making with CMC did not produce a phenomena unique from democratic decision-making in most respects (as evidenced in Chap- ter 3), and was contrary to democratic decision-making in some cases highlighted in Chapter

5. CMC-based decision-making is at most an inconsequential incremental innovation to democratic decision-making (if it must supplement such systems at all).

Despite enthusiasm for enabling willing and able participants to contribute via Web 2.0

ICTs, this latest thinking about Deliberative-Collaborative e-Democracy (Petrik, 2010) and the like remain trapped in viewing large problems of human organization through the lens of the democratic (protocol) state (agenda) as the primary provider (source) of governance, organizations, and resources (data). However, the substrate for CMCpresently the mostly ﬂat Internet— is by design indifferent to who uses which protocols to communicate what data to whomever else under whichever agenda. CMC is instead a radical innovation providing a decision-making tool alongside the forms demonstrated by democratic governance. This paper has shown that some traditional indicators of good decision-making—such as participation, sustainability, and impact (e.g., Chadwick, 2008)—fail to show that CMC as a democratic method of organization is effective in accomplishing inclusive, resilient, and responsive decision-making outcomes of human organization that democratic indicators sought to measure. However, through other indicators, CMC was shown to enable the efforts of small numbers of collaborators, using min- 178 imal capital resources, to successfully understand and meet needs of very large numbers of stakeholders worldwide in very complex technological systems.

This work contributes to both innovation and policy analysis a method to operationalize the essential concepts—objectives, actions and outcomes—in a manner which relates input communications to effectiveness of implementation and outcomes. Unlike policy studies alone, which have experienced difﬁculty systematizing the study and developing theory round the contents of case studies of policy development and implementation (Smith and Larimer, 2009), this work understands policy development on the same terms as industrial product development in which policy is explicitly embedded in technical products. Therefore, this work contributes also a starting point from which to understand deliberative decision-making with respect to policy areas that transcend geographic considerations.

6.5 Final conclusions

This research originally tried to link communication to outcomes of innovation processes. This goal was focused on communication being the central feature of the open enhancement process.

It turns out that the premise was reasonably useful, if not entirely comprehensive. Communica- tion is more than the link between ideas, inventions, technical changes, and something to use.

This work has found that the innovation itself is communicated both to and from ideators and adopters not in any single volley of words or content, but in the mutual agreement established in time over how a capability may be used as part of the users’ own needs, and in how their way of doing things is both prospectively and actually changed through adoption. 179

Appendix A

LITERATURE CITED

Alexander, IE (1988). “Personality, psychological assessment, and psychobiography”. Journal of Personality. 56 (1): 265–294.

Amadi-Echendu, JE (2007). “Thinking styles of technical knowledge workers in the systems of innovation paradigm”. Technological Forecasting & Social Change. 74:1204–1214.

Anderson, T (2000). Public policy making. (4th ed.) Boston: Houghton Mifﬂin.

Apache Software Foundation (2006). Apache Software Foundation Mail Archives. Apache

Software Foundation, http://mail-archives.apache.org/ Retrieved: 18 Sep 2009.

Apache Software Foundation (2009a). Apache HTTP Server Project Guidelines and Vot- ing Rules. The Apache HTTP Server Project. http://httpd.apache.org/dev/guidelines.html Re- trieved: 1 Aug 2009.

Apache Software Foundation (2009b). Mailing Lists. Apache Software Foundation, http://www.apache.org/foundation/mailinglists.html Retrieved: 18 Sep 2009.

APEWS (2010). About APEWS. Anonymous Postmasters Early Warning System, http://apews.org/ Retrieved: 10 March 2010.

Argyris, Chris (1970). Interventionist Theory and Method – A Behavioural Science View.

Reading: Addison-Wesley.

ARIN (2007). Suggestions. American Registry for Internet Numbers, https://www.arin.net/participate/acsp/index.html Retrieved: 18 Sep 2009.

ARIN (2008a). ARIN XXII Public Policy Meeting Draft Transcript - 16 October 2008.

American Registry for Internet Numbers, https://www.ARIN.net/participate/meetings/reports/ARIN XXII/ppm2 transcript.html#anchor 9

Retrieved: 18 Sep 2009. 180

ARIN (2008b). DRAFT POLICY 2008-7: IDENTIFY INVALID WHOIS POCS. American

Registry for Internet Numbers, https://www.arin.net/policy/proposals/2008 7.html Retrieved:

18 Sep 2009.

ARIN (2009). ARIN Number Resource Policy Manual. Section “4.2.4. ISP Additional

Requests”. American Registry for Internet Numbers.

ARIN (n.d. 1). ARIN History. American Registry for Internet Numbers, https://www.arin.net/about us/history.html Retrieved: 18 Sep 2009.

ARIN (n.d. 2). Mailing Lists. American Registry for Internet Numbers, https://www.arin.net/participate/mailing lists/ Retrieved: 18 Sep 2009.

ARIN Member Services (2008). Policy Proposal 2008-4 Discussed at ARIN Caribbean

Sector Meeting. American Registry for Internet Numbers, 10/6/08 7:44 AM.

Aronson, Cathy; Andersen, Paul (2008) via ARIN Member Services. Policy Proposal

2008-4: Minimum Allocation in the Caribbean Region. American Registry for Internet Num- bers, 16 May 2008.

Arthur, WB (2007). “The Structure of Invention”. Research Policy. 36 (2): 274–287.

Baird, F; Moore, C; Jagodzinski, A (2000). “An ethnographic study of engineering design teams at Rolls-Royce Aerospace”. Design Studies. 21(4): 333–355.

Barringer, Bruce R; Jones, Foard F; Neubaum, Donald O (2005). “A quantitative content analysis of the characteristics of rapid-growth ﬁrms and their founders”. Journal of Business

Venturing. 20: 663–687.

Baumol, WJ (1996). “Entrepreneurship: Productive, unproductive, and destructive”. Jour- nal of Business Venturing. 98 (5): 893–921.

Berelson, Bernard (1952). Content Analysis in Communication Research. New York: Free

Press

Bessant, J; Tidd, J (2007). Innovation and entrepreneurship. Hoboken, NJ: Wiley. 181

Beverley, Andy (2007). “Integrity of Apache source code”. [email protected]. Apache

Software Foundation,12/17/07 4:22 PM.

Blake-Wilson, S. et al. (2003). Request for Comments: 3546 - Transport Layer Security

(TLS) Extensions. The Internet Society.

Booth, N (2008). “Googles Chrome web browser - Essential Guide”. Computer Weekly.

Reed Business Information Ltd. Tuesday 09 September 2008 04:37 http://www.computerweekly.com/Articles/2009/07/13/232257/Googles-Chrome-web-browser-

Essential-Guide.htm Retrieved: 18 Sep 2009.

Bordia, P (1997). “Face-to-Face Versus Computer-Mediated Communication: A Synthesis of the Experimental Literature”. Journal of Business Communication. 34 (1).

Brown, Warwick (2008). Bug 417152 - move the Home button only if the bookmarks toolbar is visible. Mozilla Bugzilla. Mozilla Foundation, 2008-02-12 19:39 https://Bugzilla.mozilla.org/show bug.cgi?id=417152 Retrieved: 18 Sep 2009.

CBL (2009). The Composite Block List. Blighty Design, http://cbl.abuseat.org/ Retrieved:

20 Sep 2009.

Chadwick, A. (2008). Web 2.0: New Challenges for the Study of E-Democracy in an Era of

Informational Exuberance. Department of Politics and International Relations/New Political

Communication Unit, Royal Holloway, University of London.

Cherry, Colin (1966). On Human Communication. Cambridge: MIT.

Clark, Peter A (1987). Anglo-American innovation. New York: Walter de Gruyter.

Connor, M (2008). “Bug 404109 - move the Home button to the Bookmarks toolbar, and reset toolbars for Firefox 3”. Mozilla Bugzilla. Mozilla Foundation, 2008-01-29 22:53 PST https://Bugzilla.mozilla.org/show bug.cgi?id= 404109 Retrieved: 20 Sept 2009.

Cooke, P (2001). “Regional Innovation Systems, Clusters, and the Knowledge Economy”.

Industrial and Corporate Change. 10 (4): 945–974. 182

Cotoni, Ronald (2009). “Re: Can someone from SORBS contact me ofﬂist?”, North Amer- ican Network Operators Group Mailing List. North American Network Operators Group,

7/11/09 11:05 AM.

Cox, A (2009). “Re: [PATCH] kdesu broken”. Linux Kernel Mailing List. Tue, 28 Jul 2009

20:15:53 +0100, http://lkml.org/lkml/2009/7/28/375 Retrieved: 18 Sep 2009.

Cymru (2009). The Team Cymru Bogon List v5.0. Team Cymru, Inc., http://www.cymru.com/Documents/bogon-list.html Retrieved: 18 Sep 2009.

Daniel Karrenberg; Gerard Ross; Paul Wilson; Leslie Nobile (2001). “Development of the

Regional Internet Registry System”. The Internet Protocol Journal. 4 (4).

Darte, Bill (2008). “re: Policy Proposal 2008-4 - Staff Assessment”. ARIN-PPML. Ameri- can Registry for Internet Numbers, 10/10/08 6:51AM.

DeLong, Owen (2008a). “WHOIS Archival Policy?”. ARIN-PPML. American Registry for

Internet Numbers, 6/18/08 8:39 AM.

DeLong, Owen (2008b). “ACSP SUGGESTION 2008.15: WHOWAS SERVICE”. ARIN-

PPML. American Registry for Internet Numbers, https://www.ARIN.net/participate/acsp/suggestions/2008-15.html Retrieved: 18 Sep 2009.

Dillon, M (2008). “re: Policy Proposal: WHOIS Integrity Policy Proposal”. ARIN-PPML.

American Registry for Internet Numbers, 8/21/08 4:40 AM.

Dosi, G (1982). “Technological paradigms and technological trajectories”. Research Pol- icy. Vol. 11, No. 3.

Drazen, Jeffrey M; Campion, Edward W (2003). “SARS, the Internet, and the Journal

[Editorial]”. New England Journal of Medicine. 348 (20): 2029.

Dunbar, RIM (1993). “Coevolution of neocortical size, group size and language in humans”. Behavioral and Brain Sciences. 16 (4): 681–735. 183

Dunn, John E (2009). “Mozilla to add multithreading to Firefox”, Infoworld. May 11,

2009, http://www.infoworld.com/d/applications/mozilla-add-multithreading-ﬁrefox-923

Retrieved: 19 September 2009.

“EE ([email protected])” (2009). “Firefox 4 dumbing down?”, mozilla.wishlist. Mozilla

Foundation, 8/6/09 12:27 PM.

Erenkrantz, Justin (2008). “Conﬁguration change for cvs@httpd?”. [email protected].

Apache Software Foundation, 12/31/08 7:48 AM.

Fielding, R (2008) “[ogb-discuss] Sun’s Responses to the OpenSolaris Trademark Ques- tions”. Open Solaris Governing Board (OGB) general discussion. Oracle Corporation, http://mail.opensolaris.org/pipermail/ogb-discuss/2008-February/003443.html Retrieved:

18 Sep 2009.

Florida, R (2002). The rise of the creative class: and how it’s transforming work, leisure, community and everyday life. New York: Basic Books.

Foucault, M (2003). ”Why Study Power: The question of the Subject.” in The Essential

Focault. Paul Rainbow and Nikolas Rose (eds.). pp. 127-144. London: The New Press.

FOLDOC (1997). “post”. Free Online Dictionary of Computing.

Gertler, Meric S (2002). “Technology, Culture and Social Learning: Regional and National

Institutions of Governance” in Gertler, Meric S; Wolfe, David A (eds) (2002). ‘Innovation and Social Learning: Institutional Adaptation in an Era of Technological Change. Hampshire:

Palgrave Macmillan.

Gladwell, Malcolm (2000). The Tipping Point: How Little Things Can Make a Big Differ- ence. Paris: Little Brown.

Glaser, Barney G; Strauss, Anselm L (1967). The Discovery of Grounded Theory: Strate- gies for Qualitative Research. Chicago: Aldine Publishing Company. 184

Google (2009). ”Google News Search: ’home button’ refox 3 beta 3”. http://www.google.ca

/search?hl=en&num=100&site=mbd&q=“home+button”+ﬁrefox+3+beta+3&tbs=cdr:1,cd min:

Feb+12 2+2008,cd max:March+9 2+2008 Retrieved: 19 Sep 2009.

Grabisch, Michel; Rusinowska, Agnieszka (2010). “Different Approaches to Inﬂuence

Based on Social Networks and Simple Games.” in Collective Decision Making: Views from

Social Choice and Game Theory Series: Theory and Decision Library C, Vol. 43. Van Deemen,

Adrian; Rusinowska, Agnieszka (Eds.) 1st Edition. pp. 185-209.

Gerling, Kerstin; Gruner, Hans Peter; Kiel, Alexandra; Schulte, Elisabeth (2005). ”In- formation acquisition and decision making in committees: A survey”. European Journal of

Political Economy Vol. 21 (2005) 563597.

Gundermann, C (2008a). “re: Policy Proposal: WHOIS POC e-mail cleanup”. ARIN-

PPML. American Registry for Internet Numbers, 8/21/08 12:49 PM.

Gundermann, C (2008b) via ARIN Member Services. Policy Proposal: Annual WHOIS

POC Validation. American Registry for Internet Numbers, 21-Aug-2008.

Hall, E (2005). RFC 4155: The application/mbox Media Type. The Internet Society.

Henderson, Rebecca M; Clark, Kim B (1990). “Architectural Innovation: The Reconﬁgu- ration Of Existing Product Technologies and the Failure of Established Firms”. Administrative

Science Quarterly. 35 (1): 9–30.

Hennigan, Jay (2008). “re: Policy Proposal: WHOIS Integrity Policy Proposal”. ARIN-

PPML. American Registry for Internet Numbers, 8/19/08 6:23 AM.

Homer-Dixon, Thomas (2000). The Ingenuity Gap. New York: Knopf.

Howell, Jane M; Higgins, Christopher A (1990). “Champions of Technological Innova- tion”. Administrative Science Quarterly. 35 (2).

Hume, E (2008). “Bug 404109 - move the Home button to the Bookmarks toolbar, and reset toolbars for Firefox 3”. Mozilla Bugzilla. Mozilla Foundation, 2008-01-30 21:09:58 PST https://Bugzilla.mozilla.org/show bug.cgi?id= 404109 Retrieved: 20 Sept 2009. 185

“Ian G” (2009). “Re: SNI in 2.2.x Re: Time for 2.2.10?”. [email protected]. Apache

Software Foundation, 2008-08-20 9:29:23.

Intra2net AG (2009). Blacklist Monitor” Statistics of accuracy and failure rates - Blacklist statistics: 12. October 2009 - 18. October 2009. Intra2net AG, http://www.intra2net.com/en/support/antispam/ Retrieved: 22 Oct 2009.

Jacobson, I (1987). “Object oriented development in an industrial environment”. OOPSLA

’87: Object-Oriented Programming Systems, Languages and Applications. ACM SIGPLAN. pp. 183–191.

Jaeger, PT (2002). “Constitutional principles and E-Government: an opinion about possible effects of Federalism and the separation of powers on E-Government policies”. Government

Information Quarterly. 19 (4): 357–368.

Jayasinghe, Kelum; Thomas, Dennis; Wickramasinghe, Danture (2007). In Search of the

Micro-Entrepreneur: Deconstructing the Schumpeterian Legacy. School of Management and

Business, University of Wales, Aberystwyth. Research paper 2007-2.

Jung, R (2008). “Bug 44427 - Externally triggered rotatelogs rotation”. ASF Bugzilla.

Apache Software Foundation, 2008-02-14 17:55:04 UTC.

Jung, R (2009). “Re: son commit: r733493 - in /httpd/httpd/trunk:

CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c”. [email protected]. Apache Software Foundation. 1/12/09 1:03 PM

Kauffman, Stuart (2000). Investigations. Oxford: Oxford University Press.

Kerra, David S; Murthy, Uday S (2009). “The effectiveness of synchronous computer- mediated communication for solving hidden-proﬁle problems: Further empirical evidence”.

Information & Management. 46 (2): 83–89.

Kew, Nick (2009). “Re: Question about bug-source traceability”, [email protected].

Apache Software Foundation,12/12/09 2:35 AM. 186

Khun, T (1962). The structure of scientiﬁc revolutions. Chicago, IL: University of Chicago.

Kingsley-Hughes, A (2008). “Google Chrome is insanely fast ... faster than Firefox 3.0”.

Hardware 2.0. Ziff Davis. September 2, 2008 http://blogs.zdnet.com/hardware/?p=2507 Re- trieved: 11 Sept 2009.

Krippendorff, K (1980). Content Analysis: An Introduction to Its Methodology. Newbury

Park, CA: Sage.

Kuhlmanna, S; Edler, J (2003). “Scenarios of technology and innovation policies in Europe:

Investigating future governance”. Technological Forecasting & Social Change. 70 (7): 619–

637.

Lancaster, KJ (1966). “A new approach to consumer theory”. Journal of Political Economy.

74: 132–157.

Lee, P (n.d.). “Why failure is a good thing in the creative business”. Graphic Design

Blender. http://graphicdesignblender.com/why-failure-is-a-good-thing-in-the-creative-business

Retrieved: 21 Sept 2009.

Leibrand, Scott (2008). “re: Policy Proposal 2008-4 - Staff Assessment”. ARIN-PPML.

American Registry for Internet Numbers, 10/9/08 2:55 PM.

Leydesdorff, L (1994). “The Evolution of Communication Systems”. International Journal of Systems Research and Information Science. 6: 219–30.

Li, B (2009). Understanding innovations by decomposition. Presented at Triple Helix VII,

Glasgow 2009.

Littlejohn, Stephen W; Foss, Karen A (2005). Theories of Human Communication. (8th ed.) Belmont, CA: Thomson Wadsworth.

Loch, K (2008). “re: Policy Proposal: WHOIS Integrity Policy Proposal”. ARIN-PPML.

American Registry for Internet Numbers, 8/19/08 9:13 PM.

MacEwan, R (2009). About Invaluement. PowerView Systems. http://dnsbl.invaluement.com/about/ Retrieved: 10 March 2010. 187

MacEwan, R (n.d.). About Removal Requests. PowerView Systems, http://dnsbl.invaluement.com/lookup/ Retrieved: 10 March 2010.

Markman, GD; Balkin, DB; Schjoedt, L (2001). “Governing the innovation process in entrepreneurial ﬁrms”. Journal of High Technology Management Research. 12 (2): 273–293.

Mcmullen, Jeffery S; Shepherd, Dean A (2006). “Entrepreneurial Action And The Role Of

Uncertainty In The Theory Of The Entrepreneur”. Academy Of Management Review. 31 (1):

132–152.

Mittelstaedt, T (2008). via ARIN Member Services “Policy Proposal: WHOIS POC e-mail cleanup”. ARIN-PPML. American Registry for Internet Numbers, 8/21/08 7:55 AM.

Mockus, A et al. (2002). “Two Case Studies of Open Source Software Development:

Apache and Mozilla.” ACM Transactions on Software Engineering and Methodology. 11 (3).

Moenaert, Rudy K.; Souder, William E; De Meyer, Arnoud; Deschoolmeester, Dirk (1994).

“R&D-Marketing Integration Mechanisms, Communication Flows, and Innovation Success”.

Journal of Product Innovation Management. 11: 31–45.

Mozilla Foundation (2003). Mozilla Development Forums. Mozilla Foundation, http://www.mozilla.org/community/developer-forums.html Retrieved: 23 Aug 2009.

Mozilla Foundation (2008). Firefox 3 Beta 3 Release Notes. Mozilla Foundation, February

12, 2008. http://www.mozilla.com/en-US/ﬁrefox/3.0b3/releasenotes/ Retrieved: 21 Sept 2009.

Mozilla Foundation (2009a). Bugzilla: conﬁrm account creation. Automated e-mail sent to author on 30 Aug 2009 10:34:19 -0700 by [email protected].

Mozilla Foundation (2009b). Mission — Mozilla Messaging. Mozilla Foundation, http://www.mozillamessaging.com/en-US/about/mission/ Retrieved: Aug 23, 2009.

Mozilla Foundation (2009c). Add-on Submission. November 30, 2009. https://addons.mozilla.org/en-US/developers/docs/policies/submission Retrieved: 10 Sep 2009.

Mozilla Foundation (2010). “IPDL”, MozillaWiki, Mozilla Foundation, January 26, 2010, https://wiki.mozilla.org/IPDL Retrieved: 2 Feb 2010. 188

Nelson, RR; Winter SG (1982). An evolutionary theory of economic change. Cambridge,

MA: Harvard University Press.

Netcraft (2009). What’s that site running? Netcraft, Ltd. http://netcraft.com Retrieved: 10

Sep 2009.

Nisbett, RE; Wilson, T (1977). “Telling more than we can know: Verbal reports on mental processes”, Psychological Review. 84 (3).

Nonaka, Ikujiro; Takeuchi, Hirotaka (1995). The Knowledge-Creating Company. Oxford:

Oxford University Press.

Norman, DA (1988). The Design of Everyday Things. New York: Currency.

Obama for America (2008). Barack Obama: Connecting and Empowering All Americans

Through Technology and Innovation. Obama for America. November 11, 2008. http://www.barackobama.com/pdf/issues/technology/Fact Sheet Innovation and Technology.pdf

Retrieved: 18 Sep 2009.

Oberman, RK (2008). “re: Policy Proposal: WHOIS Integrity Policy Proposal”. ARIN-

PPML. American Registry for Internet Numbers, 8/19/08 11:27 AM.

OECD (2002). Frascati Manual: The Measurement of scientiﬁc and technological activities. Paris: OECD.

OECD (2005). Oslo Manual: Guidelines for Collecting and Interpreting Innovation Data.

Paris: OECD.

OED (2009). “post, v.1” Oxford English Dictionary. Draft revision June 2009. Oxford:

Oxford University Press.

Ogi, H (2009). Tag Toolbar 0.7.80. Mozilla Foundation, https://addons.mozilla.org/ja/thunderbird/addon/4970 Retrieved: 5 Aug 2009.

OSI (n.d.). The Open Source Deﬁnition. Open Source Initiative. http://opensource.org/docs/osd Retrieved: March 20, 2010. 189

Paquet, Simon (2009). “What to do and what not to do in Bugzilla”. MDC. Mozilla

Foundation, https://developer.mozilla.org/en/What to do and what not to do in Bugzilla Re- trieved: 18 Oct 2009.

Plzak, Raymond A; Ryan, Stephen M (2006). ”Legal and Policy Aspects of Internet Num- ber Resources.” Presented to VI Computer Law World Conference 6 September 2006.

Porter, Michael E (1998). “Clusters and the New Economics of Competition”. Harvard

Business Review. 76 (6).

Poteete, Amy R; Ostrom, Elinor (2004). Conceptual Consistency and Data Comparability:

Methodological Challenges to Empirical Research on Collective Action. Paper presented at the annual meeting of the American Political Science Association, Hilton Chicago and the Palmer

House Hilton, Chicago, IL.

Quigley, C (1961). The Evolution of Civilizations. Michigan: MacMillan.

Raymond, ES (2000). Chapter: “The Social Context of Open-Source Software” in The

Cathedral and the Bazaar. http://www.catb.org/ esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s11.html Retrieved:

September 15, 2009.

Raymond, ES (2002). chapters “Release Early, Release Often” and “How Many Eyeballs

Tame Complexity” in The Cathedral and the Bazaar. http://www.catb.org/ esr/writings/cathedral-bazaar/ Retrieved: 12 September 2009.

Rice, RE; Rogers, EM (1980). “Reinvention in the Innovation Process”. Science Commu- nication. 1 (4): 499–514.

Rogers, Everett M (1962). Diffusion of Innovations. Glencoe: Free Press.

Rogers, Everett M (1995). Diffusion of Innovations. New York: Macmillan Company.

Rogers, Everett M (2003). Diffusion of Innovations. (5th ed.). New York: Free Press.

Rothwell, Roy; C. Freeman, A. Horsley, V.T.P. Jervis, A.B. Robertson, and J. Townsend

(1974). “SAPPHO Updated-Project Sappho Phase II”. Research Policy. 3: 258–291. 190

Rowe, WA Jr. (2009). “accept mod fcgid codebase into httpd project”. [email protected]. Apache Software Foundation, 1/11/09 8:53 PM.

Sabatier, Paul; Mazmanian, Daniel (1979). “The implementation of Public Policy - A

Framework of Analysis” in Policy Studies Review Annual. Volume 4 ed. Bertram Herbert

Raven. NJ: Transaction Publishers.

Santos, John (2008). “re: Policy Proposal: WHOIS Integrity Policy Proposal”. ARIN-

PPML. American Registry for Internet Numbers, 8/18/08 9:53 AM.

Schiller, H (2008) via ARIN Member Services, August 26, 2008. POLICY PROPOSAL

2008-7: WHOIS INTEGRITY POLICY PROPOSAL. American Registry for Internet Numbers,

8/18/08 9:53 AM.

Schmookler, Jacob (1966). Invention and Economic Growth. Cambridge: Harvard Univer- sity Press.

Schumpeter, JA (1934). The Theory of Economic Development: An Inquiry into Proﬁts,

Capital , Credit, Interest, and the Business Cycle. Cambridge: Harvard University Press.

Schumpeter, JA (1942). Capitalism, socialism and democracy. New York: Harper.

Schumpeter, JA (1950). Capitalism, Socialism, and Democracy. (3rd ed.). New York:

Harper & Row, Publishers.

Schumpeter, JA (1982). The theory of economic development. New Jersey: Transaction

Publishers.

Seastrom, RE (2008). “re: Policy Proposal: WHOIS Integrity Policy Proposal”. ARIN-

PPML. American Registry for Internet Numbers, 8/19/08 12:36 PM.

Shannon, C; Weaver, W (1948). The Mathematical Theory of Communication. Urbana:

University of Illinois Press.

Sharma, S; Sugumaran, V; Rajagopalan, B (2002). “A framework for creating hybrid-open source software communities”. Information Systems Journal. 12 (1): 7–25. 191

Sharp, G (2008). “Bug 422420 - Revert home button move and related migration code”.

Mozilla Bugzilla. Mozilla Foundation, 2008-03-12 08:21 PDT https://Bugzilla.mozilla.org/show bug.cgi?id=422420 Retrieved: 20 Sept 2009.

Sinatra, M (2008a) via ARIN Member Services. Policy Proposal: WHOIS Authentication

Alternatives. American Registry for Internet Numbers, 8/20/08 8:47 AM.

Sinatra, M (2008b) “re: Whois Integrity Policy Proposal”, ARIN-PPML. American Registry for Internet Numbers, 8/22/08 4:00 PM

Sinatra, M (2008c) “re: Policy Proposal: Whois Integrity Policy Proposal”, ARIN-PPML.

American Registry for Internet Numbers, 8/19/08 4:38 PM

Sinatra, M (2008d) “re: Policy Proposal: Whois Integrity Policy Proposal”, ARIN-PPML.

American Registry for Internet Numbers, 8/19/08 5:33 PM

Smedberg, B (2009). “Electrolysis”. MozillaWiki. Mozilla Foundation, May 5, 2009, https://wiki.mozilla.org/Content Processes Retrieved: 20 Sept 2009.

Smith, Kevin B; Larimer, Christopher (2009). The Public Policy Theory Primer. Boulder,

CO: Westview Press.

Souder, William E; Moenaert, Rudy K (1992). “Integrating marketing and R&D project personnel within innovation projects: an information uncertainty model”. Journal of Manage- ment Studies. 29 (4): 485–512.

Spamhaus (2009). About Spamhaus. The Spamhaus Project Ltd. http://www.spamhaus.org/organization/index.lasso Retrieved: 21 October 2009.

Spitzer, Seth; Flett, Alec (2009). “Mozilla Development Strategies”. MDC. Mozilla Foun- dation, https://developer.mozilla.org/en/Mozilla Development Strategies Retrieved: 20 Sept

2009.

Stenback, J (2009). “Bug 478976 - OOPP) Electrolysis + plugins tracking”. Mozilla

Bugzilla. Mozilla Foundation. https://bugzilla.mozilla.org/show bug.cgi?id=478976 Retrieved:

2 Feb 2010. 192

Storper, Michael; Venables, Anthony J (2004). “Buzz: face-to-face contact and the urban economy”. Journal of Economic Geography. 4 (4):351–370.

Suarez-Villa, L (1990). “Invention, inventive learning, and innovative capacity”. Behav- ioral Science. 35 (4): 290–310.

Swyngedouw, E (2005). “Governance innovation and the citizen: the Janus face of governance-beyond-the-state”. Urban Studies. 42 (11):1991–2006.

Tapscott, Don; Williams, Anthony D (2006). Wikinomics: How Mass Collaboration

Changes Everything. New York: Portfolio.

Teece, D (1986). “Proﬁting from technological innovation: Implications for integration, collaboration, licensing and public policy”, Research Policy. 15: 285–305.

Tidd, Joe; Bessant, JR; Pavitt, Keith (1997). Managing Innovation: Integrating Technolog- ical, Market and Organizational Change. Hoboken: Wiley.

Tornatzky, LG et al. (1983). The process of technological innovation: reviewing the literature. Washington, DC: National Science Foundation.

UCEPROTECT (2010). UCEPROTECT-NETWORK SPAM-FAQ. UCEPROTECT-Orga, http://www.uceprotect.net/en/index.php?m=2&s=0 Retrieved: 10 March 2010.

Utterback, James M (1995). Mastering the Dynamics of Innovation. Cambridge: Harvard

University Press.

Utterback, James M; Abernathy, William J (1975). “A dynamic model of process and product innovation”. Omega. 3 (6):639–656.

von Hippel, E (1998). The Sources of Innovation. Oxford: Oxford University Press. 193

Appendix B

CHAPTER 5 CASE STUDY QUOTATIONS

B.1 Quotations

This appendix provides quotations from source materials supporting Chapter 5. The original communication items from which these quotations are extracted may be located by referenc- ing each message’s time-stamp and author in archives of the Bugzillas and mailing lists indicated. Note that some versions of message archives may use different time zones for their time-stamps.

B.2 Case 2

B.2.1 Quotation 2.1

“I ﬁnd this change is quite the opposite of improvement for me. I do not need to

provide justiﬁcation why I would want to visit a site with a self-signed certiﬁcate.

All that this change has done is caused me to search for hours for a way to get past

the message. I found it, buried 8 clicks deep – impressive, isn’t it? Did some user

actually ask for this functionality, or what prompted the developers to want to hold

my hand and tell me what I do not want to do? Did someone ask - please make this

harder for me, I am not competent enough to take decisions myself. Is the Gnome

disease spreading here too?”

– Andreev, A (2008-02-25 01:30:22 PST). Comment 170, “Bug 327181 - (https-error-pages)

Improve error reporting for invalid-certiﬁcate errors (error page for https, or combined dialog)”,

Mozilla Bugzilla. 194

B.3 Case 3

B.3.1 Quotation 3.1

“This is the ﬁrst time since the launch of Firefox 1.0 that we’ve changed the

default layout of controls, adding a new uniﬁed back/forward button... and moving

the “Home” button down to the Bookmark Toolbar. These changes are needed

to realize the new theme work which aims to make Firefox slick and OS-native,

while also retaining a unique identity across all platforms. A lot of time and angst

precede decisions like this, and we know that we’ve likely caused some cursing

amongst our closest followers. We’re sorry for that. Fortunately it’s easy to move

things back to the way they were (once you’ve ﬁnished your cursing) and it will

only take a second or two to do it, in case you decide that hm, no, after all, your

way is still better.”

– Mike Beltzner, Jan. 30, 2008. “Dear Eggs... (an apology from the omelet).” beltzner. http://beltzner.ca/mike/2008/01/30/dear-eggs-an-apology-from-the-omelet/ Ret. Dec. 28, 2009

B.4 Case 4

B.4.1 Quotation 4.1

“I think this [external summary of Internet Explorer 7’s threading implementa-

tion] give[s] a really good reason to ﬁx what I and I am guessing many others see

as a weak point of Firefox before the competition gets out with a version of their

browser that works in this way.”

– “Mark” (2005-05-27, 16:37). Comment 11, “Bug 40848 - (thread) each docshell should run on its own thread (one thread per frame)”, Mozilla Bugzilla. 195

B.4.2 Quotation 4.2

“Unless you’re going to work on this, or have a constructive technical com-

ment, do not add to this bug. Here’s a free clue: we are not going to have this bug

ﬁxed before the likely beta release of IE7. Will that matter to most end users? Of

course not... Don’t spam it, or I’ll do something drastic.”

– Eich, Brendan (2005-05-27 17:16:27). Comment 12, “Bug 40848 - (thread) each docshell should run on its own thread (one thread per frame)”, Mozilla Bugzilla.

B.5 Case 5

B.5.1 Quotation 5.1

“... this proposal came via the staff as a request from the folks of the Caribbean

region. ARIN does have a deﬁnition that they’re working from for this region. I

feel fairly certain that the ARIN staff knows the ARIN service area. I am not sure

why this is such an issue. The staff doesn’t seem to have an issue with it. We did

this exact same thing for Africa and that seemed to work out just ﬁne.”

– Cathy Aronson (10/9/08 4:19 PM). “Policy Proposal 2008-4 - Staff Assessment”, ARIN-

PPML, American Registry for Internet Numbers.

B.5.2 Quotation 5.2

“I even went back [to] review the Quicktime [recording] of the Open Policy

Hour from Denver, because I honestly couldn’t remember if I only thought about

raising the issue or if I actually did... This discussion and reviewing the Open Pol-

icy Hour Quicktime from Denver, has help[ed] me to come to the conclusion that

the proper scope of this issues and maybe even the proper title is ’Small Economies

within the ARIN Region’.” 196

– Farmer, David (10/10/08 10:40 AM). “re: Policy Proposal 2008-4 - Staff Assessment”.

ARIN-PPML, American Registry for Internet Numbers.

B.6 Case 6

B.6.1 Quotation 6.1

“Legacy records are frequently out of date and have become an increasingly

popular target for hijackers. Having up to date contact information and a formal

relationship with legacy record holders would assist ARIN and ISP’s in ensuring

these records are maintained accurately.”

– Schiller, H (8/18/08 9:53 AM) via ARIN Member Services. “POLICY PROPOSAL 2008-7:

WHOIS INTEGRITY POLICY PROPOSAL”. American Registry for Internet Numbers.

B.6.2 Quotation 6.2

“Here’s a question: If you’re the original legacy registrant but your email ad-

dress, phone number and postal address have changed, how exactly do you estab-

lish your bona-ﬁdes to ARIN in order to make a change now?”

– Herrin, Bill (6/18/08 9:52 PM). “re: WHOIS Archival Policy?” ARIN-PPML, American

Registry for Internet Numbers.

B.6.3 Quotation 6.3

“Unfortunately there is a lack of hard numbers... entering ’hijacked netblocks’

in Google will ﬁnd plenty. ARIN does much of its work on them behind closed

doors, and for good reason. ARIN actually tries to get criminal and civil prosecu-

tion of the fraudsters. More than a few ISP folks will tell you in the halls about

cases where a customer came to them with a funny looking block, they referred 197

it to ARIN and soon after that person no longer had the block. I believe many of

these are from hijacking.”

– Bicknell, Leo (8/20/08 2:02 PM). “re: POLICY PROPOSAL: WHOIS INTEGRITY POL-

ICY PROPOSAL”. ARIN-PPML, American Registry for Internet Numbers.

B.6.4 Quotation 6.4

“The numbers that Heather provided only partially describe the resources and

organizations affected by this proposal.

36,038 netblock records with last modiﬁed year of 1997 or earlier

2,375 ASN records with last modiﬁed year of 1997 or earlier

22,718 ORG records with last modiﬁed year of 1997 or earlier

How many legacy netblock and ASN records have been updated since the for-

mation of ARIN on December 22, 1997? My biggest objection to the proposal is

that it sounds like a stick to beat up the evil legacy resource holder because they

haven’t been paying their fair share. Until less than a year ago, ARIN did not have

a process or documentation in place to allow a legacy resource holder to bring the

resource under some kind of agreement.”

– Hare, Keith W (8/21/08 8:47 AM). “re: POLICY PROPOSAL: WHOIS INTEGRITY POL-

ICY PROPOSAL”. ARIN-PPML, American Registry for Internet Numbers.

B.6.5 Quotation 6.5

“I assume the act of authenticating the resource holders however it is done

today takes staff time. Since many legacy holders pay no fees they are being

subsubsidized by other ARIN members. The $100 a year hopefully covers the

cost of authenticating the legacy holder, providing them WHOIS and in-addr.arpa 198

services, this forum for discussion, and so on so the playing ﬁeld is much more

level than it is today.”

– Bicknell, Leo (8/19/08 4:17 PM). “re: POLICY PROPOSAL: WHOIS INTEGRITY POL-

ICY PROPOSAL”. ARIN-PPML, American Registry for Internet Numbers.

B.6.6 Quotation 6.6

“If the goal is accurate WHOIS (and not to force the (L)RSA contract on legacy

holders [...)] a solution with a much more likely (quick) uptake would be a “LRSA-

lite” contract, of which the legacy holders (on their part) agree only that they were

previously allocated resources and are responsible for keeping the WHOIS data

correct/accurate.”

– Bhurmaster, Gary (8/20/08 11:57 PM). “re: POLICY PROPOSAL: WHOIS INTEGRITY

POLICY PROPOSAL”. ARIN-PPML, American Registry for Internet Numbers.

B.6.7 Quotation 6.7

“This may seem harsh, but essentially these networks have opted out of Internet

society by not paying their taxes. There may not be an IRS to shut them down,

but that doesn’t mean that honest tax-paying members of the Internet need to do

business with these network operators. Personally, I suspect that if someone sets

up this type of feed, it will soon be picked up in the media and we will see a ﬂurry

of people updating their contact info.”

– Dillon, Michael (8/21/08 4:40 AM). “re: POLICY PROPOSAL: WHOIS INTEGRITY POL-

ICY PROPOSAL”. ARIN-PPML, American Registry for Internet Numbers. 199

Appendix C

CLASSIFYING ENHANCEMENTS AND INNOVATIONS

A central idea guiding this thesis is that communication is essential to OEPs, linking new ideas to changes in the broader world. This work has implicitly assumed some comparability of “enhancements” from on-line OEEs with industrial “innovations”, as forms of purposeful change. This appendix1 examines enhancements and innovations without considering communications from their development. Using a method suggested by literature, it extracts particular characteristics of OEE enhancements and non-OEE innovations to test their comparability.

Speciﬁcally, it characterises why an enhancement or innovation was wanted, the actions taken to realize an enhancement or innovation, and the results. It then re-connects the abstract categories with the rich text data to better understand the context of the data reported in this thesis.

C.1 Introduction

The framework used in this appendix characterizes innovations using six factors in three dimensions. It relates reasons behind innovations to their realized changes. It was applied in previous work to 27 innovations described in narratives by key participants in the Calgary

CMA as part of ISRN research (described next). This chapter reports results from applying the method to the 10 enhancements in OEEs described in Chapter 5. The goal was to determine if OEE enhancements and CMA innovations shared common relationships between why an enhancement or innovation was wanted, the actions taken to realize an enhancement or innovation, and the results. The term “enhancement” distinguishes the OEE efforts from the CMA efforts, without making claims about the innovativeness of the former.

1based on a paper presented at Triple Helix VII in Glasgow, 2009 200

The Calgary CMA dataset represents a cross-section of industries and types of actors among entities thought to be important to the innovation system in Calgary. The data includes interviews with individual innovators and representatives from groups and entire organizations during the years 2006–2009. The variety of sources, types and contexts of individual innovations represented allows descriptions of past innovation circumstances to be distilled into essential, common types of factors, and for such factors to be compared and contrasted with those of more recent or ongoing innovations. Public narratives about innovations and their processes as reported in news media, commentary and corporate communications provide a way to externally establish the reliability of some of the individual narratives collected in the CMA data, as well as a way to externally adjudicate the degree of success of innovations described in CMA data. Comparing enhancement patterns among the two kinds of data sources enables an estimate of how well in the OEPs represent innovation processes in general.

C.2 Development of the framework

A preliminary reading of a dozen interviews from the CMA data set of over 100 interviews found descriptions of three broad phases to be common to all innovations described: The circumstances for an idea, attempt to implement the idea, and the outcome.2 These formed a preliminary hypothesis (that circumstances, implementation, and outcome were causally linked in procedural sequence, and that such linkage related to success of innovations) later reﬁned into six more precisely deﬁned factors.

The six factors have strong empirical and theoretical bases in innovation literature, but their consideration in concert is less developed. The motive behind a change is similar to Ut- terback and Abernathy’s (1975) “stimuli for innovation”, and often responds to an observed or perceived limit in capabilities (Nelson and Winter, 1982, Chapter 2, pp. 59 ff.). Initiating

2With respect to the CMA data used in this appendix, the author worked with ISRN collaborators to conduct and transcribe interviews, but the coding and analysis used herein is the present author’s alone. 201 change consumes resources (OECD, 2005) to reconﬁgure objects, ideas, and people, or their circumstances. The creative change action can take many forms, including invention, learning, network building, etc. (McMullen and Shepherd, 2006). A solution arising from the creative change—in the form of something to be adopted or diffused (Rogers, 1962)—addresses the initial motive by presenting the resource created by the innovation to satisfy at least the original limit (Lancaster, 1966). Although the factors suggest an overall chronological progression, the dissection framework neither claims nor requires that innovations arise through any particular process.

Each of those factors—motives, limits observed, resources used, creative change, solution implemented, and resource created—can have components in each of three dimensions, re-

ﬂecting three of Quigley’s (1961, pg. 48) “range of human potentialities” and human needs.

The industrial dimension consists of physical materials, machines, monetary resources and their relations and configurations. The social dimension consists of individual persons and groups of people, and their relations and configurations. The intellectual dimension consists of ideas, concepts, knowledge, paradigms and their relations and configurations. (Quigley’s other three potentialities—religious, political, and military—were not applicable to the enhancements and innovations studied.) Each combination of a factor and dimension was labelled as a component. Each component had a magnitude reflecting the number of aspects of an innovation case which involved that combination of factor and dimension. (An innovation changing social relationships in two different ways would have a “creative change–social” component equal to two.) In this framework, 18 components identified (six factors in three dimensions) formed the change profile for each enhancement or innovation. 202

C.3 Hypothesis

From testing the main relationships of this thesis (that the circumstances for an idea, implementation of the idea, and the outcome were linked in procedural sequence, and that such linkage related to success of enhancements), it has been shown that communication, shepherds, and users must agree on the capabilities and potential uses of enhancements for such

OEE enhancements to be successful. The following hypothesis attempts to link that ﬁnding to non-OEE innovations by comparing the similarities of OEE needs and enhancements to several non-OEE needs and innovations.

• H1. Successful innovations enable users to better meet their needs in the same manner

as successful enhancements.

Enhancements and innovations that saw low adoption were expected to share the feature that the resources they created did not match the limits the changes were intended to address.

C.4 Method

Each enhancement or innovation was inspected for mentions of ideas, intended changes, and changes actually carried out to implement ideas (including inventing, intervening, or other work). For each enhancement or innovation, all related mentions of the six factors (motives, limits observed, resources consumed, creative change, solution implemented, resource created) in three dimensions (industrial, social, intellectual) were identiﬁed. The magnitude of each component was recorded, counting multiple mentions of the same component only once.

Because the source data consisted largely of narratives about enhancements and innovations, this method relies on three of Alexander’s (1988) “nine principle identifiers of salience”— primacy, uniqueness, and emphasis—to assume that informants identified the most important information about their enhancements and innovations first. 203

Table C.1 records each distinct CMA innovation using a change profile consisting of an array of 18 numbers, with each of the six factors being represented by a triplet containing component magnitudes for the three dimensions. (For example, an innovation relieving a limit with no industrial components, four intellectual components and two social components would have its ‘Limit’ factor represented as 0/4/2.) “Innovations” described by interviewees as not successful, or only partially successful, in achieving their goals were recorded accordingly. In- novations were identified as successful or non-successful if there was evidence of such outside of the interviews—for example, via media coverage or testimonials, or abandonment of firms or products. The remaining cases were identified as “not yet” successful or non-successful.

Table C.2 records analogous data for the OEE enhancements. Success of OEE enhancements was recorded based on their formal status in their respective OEPs, and external evidence such as media coverage and software downloads. Additionally, enhancements and innovations were categorized according to Schumpeter’s (1942) innovation categories, and under Henderson and

Clark’s (1990) concepts and components framework.

Note that the CMA data are not a representative sample of innovators nor innovations from the Calgary CMA, and that interviewees were not requested to provide information about their successful or failed innovation efforts, but only about innovations in which they or their ﬁrm participated. Similarly, the OEE enhancements selected do not represent all OEE enhancements.

C.5 Results (CMA data)

A set of 14 full interview transcripts from the CMA data (accounting for 21 of the 27 innovations examined) and six public sources was used. Public sources consisted of published media reports and websites in which entrepreneurs (senior leaders of organizations based in Cal- gary) described their innovations entirely or largely in their own words. Several incompletely 204

Table C.1: Change proﬁles for 27 identiﬁed innovations in CMA data.

- I I I I I I I R R R R R R R R A A A A A A M M M M M M (H Success Innov. type been columns:

tion, PR=product, Resource created a

and development (ME/OR/SO) sector partnership (OR) - l green energy (MA/PR) Limit profit funding policy (OR) Intended change - sible excesses in resources created.

medical research device (PR) (Schumpeter categories) s New artistic direction (PR) Prevent illegal parking (PR) New cultural landmark (PR) New surgical device (ME/PR) Enhance social inclusion (OR) profit. New logistics infrastructure (PR) New automotive franchises (MA) Eliminate homelessness (ME/OR) New audience demographic (MA) - New New interagency partnership (ME) New internal knowledge tool (ME) New market research methods (SO) New market research methods (SO) New non Insourced network filter (ME/OR/PR) New funding source/relationship (ME) Logistics education/collaboration (SO) New marketing/ownership model (SO) New business model/sources (ME/OR) New marketing measurement (OR/SO) New marketing/ownership model (OR) New residentia New university New funding/HR/knowledge (MA/ME/OR/SO) New hardware driver collaboration (ME/OR/SO) Outsource downtown re

No No No No No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Partial Partial Partial Not yet Not yet Not yet Not yet Not yet Adopted

25 17 13 19 36 23 21 24 15 11 36 12 14 27 35 32 33 34 25 42 31 35 13 15 15 11 28 points # Data

1 1 1 2 4 2 2 1 0 1 0 0 1 1 2 1 0 1 1 /0 / /0 /0 /0 / / / / / / / / / / / / / / / /0 /0 / 2 1 3 1 1 4 1 3 1 2 6 1 4 1 0 0 1 0 0 0 0 3 / / / / /0/0 / / / /0/0 / /0/ / / / / / /0/ / / / / / / / / / eated Res. ates limits not satisfied, italics show po 2 1 3 1 1 5 4 1 1 1 1 1 2 3 2 1 3 0 0 1 0 0 0 1 1 2 1/1 cr

1/2/1 2/1/0 1/1/0 1/1/0 1/1/0 2/2/2 1/0/2 1/1/0 0/1/1 1/0/0 1/1/1 1/0/0 1/0/0 1/1/0 0/3/0 1/0/0 1/1/0 1/1/2 0/2/1 1/1/1 1/0/2 0/2/1 0/0/1 0/0/0 1/1/0 0/1/0 1/0/3 Solution categories in parentheses: MA=market, ME=method, OR=organiz

1 0/2/1 4/0/1 3/1/0 3/1/0 1/1/0 4/1/4 4/0/0 2/1/0 0/1/1 3/1/0 1/1/1 1/0/0 1/0/1 2/2/1 2/1/0 2/1/1 1/0/1 1/0/1 0/2/2 0/1/2 2/0/1 1/2/2 0/0/2 0/0/ 1/1/0 1/0/0 2/0/1 change Creative column: I=industry, A=academic, G=government, N=non

Res. used 0/2/0 0/1/0 0/1/0 1/1/0 5/8/7 0/2/2 1/0/2 1/1/2 0/1/1 1/0/0 2/4/4 1/0/1 2/0/0 2/1/2 1/5/3 1/0/8 4/5/1 6/2/2 0/1/1 4/2/7 1/1/6 0/2/2 0/0/2 3/0/1 3/0/1 2/2/0 1/0/1 Sector

(Industrial/Intellectual/Social) 2 1 4 2 1 5 3 1 7 2 7 7 4 2 1 5 /0 / /0 /0 /0 /0 / / /0 / / / / / / / / / /0 /0 column: Schumpeter 4 1 1 4 1 1 3 1 3 3 5 5 2 1 7 3 3 1 2 / / / /0/0 /0/0 / / /0/0 / / / /0/ / / /1/ / / / / / / / 0/ 1 1 4 1 2 1 1 2 2 1/0/ 1 2 2 4 6 5 4 1 1/ 4 1 3 1 1 0/1/ 3/2 Limit

Clark innovation types A=architectural, I=incremental, M=modular, R=radical.

- 0/3/2 0/1/0 1/1/0 1/2/0 2/0/0 2/0/0 0/1/1 3/1/0 1/1/0 2/0/0 1/1/1 1/0/1 0/2/1 1/0/3 1/1/2 1/1/2 1/0/1 1/0/1 0/2/1 3/2/7 3/2/0 2/2/2 1/0/1 1/0/1 3/1/0 1/0/0 3/2/2 Motive ISRN interview. -

Intended Change

opment

column: Henderson Activity ev./multimedia Marketing Marketing Engineering Auto retailer Transportation Transportation Social services Performing arts Performing arts Municipal policy Private developer Private developer Private developer Civic organization Civic organization Civic organization Civic organization Medical technology Medical technology Bus. d Bus. dev./multimedia Bus. dev./multimedia Software devel Software development Software development Advertising multimedia Advertising multimedia

column: * indicates non

I I I I I I I I I I I G G G N N N G N N N N A A A/N G/A A/N Sector Innovation type

date 2002 2001 2001 2001 2000 2000 1978 2008 2007 2005 2008 2008 2008 1999 2008 2008 2006 2005 2008 2006 2008 2007 2008 2006 1993 2001 2005 Start

isfied with the innovation’s results.

# 1 2 4 5 6 7 8 9 3* 11 12 15 16 18 19 20 21 22 23 25 26 27 10* 13* 14* 17* 24* Innovation number Bold indicates resources created which proportionately satisfied the limits, underline indic column: ‘No’ indicates that the interviewee stated (at the time of the interview or after) that the innovation failed, ‘Yes’ indicates that the innovation’s success has recognized externally, ‘Not yet’ indicates that the innovation is relatively new and has not succeeded or failed, ‘Partial’ indicates that the interviewee was not completely sa SO=sources. Innov. 205

Table C.2: Change proﬁles for 10 identiﬁed enhancements in OEE data.

- I I I M M M M [I] AR (H AIMR

M (A?) Innov. type

column:

1). -

Innovation type

isfied with the innovation’s

t (PR) Note 2 column: ‘No’ indicates that the addresses (MA) Intended change (Schumpeter categories) New way to get data (PR) RSA holders from updating database (OR) Move the home button (none) Better way to warn users (ME) - Success ons to malfunction (ind - [prepare for a large UI revision (PR)] Verify existing whois database data (SO) New way deploy secure web servers (ME) late each browser document for performance (PR) Enable Caribbean members to request fewer IP Isolate each browser document for performance (PR) Iso

Less costly/more efficient way to deploy web servers Exclude non party add

columns: Bold indicates resources created which tion, PR=product, SO=sources.

No No No No Yes Yes Yes Yes Yes Yes Partial Adopted

5 6 8 8 8 12 12 28 11 10 [4] worked iteratively. points # Data Resource created hod, OR=organiz

1 ived criminals of a capability (ind +1), enhanced the accuracy of the database - 1/0 and

ible excesses in resources created. -

/0/0 s Res. 1/0/0 1/0/0 1 1/0/0 1/ 0/0/0 2/1/0 1/0/0 1/1/0 s 1/0/ 1), and caused many third Note 4 [1/0/0] - created - Limit

1), depr

1/0/0 1/0/0 1/1/0 1/1/0 0/0/0 0/0/0 1/1/0 1/1/0 1/1/0 1/1/0 [1/0/0] profit. Solution -

1/0/0 1/1/0 1/1/0 1/1/0 1/0/0 1/0/0 1/1/0 4/4/0 1/1/0 1/0/0 1/1/0 Note 1 change Creative of user interface components, which would be simplified with this change. Moving the home button

. Res. used 0/1/0 1/1/0 2/1/1 2/2/0 1/1/0 1/1/0 0/2/0 2/2/0 0/1/0 0/1/0 1/1/0 Note 1 Note 3 Note 1 1) -

(Industrial/Intellectual/Social)

1/0/0 1/0/0 1/0/0 0/1/0 0/0/0 2/1/0 4/4/0 1/0/0 2/0/1 1/0/0 Limit Note 1 [1/0/0]

0/0 1/0/0 1/0/0 1/1/0 1/1/0 2/0/0 3/0/0 1/0/0 2/0/0 1/0/0 [1/0/0] Motive

- ecure s - button button

ecure

column: I=industry, G=government, N=non ” ” s integrity 7) on - n

ome ome (327181) og rotation 08 SNI cument windows POC (2008 (as intended) “H “H SNI (40848) (34607) (34607) Activity Identify invalid (20 Sector RSA holders in the database (soc (404109) Note 2 - trigger (44427) (“Electrolysis”) column: Schumpeter categories in parentheses: MA=market, ME=met warning move Apache Caribbean (2008 Apache l ARIN move WHOIS Firefox Firefox Apache ARIN WHOIS ARIN Min. Allocation in Firefox secure connection Threaded do Threaded document windows

column:

I I I I N N N G G G Sector Clark innovation types A=architectural, I=incremental, M=modular, R=radical.

------14 21 20 14 16 27 05 16 26 23

------Intended Change date Start 2008 02 2005 04 2006 04 2006 02 2007 11 2000 05 2009 05 2008 05 2008 08 2009 03 ates that the innovation is relatively new and has not succeeded or failed, ‘Partial’ indicates that the interviewee was not completely sa

te 3: In the course of the immediate discussion, many proposals and problems (more than two) were discussed directly, and in the discussions which flowed into it. #

0 1 2 3 4 5 6 7 1a 4a [3] Innovation number proportionately satisfied the limits, underline indicates limits not satisfied, italics show po interviewee stated (at the time of the interview or after) that the innovation failed, ‘Yes’ indicates that the innovation’s success has been recognized externally, ‘Not yet’ indic results. Henderson Note 1: In the course of the work, many (more than two) drafts and concepts were discussed and/or Note 2: This innovation began its public life as a nearly finished change produced and approved by project leaders without reason or comment. The motive and limit was revealed elsewhere and relate to the broad technical implementation created negative resources in the sense that the change confused users for no benefit (int No Note 4: This proposal would have deprived stakeholders of a current capability (ind (ind +1), and alienated non Case 206 described innovations were excluded. The distribution of sectors represented in CMA innovations was: industry=11, government=5, academic=5, other=9 (three innovations concerned the intersection of two sectors each). In total, 642 usable data points were identiﬁed (Table C.1), with an average of 24 components describing each innovation (minimum=11, maximum=42).

The six public data sources about innovations yielded 113 components, an average of 19 each; while the comparatively lengthier CMA transcripts yielded 529 components in 21 innovations, an average of 25 each. Slightly more components were identified for successful innovations by the criteria above (22) than for “non-successful” innovation efforts identified by the criteria above (16). Compared with successful innovations, descriptions of non-successful innovation efforts included fewer components in solutions and resources created. This may be due to recall bias toward past successes. The 14 successful innovations represented a total of 293 components. Innovation efforts identified as partially successful and “not yet” successful nor non-successful represented a total of 267 components, an average of 33 each.

Under Schumpeter’s categories, four innovations were identiﬁed as relating to new markets, 10 to new materials/methods, 10 to new modes of organization, eight to new products, and eight to new sources of starting materials. An innovation could fall in more than one

Schumpeter category. Under the Henderson-Clark categories, seven innovations were identi-

ﬁed as incremental, six as architectural, six as modular, and eight as radical.

The change profiles in Table C.1 suggest that successful innovations consistently generated resources to relieve their targeted limits in proportions matching components in each of the industrial, social, and intellectual dimensions. The magnitudes of components in each dimension of successful solutions also corresponded in proportion with the magnitudes of components in each dimension of the motives, although less faithfully than the correspondence between limits and resources created. Each only partially successful innovation yielded resources created with magnitudes of components in dimensions insufficient to meet its limit. An analysis relating Schumpeter and Henderson-Clark categories to change profiles was given in (Li, 2009). 207

The framework distinguished characteristics of innovations in agreement with previous approaches. “Radical” changes have relatively heterogeneous motives, confront diverse limits, and generate varied resources; “incremental” changes have relatively homogeneous motives, confront narrow limits, and generate specific resources. (Those may be good definitions in general for radical and incremental innovations.) The OEE data (Table C.2) show that non-simple enhancements such as rearchitecting a web browser platform to use threaded processes affected more parts and people than simpler changes such as adding optional features to a web server or policy book for a relatively small number of users. Very few successful innovations produced resources in dimensions other than those suggested by their inspiring limits. The present method yielded results directly compatible with Henderson-Clark and Schumpeter models, but that observation is valuable to the present research only as preliminary validation of the present method treating superficially different kinds of purposeful change under one framework.

C.6 Results (OEE data)

The OEE enhancements were distributed in the following sectors: industry=4, government=3, academic=0, non-profit=3. In total, 112 data points were identified (Table C.2), with an average of 11 components describing each enhancement (minimum=11, maximum=42). On average, slightly fewer components were identified for non-successful enhancements (8) than successes

(10). ‘In progress’ enhancements averaged the largest number of identiﬁed components (28), perhaps because they had not ﬁnalized on their problems or implementation. The six successful enhancements represented a total of 61 components.

Under Schumpeter’s categories, one enhancement was identified as relating to new markets, two to new materials/methods, one to new modes of organization, six to new products, and one to new sources. An enhancement could occupy more than one Schumpeter category. Under the Henderson-Clark categories, four enhancements were identified as incremental, three were 208 identified as architectural, six were identified as modular, and two were identified as radical.

Change proﬁles in Table C.2 suggest that successful enhancements, like successful innovations, consistently generate resources to relieve their intended limits in matching proportions of components in each dimension. Again, each partially successful or non-successful enhancement generated resources in components of the dimensions insufﬁcient to meet its limit.

The substantial portions of in situ descriptions of enhancements from the OEE Bugzilla and mailing list data were much shorter than retrospective descriptions of innovations from the CMA interview data. The OEE data were not hour-long interviews rationalizing previous successes, but concise messages explaining objectives, actions, and fairly immediate outcomes in near real time. With the exception of initial requests for changes, or summaries of proposed changes, both of which would be pre-meditated, the OEE data were not ﬁltered retrospective commentaries. The OEPs used and generated source code, concepts and use cases, but did not generally manifest new resources for use outside of the OEPs. It was not until the end of the processes, when completed enhancements were made available for adopters, that new resources were presented to meet the original identiﬁed limits.

The predominant limit among OEE enhancements was industrial, since software code or policies to enable new features or capabilities concerned the re-arrangement of a kind of machinery. Implementing new code required developing new intellectual concepts, but the purposes of the enhancements which did so were not usually to develop the new concepts themselves. In cases where limits and motives included an intellectual component, it was required as much for the contributors to re-think a part of their understanding of their systems as it was for potential adopters to grasp those changes in the relationships between parts of the systems.

The OEE data included speciﬁc cases in which an enhancement initially failed but then succeeded later. Such cases were not directly available in the CMA narrative data as intermediate stages were not described in detail. Although there are only two pairs of success/failure cases in the OEE data, their change proﬁles recall those of successes and non-successes in the CMA 209 cases. Of note, OEE Case 3 indicates that shepherds had planned and implemented a different enhancement (in which their plan would have followed a successful enhancement pattern) than they had presented to the stakeholders (in which the enhancement was experienced as a failure). This supports the proposition that the enhancement which is communicated is of more importance to adoption than the potential or actual enhancement which is implemented.

C.7 Analysis

Since the OEE change proﬁles relate in the same way as the CMA data to enhancement success, and to the Henderson-Clark and to the Schumpeter innovation categories, H1 appears to be supported for the OEE enhancements, but perhaps less strongly than for CMA innovations.

A more precise statement of H1 would be: Successful innovations (or enhancements) have change proﬁles containing solutions and resources created in dimensions corresponding in variety and magnitude to the dimensions of the motives and limits, respectively.

Table C.3: Characteristics of enhancements from the open enhancement environments. Case # Start Sector Activity Users must Sourcea Idea Main First Adopted date adopt? Source Delay Impression 0 2008-02- N Apache log rotation Optional Internal, Bureaucrat Process Finished Yes 14 trigger (44427) External Prototype 1 2005-04- N Apache SNI non-secure Optional Community Leader Process Finished Yes 21 (34607) Standard Prototype 1a 2006-04- N Apache SNI secure Optional Com. Std, Contributor External Working Yes 20 (34607) Bus. Need Standard Prototype 2 2006-02- I Firefox secure connection Yes Internal Bureaucrat Ext. Use Concept & Yes 14 warning (327181) Stakeholder Case Drawings 3 2007-11- I Firefox “Home” button Yes Internal Leader Ext. Use Finished No 16 move (404109) Stakeholder Case Prototype [3] 2007-11- I Firefox “Home” button [Optional] Internal Leader [Process] Finished No 16 move (as intended) Stakeholder Prototype 4 2000-05- I Threaded document windows Yes External Stakeholder Int. UC/ Implem’n No 27 (40848) Stakeholder Bureaucrat Concept 4a 2009-05- I Threaded document windows Yes Internal Leader Technical Concept & Partial 05 (“Electrolysis”) Stakeholder Work Plans 5 2008-05- G ARIN Min. Allocation in Optional Business Stakeholder Scope Finished Yes 16 Caribbean (2008-4) Standard Ambiguity Prototype 6 2008-08- G ARIN WHOIS integrity Yes Internal Contributor Ext. Finished No 26 (2008-7) Stakeholder UC/Legal Prototype Ambiguity 7 2009-03- G ARIN Identify invalid Yes Internal Std., Contributor Process Finished Yes 23 WHOIS POC (2008-7) Bus. need Prototype a: internal stakeholder, external stakeholder, community standard, business need

11 210

Departing from the above framework and returning brieﬂy to the rich texts, Table C.3 summarizes data about the OEE enhancements described in detail in Chapter 4. In particular, it tabulates the communications occurred in OEPs according to direct and alternative variables examined in the overarching model for the present research.

Ultimate success or failure of an enhancement did not seem to co-occur with internal, external, or standards-based source of ideas; the role of the ideator; the kinds of delay experienced; nor the state of the idea when ﬁrst presented. All cases of non-successful enhancements included consideration of internal or external use cases as a factor which stalled the OEP, but not all instances in which consideration of use cases stalled the OEP resulted in non-successful enhancements. Ideas for non-compulsory new features seemed to achieve success more easily than ideas forcing changes, as did ideas which were presented in forms which allowed substantial stakeholder input. Communication about administrative matters were both frequent and infrequent for both successful and non-successful enhancement attempts (Figures C.1 and

C.2).

Thus, such other factors which could affect success or failure do not appear fruitful as avenues of analysis at the present small sample size of OEPs.

C.7.1 Comparing enhancements and innovations

Reasons behind enhancements appear to resemble reasons behind innovations, and accepted enhancements appear to resemble successful innovations. But those alone do not directly show that the processes between ideas and outcomes are comparable. They do suggest that OEE enhancements could be a particular form of innovation analytically interesting due to open availability of data about the process.

This method and framework provided information about two parts of the enhancement and innovation processes without any knowledge of their communications. The ﬁrst were factors which solicit an innovation or enhancement (limits, motives, resources used). These 211 data substantially describe Souder and Moenaert’s (1992) planning stage of their innovation process. The second were factors which indicate the success of innovations and enhancements

(creative change, solution, resources created). These data substantially describe Souder and

Moenaert’s (1992) development stage of their innovation process.

Thus, the motives and outcomes of enhancements and innovations appear comparable in kind. From the detailed OEP data and knowledge in the literature about entrepreneurs and organizations, some inferences are possible.

C.7.2 Shepherds, entrepreneurs, and bureaucracies

Schumpeter (1934, pp. 64, 68) saw that the appearance of new things may be explained by the recombination of existing things by entrepreneurs. Kauffman (2000, ch. 9) highlights the same idea in terms of development trajectories inﬂuenced by being able to build new things from combinations of previously combined things. In both cases, the new things are not truly novel in themselves, but are made known to the market by the creative efforts imputed by individual and groups of entrepreneurs. Among the OEEs studied, shepherds ﬁll a similar, if not analogous role to Schumpeter’s entrepreneurs who were informants in the CMA data.

Shepherds and entrepreneurs combined existing knowledge and software (including policy) to enable new capabilities, and were required to communicate with potential adopters to understand their needs, and to bring their enhancements and innovations to market. The act of externalizing knowledge, therefore, is essential for the advancement of knowledge itself among groups of collaborative individuals, in both social and industrial contexts (e.g., Storper and

Venables, 2004). Since both OEE and CMA entrepreneurs collaborated with others in pre- or non-commercial environments prior to having ﬁnished products, relationships built on social capital appear important to both kinds of processes. Communication, the vehicle of knowledge transfer, is therefore also critical for development of new things among both the OEEs and

CMA environments. 212

Rogers enthusiastically embraced the idea of the innovator to include the adopters of the innovation. Rogers describes innovators as venturesome, interested in new ideas, cosmopolite and technically capable individuals who are willing to take risks with new ideas (2003, pp. 282–

283). Such is also the description of shepherds in the OEEs, who patrol discussion lists and

Bugzillas for ideas that interest them; invest time, effort and reputation to support a small number of enhancements; and commit to bringing them to users over months or years. Rogers’ innovator performs several key communication roles: as a gatekeeper of knowledge flow into his social network, as a connector of disperse individuals, as an influential member of cliques of innovative people, and as one of the first users to feed information back to the manufacturer by being the earliest adopter. OEE shepherds also perform similar functions, by admitting or rejecting suggestions and use cases from users, by judging and choosing which enhancements advance, and by first adopting enhancements through models and testing.

The positive comparison between the work of shepherds and the work of entrepreneurs holds following Schumpeter’s ﬁrst conception of private individuals in the innovation development process as it contrasted with his second conception of innovators as large companies with the resources and capital to invest in organized research and development. Recall that the OEEs started as small, almost personal, efforts which grew supporting bureaucracies as needed. Also recall that the OEEs continue to permit modules to be developed by private personal individuals before being assimilated by the central organization.

Schumpeter claimed that ousting of the entrepreneur by a “perfectly bureaucratized giant industrial unit” (Schumpeter, 1950, pg. 134) is said to deprive entrepreneurs of both income and their function within the context of a stable innovation undergoing only incremental improvements. Indeed, cases in Chapter 4 have shown that the OEE bureaucracies could react slowly to radical enhancements requested from outside, providing neither beneﬁts nor recognition for their ideas (and often resisting them) despite the OEEs being open environments. On the other hand, the bureaucracies could also move much too quickly on some ideas. 213

For research and development functions to scale up in breadth and depth—both around a particular innovation or in the market in general—they must be carried out by more or less organized groups of people sharing a common goal (Schumpeter, 1950, pg. 133) with a sufficient capital infrastructure to conduct large-scale research. Such a pattern of organizing groups of groups of contributors was observed in all three OEEs, reflected in the decision-making about supporting particular enhancements in the context of the whole project or organization. The same data which informed the infrastructure outlined in Chapter 3 also records how the OEEs became organized in their present forms out of needs to match particular goals to specialist expertise and resources. Chapter 4 showed cases in which OEEs, like firms, may depend on a small number of competent leaders or internal entrepreneurs as drivers (or blockers) of change.

C.7.3 Validity and reliability

Barringer et al. (2005) raised two kinds of concerns about the validity of inferences obtained from post-hoc narrative data: structure and scope of the data source with respect to representing the phenomena we seek to study, and a possible self-desirability bias in self reported actions and requests communicated.

First, since the CMA narratives were collected as responses to standard questionnaire guidelines as prescribed by the project, there is potential concern about internal consistency within that set of data. However, a preliminary reading and analysis of a subset of the CMA data indicated that they provided sufﬁciently comparable information about innovations to inform the variables of this thesis (what innovation was initiated, how and why; along with the means, implementation and perceived success of the innovation).

Second, some public working documents and communications were self-promotional so there was the clear potential for self-desirability bias. However, although the conﬁdential CMA interviews offered no beneﬁt of self-promotion, many interviewees referred to or simply reit- erated content in public supporting documents about their innovations. It was not observable 214 from the data itself whether an informant had been promotional to the point of being deceptive, nor that any deception would be systematic or coordinated among multiple interviewees. Truth in advertising laws and reputations would preclude outright lies in public disclosures and it is possible to externally examine the purported outcomes of innovation in most cases.

Incomplete recall is a concern with the CMA data since the narratives and documents about innovations were given at both different points in real time, and at different intervals after the described innovations were implemented. However, the principals of salience again bring the most important features (at the time the narrative and documents is given) to the front. Given that past innovations could have been perceived through the problems of the present, and that the selection of time horizons during which to look for changes and their effects will always have attached beneﬁts and drawbacks, this research frames the time of the interview and innovative activity as mostly constant. It was recognised that data did not describe a snapshot of an innovation within any particular system in time, but rather categorizes the broad kinds, circumstances and communication contents of innovations as they have been encountered. In- deed, descriptions of the more recent (and prospective) innovations generated a larger volume of data points, but the difference was in magnitude and not in kind or relative proportions.

C.7.4 Implications

If, by chance, communications in OEEs are like of those employed in the innovation processes employed at the CMA firms (or firms in general), then the major findings of the present work would provide an additional layer of understanding about the kinds of innovation process with which the literature is already familiar. Bordia (1997) found that among diverse kinds of organizations, computer-mediated communications tended to first supplement, and then displace face to face interactions, without clearly affecting productivity or outcomes. By contrast, Kerra and Murthy (2009) find that individuals within organizations providing the choice of CMC or face to face channels preferred the latter (and more effective) channels for business problem 215 solving purposes. If CMC in OEEs differs much from communication practiced in innovative

ﬁrms, then the present work would describe an alternative pattern by which international collaborations could successfully manage their innovation processes. In either case, considering how OEEs use CMC is worthwhile if for no other reason that CMC has enabled the OEEs to develop with few resources innovations adopted by hundreds of millions of people.

The similarities and differences between OEPs and innovation processes identified above suggests placing the OEEs studied near the strongly CMC reliant extreme of face to face organizations. The Mozilla OEE, having a brick and mortar headquarters, would be most similar to the CMA firms, while Apache and some of the third party modules with no physical presence locate on the opposite, exclusively CMC, extreme among OEEs. There was little variation in communications or outcomes among OEEs with differing infrastructures in which CMC are embedded (Chapter 3), nor among change profiles and successes of innovations among CMA

ﬁrms whose primary activities are required to be highly CMC-reliant (e.g., multimedia) and those who may be able to do without as much reliance on CMC (e.g., automobile retailing).

More research, particularly details about how social capital and corporate culture, would be required to conﬁdently situate the present research in the study of organizations.

C.8 Conclusions

Broadly, this appendix supports observations from previous chapters that success of enhancements depends on how potential adopters understand the connection between the needs an enhancement claims to ﬁll, and the capabilities an enhancement provides. These observations also reiterate that enhancements seeking simple outcomes (few components and small magnitudes) engage a more limited section of the OEE communities than enhancements seeking more elaborate outcomes. This conﬁrms intuition that to understand and meet potential adopters’ limits with an enhancement implies that shepherds must communicate about how 216 adopters may use that enhancement. 217

Appendix D

Glossary

AC: ARIN Advisory Council

ACSP: ARIN Consultation and Suggestion Process

AIM: America On-Line (AOL) Instant Messenger

ARIN: American Registry for Internet Numbers

ASF: Apache Software Foundation

Bugzilla: The name of a database platform which tracks software defects, enhancements, and other information. Apache and Mozilla have each installed an instance of Bugzilla for their own use.

CMA: census metropolitan area

CMC: computer-mediated communication

HTTP: Hyper Text Transfer Protocol

IANA: Internet Assigned Numbers Authority

ICANN: Internet Corporation for Assigned Names and Numbers

IP: Internet Protocol

IPv6: Internet Protocol version 6

IRC: Internet relay chat

ISP: Internet service provider

ISRN: Innovations Systems Research Network

LRSA: ARIN Legacy Registration Services Agreement

NANOG: North American Network Operators Group

NGO: non-governmental organization 218

OECD: Organisation for Economic Co-operation and Development

OEE: open enhancement environment

OEP: open enhancement process

OpenSSL: Open Security Sockets Layer (project, library)

OSI: Open Source Initiative

OTC: one-time contributor

PDP: ARIN Policy Development Process plug-in: a third-party module providing additional optional functions

PMC: ASF Project Management Committee

POC: WHOIS point of contact

PPML: ARIN Public Policy Mailing List

RIR: Regional Internet registry

RSA: ARIN Registration Services Agreement

SNI: Server Name Indication

WHOIS: a protocol for querying databases of Internet resource registrants