Standardization serves a as a means to improve overall quality of life through the economies of scale gained from the pervasive adoption of technical solutions. It enables competition by facilitating interoperability between products of different vendors. The wider open source community develops free and open source software (FOSS) in a global upstream/downstream model that similarly benefits society as a public good. FOSS and standards setting organizations (SSOs) are both instruments causing standardizing effects. Innovators and policy-makers assume that a mutually beneficial collaboration between them is desirable. However, their exact relationship is not fully understood, especially when and how FOSS and SSOs complement each other, or displace each other as competitors. To be able to compare FOSS and SSOs, our study develops a phase model of standardization that is applicable to both approaches, and applies this model to compare the strengths and weaknesses of FOSS and SSOs against common opportunities and threats in the ICT sector. Based on qualitative expert interviews with FOSS and SSO representatives, the synthesis of the separate results support conclusions from a product, a process and a societal perspective. The study identifies cost of change as a key determinant for the efficacy of each approach. It concludes that FOSS and SSOs create complementary products, compete for efficiency of the standardization process, and are both independent and complementary standardization instruments available to industry and influenceable by policy-makers. The paper closes with a discussion of possible implications relevant to businesses, the wider open source community, SSOs and policy-makers.Contents
1. Technical standardization in the ICT sector
2. Scope and literature review
3. Model and objectives
4. Qualitative methodology based on expert interviews
5. Empirical analysis of the interview results
6. SSO and FOSS communities — Partners or competitors?
7. Managerial and policy recommendations
8. Summary
1. Technical standardization in the ICT sector
SSOs have a long-standing history in facilitating technical innovation dating back more than one hundred years (Luxbacher, 2017). The recognized positive economic, social and political impact of standardization resulted in strong ties between industry, government and research institutions and lead to the establishment of an integrated network of national standards bodies, European standards bodies, sector-specific SSOs and the International Organization for Standardization (ISO). Today, SSOs are an integral societal institution. We encounter standards in every moment of our daily lives. They increasingly define how we communicate with each other, and what quality to expect from our food, shelter, transportation, health care, banking and environment. Standards developed by ISO, IEC and ITU in cooperation with national standards bodies define requirements for environmental protection [1], information security [2] or quality management [3]. Conforming with these formal standards means adopting an acknowledged state of the art or technical consensus. It is a common expectation by industry and consumers and potentially a requirement by regulators or public procurement (Weber, 2004).
In contrast, FOSS is a relatively new phenomenon, even though it represents a tradition of collaboration in software development that predates proprietary software. It has gained widespread recognition because of its evident ability to produce high quality, interoperable and widely adopted software at a high pace of innovation (Lerner and Tirole, 2005). The Linux operating system or the Eclipse family of software engineering products have become de facto standards. FOSS success stories affect all walks of life: Firefox helps citizens protect their privacy. Android has been adopted by the mobile industry as the most widely used device platform. Much of the critical infrastructure [4] of the Internet is based itself on the results of diverse participants voluntarily collaborating in communities on FOSS solutions.
Since both SSO and FOSS drive innovation (Kappos and Harrington, 2019), it is commonly assumed that ”(i)ntegration between open source projects and standards development processes is a win-win situation: On one side the alignment of open source and standardization can speedup the standards development process and the take-up of ICT standards (especially for SMEs) and on the other side standards can provide for interoperability of open source software implementations.“ (European Commission, 2017a) There are many concrete examples of successful collaboration between SSO and FOSS, especially in the development of Internet and Web technologies. Of particular research interest are the dynamic interaction between SSO and FOSS that drives innovation in the ICT sector as well as the opportunities for collaboration based on where and how SSO and FOSS can collaborate and where are they strategic alternatives with regards to facilitating effective standards. The dynamic interaction has been explored in a recent report by the European Commission (EC) (Blind and Boehm, 2019). Our study complements this report by focusing on the opportunities for collaboration.
We assume that by breaking down the two alternative processes that create a standardizing effect into more generic phases it is possible to create a model where SSO and FOSS activities that result in the diffusion of a standard can be systematically compared. By combining the individual author’s perspectives of working in standard-setting organizations and of being a FOSS contributor as well as the perspectives of experts from SSOs and FOSS, we attempt to compare the strengths and weaknesses of the two approaches in a scientific, but also pragmatic and practically applicable way.
We approach the problem by developing a generalized standardization model that is subdivided into ideation, implementation, specification and diffusion as separate phases (see section 3.4). We assume that both SSO and FOSS activities touch upon these phases, but not necessarily in the same order of events. Through semi-structured, qualitative expert interviews with representatives of SSO that are involved in evaluating the impact of open source approaches in their organizations and FOSS contributors with experience in standardization activities of their communities, we gather empirical data to perform two separate strengths, weaknesses, opportunities and threats (SWOT) analyses. The results are then contrasted in a comparative analysis to identify where the two constituencies complement each other, and where they compete for relevance. The results are discussed separately regarding the created products, the processes and norms applied in the organizations, and from a societal perspective.
We find that FOSS products commonly implement a multitude of formal standards and therefore complement the results of the work of SSOs. However we also find that both represent systematically different approaches where participants choose between centralized and hierarchical as opposed to decentralized and meritocratic processes, and therefore represent competing mechanisms. Finally, we conclude that from a societal perspective, both SSO and FOSS approaches are effective standardization instruments, offering policy-makers and enterprises a choice of which approach to support to drive innovation, to ensure competitive markets or to enforce regulatory goals.
2. Scope and literature review
Both SSO and FOSS continue to evolve at a fast pace. However, a noticeable gap in FOSS research after 2010 has been identified (Blind and Boehm, 2019), in particular in relation to the more recent industrialisation of FOSS that increases the interaction with standards development. FOSS also becomes relevant for new audiences. Acknowledging this trend, our paper establishes common theoretical ground by reiterating where necessary current understandings of basic terminology regarding SSO and FOSS.
2.1. Standardization and standards setting
Standardization is the process of creating specifications and implementations for technical solutions with the aim to reach wide adoption in the market. Standard in this paper means a technical standard that describes requirements towards technical systems, built of a combination of hardware and software (Blind and Mangelsdorf, 2016). Hardware refers to physical goods that require labor and materials to build, resulting in limited supply. Software are information goods that are “costly to produce but cheap to reproduce” (Varian, 1998), resulting in virtually unlimited supply. Related to computing technology, standards may describe the functionality of software systems (software standards), or the interaction between software or hardware systems (interface standards), or attributes of hardware (hardware standards). Technical standards that interact with the work of FOSS communities are either software standards or interface standards, not hardware standards. Communities may produce open hardware designs which are information goods [5], or even engage in producing such hardware, however this is not the usual modus operandi and not discussed in this paper.
The ongoing commoditization of hardware fosters a shift from hardware standards to software standards implemented using off-the-shelf components. The increasing relevance of software standards is evident for example in the transition to software-defined networking (ETSI, 2012), or the use of container technologies in data centers that abstract away hardware interfaces all the way to current trends like server-less computing or function-as-a-service. Ensuring interoperability, as in “the ability to transfer and render useful data and other information across systems [...], applications, or components” (Gasser and Palfrey, 2007), is commonly identified as a central aim of standards setting. Specifications of data formats, hardware interfaces and communication protocols all enable interoperability between devices or programs following these standards. Both SSOs and FOSS communities aim to achieve interoperability, using different and partially competing approaches. Systems can gain interoperability by either following a common specification, which requires a consensus based formal process and is the formal standardization approach of SSOs, or by using one or more common implementations, the informal standardization process which is closer to how FOSS communities approach the problem, or a combination of the two. By specifying first, standards enable implementers to create a multitude of standard-compliant products that are interoperable and compete in the market. Due to the relatively time-consuming formal standardization process, a formal standard is not changed or withdrawn quickly, which on the one hand offers investment security, but often lacks the flexibility to quickly react to technical advancements. By implementing first, FOSS products facilitate interoperability through a shared, freely licensed implementation defining a non-differentiating state of the art. SSOs facilitate a process where stakeholders agree on and formulate a written specification (the standard), and leave it to implementers to create products that follow the standard after it has been set. FOSS communities apply a “code first” approach, where the expectation is that participants produce “working code” and if necessary, author a specification after a working reference implementation exists. Contributors usually do not create code with the goal of setting standards, however the various initiatives attempting to solve a specific technical problem typically converge towards a dominant design that finds wide adoption (Suárez and Utterback, 1995). While SSOs often assume that a formal or de jure standard is the precondition for standardization, FOSS communities achieve standardizing effects and create informal or de facto standards by implementing first.
Because of this difference in understanding, the standardization phase model used in this study to relate formal and de facto standardization to each other does not assume that specification precedes implementation in the sense that implementation has to be based on an existing specification. Both formal and de facto standardization are seen as comparatively effective paths to create a standardizing effect.
Literature and common practice differentiate between de jure and de facto standards, which differ in the way they are developed, and in the effects they have on the market. Formal (de jure) standards are the result of committee work in recognized SSO. They are developed in a usually complex, consensus-driven process open to a variety of often diverse and competing stakeholders (Blind, 2002). The process differs regarding the market and sector context as well as the often very different goals and strategies of the stakeholders involved (Folmer, et al., 2009). Established platforms for multi-stakeholder elaboration implement a formalized and partly regulated process in which finding a common denominator can last several years. This stable, formalized process is a strength of SSO, as it alleviates anti-trust concerns and enables transparency, accessibility for all stakeholders and high-quality standards. It is also a weakness, as SSO are in some cases not able to keep up with accelerating innovation cycles (Shin, et al., 2015).
More flexible informal standardization has evolved and broadened the standardization landscape (Wiegmann, et al., 2017). By reaching a significant or dominant market share, technologies that are developed by individual market players, consortia or unrecognized SSO become de facto standards (Pohlmann, 2013). De facto standards emerge from competition in markets, industry alliances, market creating activities of intermediaries, technical specifications issued by influential market actors, by consumer choices and other factors (Baron and Spulber, 2018). Means like contracting, advertising and pricing help disseminate the technology at a large scale (Katz and Shapiro, 1986; Spulber, 2008). De facto standards are differentiated into private standards that are created by individual organizations and market standards that emerge through competition. Both are not initially defined by a formal SSO (Baron and Spulber, 2018). The fact that there is no formal definition of what a de facto standard is and how it emerges adds to the complexity of a systematic assessment. De jure standards are set by recognized formal national or international SSOs or through governmental regulation. Government agencies may ratify and SSO may adopt and formalize existing de facto standards based on their acceptance in the market, which transforms them into formal standards (Baron and Spulber, 2018).
The unifying aspect of these approaches is that they primarily focus on the creation of specifications. The strict separation of formal and informal standardization has been questioned, underlining that actors chose between participation in SSO processes and in de facto standards setting market processes and often developing a hybrid approach of parallel implementation and specification (de Vries, et al., 2008). Participants have a choice between formal standardization, informal standardization and a flexible combination of the two. In this paper, the distinction between de jure and de facto standardization was found to be less important than the capability of a recognized or unrecognized SSO or industry consortium to produce specifications that are useful for the targeted market segments. There are far more consortia and fora than de jure SSO. Some SSO support both accredited and unaccredited working groups. They are however renowned for the specifications they produce, and much less for their governance and formal recognition.
2.2. Creating industry standards through joint implementation
The FOSS communities considered in this paper produce information goods, predominantly computer programs, in a collaborative process based on voluntary participation and often highly fluid and less structured than typical SSOs. Their products are public goods called free software (FS) because they are distributed under a license that provides the user with the freedoms to use, study, modify and redistribute these goods (Stallman, 2002). What these freedoms entail is detailed in the Open Source Definition as set by the Open Source Initiative. The commonly used term open source originally describes a campaign to promote FS to business (Perens, 2017). Both “free software” and “open source” (in this paper jointly and synonymously referred to as FOSS) today are proper terms of art that refer to software that is distributed under a license which complies with the Open Source Definition. The Open Source Initiative is the steward that approves licenses for being compliant with this definition.
FOSS community in this context describes a group of contributors and optionally their organizational entities that participate in the creation of specific FOSS goods voluntarily. Both individuals and entities such as businesses, universities and governments participate in FOSS production processes in a modus commonly referred to as peer production (Benkler, 2002). The social and behavioral norms and decision-making processes applied by the group of participants are described by the governance of the community. Absent of an outside authority, governance is usually established by the group itself, with all authority born from within the community. Since all authority in the community is self-determined, behavior according to community governance norms set out informally or formally for example in codes of conduct is a prerequisite to participation. Violation of community norms is regarded as anti-social behavior.
While individual communities focus on the creation of specific software or solutions, there is a strong habit of inter-community collaboration, as evident in regular large-scale conferences like FOSDEM [6] that attract thousands of contributors from a variety of backgrounds. The common understanding between them is referred to as the open source way or sometimes as open source culture, resulting in an understanding of the wider Open Source community as an aggregate of the individuals and organizations participating in FOSS development with an interest to foster and protect it. The wider Open Source community jointly creates large and complex software products like Linux distributions that combine the products of possibly thousands of individual communities in the above sense. Prerequisite to this is a common understanding of how to create derivative and aggregate works that is based on the Open Source Definition and other fundamental open source norms referring to shared stewardship and access not only of the software source code, but also to the community development processes. Based on that the communities establish an upstream/downstream model of how their development processes interact with others, enabling cross-community collaboration in complex many-to-many relationships (see Section 5.2). Adherence to this common understanding is expected from all participating actors.
All FOSS licenses grant recipients of the software the rights to use, study, modify and redistribute it. Once a piece of software is released under a FOSS license, it will be free for everybody to use, forever (Fogel, 2005). While some FOSS licenses allow proprietary derivatives that themselves are not FOSS, the underlying work cannot be retracted from the market (or “un-open-sourced”) once copies of it are in circulation. The usage rights embodied in FOSS licenses make the software non-excludable and non-rivalrous, so that the software becomes a public good through the application of the terms of the license (Weber, 2004). Inherently, FOSS communities produce state of the art, but non-differentiating technology. The technology is state of the art if the community manages to develop new and innovative solutions. Competition for contributors and adoption drives communities towards excellence and leading technology to be adopted as de facto standards. The technology is however not differentiating, because the software is available to everybody and therefore cannot differentiate between competing products. To differentiate, implementers need to combine the FOSS product in new and innovative ways or with other differentiating product features. All FOSS produced over time contributes to a common body of knowledge that grows steadily since none of its elements can ever disappear. By competing for the adoption of their technologies, communities trigger fast innovation cycles. For that reason, the process that leads to FOSS is linked to innovation not just as a method, but also as a strategy (Schrape, 2019). Wherever the state of the art can be improved, existing solutions can expect to be challenged. Once a dominant design emerges, it is quickly adopted across the industry. It becomes a de facto standard and a commodity. The FOSS community process is collaborative in organization, but competitive in nature. Since it produces an ever-growing commons of free technology goods, it is considered beneficial to the common good in various jurisdictions. Many community organizations like The Document Foundation or KDE e.V. are not just not-for-profit organizations but also recognized as charitable (in the United States trade associations (501(c)(6)) are more common).
Both SSOs and FOSS communities differentiate between their products, the outcome of their activities, and their processes, which describe how these outcomes are created and agreed upon. The European Interoperability Framework for example imposes requirements for open standards regarding the standards setting process (“all stakeholders have the opportunity to contribute to the development of the specification and a public review is part of the decision-making process”), and the licensing of the product (“intellectual property rights to the specification are licensed on fair, reasonable and non-discriminatory (FRAND) terms, in a way that allows implementation in both proprietary and open source software, and preferably on a royalty-free basis”) (European Commission, 2017b). In this study, the interaction between SSOs and FOSS communities will in a similar fashion be reviewed separately from a product and process perspective.
2.3. Existing interactions between Open Source and standardization
Research on the interaction between FOSS and SSO focuses on the compatibility of FOSS licensing terms with those of standards. A key aspect in this debate is the question of under what conditions a technical standard may be implemented as FOSS. Lundell, et al. (2015) conclude that uncertainty about the identity of rights holders and the patent claims reading on the standard are associated with significant risks for implementers of FOSS, and recommend a royalty-free licensing option of standards essential patent (SEP) for FOSS implementations. The discussion about what constitutes an open standard focuses on the relationship between the licensing terms of the specifications of the standard and related SEP and the viability of the FOSS model of collaboration under these terms. While it seems to be accepted that “(t)he availability of an OSS implementation will spur quicker adoption and acceptance of the standard as everyone has easy access to the implementation of the standard and so can try and test it out” (Almeida, et al., 2011), there is no agreement yet on the licensing terms required to facilitate FOSS implementations. It can be construed that specification and implementation should be considered separate in terms of licensing policy, however practices like automatic sub-licensing of derivative works and the absence of license negotiations and monitoring of individual licenses or licensees are considered essential to the FOSS model of collaboration (Ghosh, 2011).
Cooperation between SSO and FOSS appears desirable because of the fast pace of innovation in FOSS and the obvious utility of an ever-growing body of public software goods. Compatibility of licensing terms is only one aspect of enabling this cooperation. In contributing to FOSS projects, participants do not contribute with the expectation of obtaining future license revenue from that contribution. Actors contribute voluntarily following their self-interest and on the basis that others will be contributing on a similar basis. Information asymmetries regarding access to the underlying technology as well as differences in cultural norms and expectations may affect their motivation to do so, possibly to the point of inhibiting successful collaboration. This may require facilitation, incubation of projects and coordinated policy-making to achieve successful cooperation between SSO and FOSS (OpenForum Europe, 2017).
Overall, while the question of legal compatibility has been discussed extensively, and the usefulness of collaboration between SSO and FOSS communities has been established, there is not much research yet on what benefits both sides would realize from such cooperation. Successful examples exist that represent a special case of standards competition (Blind, 2011). The process of developing the Open Document Format for Office Applications (OpenDocument) standard brings together community actors and industry at OASIS, the results are later formalized at ISO (OASIS OpenDocument Technical Committee, 2009). The IETF considers itself an open standards organization without formal membership, and develops Internet and network standards like TCP/IP or the widely used Secure Shell (SSH) protocol. World Wide Web Consortium (W3C) specifies formats like CSS and XML with widely deployed FOSS implementations like Webkit or Gecko. Open Source Mano is an European Telecommunications Standards Institute (ETSI)-hosted initiative to develop an Open Source NFV Management and Orchestration (MANO) software stack (ETSI, 2012). Collaborations of this kind are however not ubiquitous or common. This paper will investigate what promotes and what inhibits larger-scale cooperation and discuss potential implications relevant to SSO, FOSS, regulators and enterprises.
A fundamental research objective of this study is to establish a generalized phase model of standardization that can be applied to various standardization instruments, including formal standardization in SSO as well as FOSS processes. De facto standardization follows a relatively undefined process, while formal standardization processes are usually well-defined and strictly followed. By applying a common standardization phase model, SSO and FOSS activities that cause a standardizing effect become comparable. The phase model supports identifying activities where SSO and FOSS complement each other and where they are in competition. This model is then used to describe differing approaches of standardization efforts that are identified during qualitative interviews. Finally, we aim to discuss possible implications relevant to policy-makers, businesses, SSO and FOSS communities on how position and adapt their organizations.
3.1. Early and late standardization
Most definitions of standards, including that applied by ISO, emphasize both the document character and the formal approval processes for it to become effective. ISO/IEC Guide 2:2004 defines a standard as “a document, established by consensus and approved by a recognized body, that provides, for common and repeated use, rules, guidelines or characteristics for activities or their results, aimed at the achievement of the optimum degree of order in a given context.” By including features that conform to such standards, products from different companies can benefit from network effects. A common thought model is that the standard is embodied in a specification, and that standard-compliant products implement this specigication. For de facto standards, these events do not necessarily occur in that order. Products may be implemented, introduced in the market and become successful with a specification added as an afterthought. This indicates that innovations that become standards will exhibit implementation and specification phases, however the order is not predetermined. We use the term early standardization if the specification is created first and then implemented, late standardization if the implementation is created first and then formally specified and parallel standardization if specification and implementations are created at the same time (Lundell and Gamalielsson, 2017).
This observation leads to the hypothesis that processes that cause a standardizing effect proceed through a set of relatively generic phases, and that different approaches to standardization differ in the order of events in which those phases occur. A standardizing effect on a market segment, an industry sector or society as a whole in this context describes the transition caused by a standardization instrument from a situation where a need for standardization is perceived to a situation where that need was satisfied by the widespread diffusion of a standard. The need for standardization may arise from various governmental, societal or market motives (Blind and Mangelsdorf, 2016).
Such instruments cause a standardizing effect by influencing market actors to adopt common technical solutions. The influence could be manifested in an intervention through authority, for example in the form of governmentally enforced safety standards, or in an extreme case through the order of a dictator. Compared to that, formal standard setting in SSO is preferred, as it replaces the need for an intervention through authority with a consensus- or market-driven platform based on voluntary participation and involving a variety of stakeholders. Other instruments exist next to formal standardization in recognized SSOs. Standardizing effects are also caused by normalized customs and practices enforced by tradition, self-regulation, codes of behavior that are prevalent in some industry sectors, especially trade, but also industrial consortia, professional charters or FOSS governance (Jenkins, 2001).
To avoid the nomenclatorial confusion that stems from the customary use of the term “standard” in the sense of an approved document as well as a widely adopted technical solution, we will use the term standard for a dominantly used solution to a technical problem, the term specification for the document that describes this solution, and the term implementation for a product that embodies the standard according to the specification. Other interpretations of these terms are possible. For some readers, the term “standardization” typically refers to the technical specification development process. However, standardization may be achieved in different ways, sometimes completely without a priori specification. It would defeat the purpose of this study to reduce the understanding of the term standard to a formalized written specification. It would assume that specification precedes implementation, and exclude most de facto standards, especially FOSS products.
3.2. Interoperability in software and interface standards
Especially de facto standardization does not follow a common script that may be easily recognized or replicated by competitors. Market forces determine the success of a de facto standard based on the availability of products and technology, marketing skills and timing. Any attempt to put together a recipe with these ingredients would end in speculation (Spivak and Brenner, 2001). In relation to FOSS, this difficulty in describing a common model of the development of de facto standards is aggravated by an observable shift in what is being developed as a standard from common data formats to communication protocols to joint implementations.
In reaction to the dominance of specific applications in the ICT sector, the wider Open Source community initially approached the problem of recreating a competitive environment by developing standard data formats, and lobbying for dominant commercial products to support these. The OpenDocument standard opened the market for office productivity suites by challenging Microsoft Office (OASIS OpenDocument Technical Committee, 2009). The existence of such strong de facto standards implemented in dominant proprietary applications may be attributed to the explosive historical development of the personal computer market.
Widespread use of networked applications increased competition in the ICT sector by reducing the dependency on specific file formats. Instead, interoperability was achieved by enabling communication between different applications through standardized protocols. A relatively large and diverse number of stakeholders was involved in creating these protocols as open and royalty free standards, for example during the developing of the XML standard at the W3C (W3C, 2015).
With the wider adoption of FOSS in enterprise contexts, more advanced forms of industry collaboration established themselves. Open Source focused umbrella organizations like the Eclipse Foundation or the Linux Foundation enabled direct, continuous collaboration on the development of FOSS in large consortia of otherwise competing participants. The resulting body of non-differentiating commodity software today provides the foundation for proprietary commercial products built on top of them. The focus on standards setting shifted again from protocols to joint implementation. Today, many of these consortia embrace a “code first” philosophy and consider specification not only as an afterthought, but as a reason for community fragmentation. Fragmentation refers to a situation where the wider community develops competing implementations of the same technical solution, leading to a race for adoption and fewer contributors to each individual single product. This is considered a waste of resources, since in FOSS one jointly developed implementation is available to everybody, and competition for market share as such is pointless in the commons (Parker-Johnson and Doiron, 2018).
3.3. Continuous non-differentiating cooperation
Instead of competing for market share with standards-compliant products by different vendors, FOSS solutions compete for adoption in the upstream/downstream model and for contributors. It is assumed today that computing devices ship with the larger part of their software stack based on collaboratively developed FOSS solutions. This approach to developing products that combine FOSS and proprietary source code, sometimes referred to as the “Pareto rule of software”, enables product developers to invest the majority of their research and development spending into differentiating product features.
The resulting model of collaboration on joint implementations between otherwise competing market actors differs from earlier approaches, especially pre-competitive research and development cooperation. Previously, industrial consortia established elaborate terms of reference to be able to engage in pre-competitive cooperation without raising concerns about possible collusion in the eyes of anti-trust authorities. Under the continuous non-differentiating cooperation model, enterprises now commit to continuous collaboration on the non-differentiating elements of the software stack with their competitors. Continuous-non-differentiating cooperation is a collaboration model implemented in FOSS communities and facilitated by FOSS foundations that enables otherwise competing market actors to continuously cooperate to develop a common software stack that serves as basic, non-differentiating technology prerequisite to products that combine free and proprietary software. In contrast to pre-competitive cooperation on the development of proprietary, differentiating products, anti-trust concerns are not relevant in the continous-non-differentiating cooperation model since collusion is impossible if the results are immediately available to the general public and the development process is generally open for participation to all interested parties. The possibility of forks limits the control individual entities can exercise over the development process.
Continuous non-differentiating cooperation significantly reduces the transaction cost of collaboration due to non-negotiable FOSS licensing terms, and eliminates welfare losses caused by the parallel development of products in a standards race where later only one will become an adopted standard. Implementers perceive a strong motivation to participate in the collaborative effort, since being able to share the majority of the software stack becomes a prerequisite to producing at similar cost as competitors and to competitive product pricing.
The emergence of the continuous non-differentiating cooperation model of collaboration influences the efficacy of standardization instruments. The utility of specifications is reduced if adopted standards are based on a single, quickly evolving joint implementation. Where such a development model is applicable, as for example with the Linux kernel, interoperability is a given from the start, so that specification does not serve that purpose anymore (Corbet and Kroah-Hartman, 2017). “As a ‘code first’ organization, AGL members are collaborating to build a brand new Linux-based software platform and application framework that serves as the de facto standard for the automotive industry. Adopting an open platform across the industry enables automakers and suppliers to share and reuse the same code base, which will reduce development costs, decrease time-to-market for new products and enable rapid innovation across the industry.” [7] In such scenarios, the product source code serves as the documentation. Specification may still be useful, however it needs to provide utility beyond interoperability, for example to document safety norms or other requirements.
3.4. A phase model of standardization
Formal standardization varies between different SSOs, but commonly proceeds through a combination of proposal, preparatory, committee, inquiry, approval and publication stages (Torti, 2016). Sometimes one or more proposals are submitted for a ballot vote. After identifying the proposal with the most support by experts, a working group discusses the suggested approaches to create the new standard. A draft is published for the public to comment on. The comments are discussed in the working group and a final version is being published (Torti, 2016). From this point on the standard is promoted and diffused into the market in order to gain wide market acceptance.
Structured processes of developing new technical solutions and become de facto standards regularly exhibit the phases of strategy development, idea generation, screening and evaluation, business analysis, product development, market testing and commercialization. These phases were adopted and modified throughout literature over time, and eventually condensed into three main steps, pre-development activities, product development, and testing and commercialization (von Stamm, 2008).
Based on these two descriptive models of standardization and product development processes, a technical specification that also is implemented and adopted in the market will iterate through four basic phases — ideation, specification, implementation and diffusion. The order of these phases depends on the strategies chosen by the stakeholders involved (see Section 3.1).
The starting point is marked by a perceived need for standardization that triggers a strategic decision of stakeholders to participate. The need may be caused by a lack of acceptable solutions at the micro level of individual actors, inefficiencies causing friction between actors that require interoperability at the macro level of markets or industry sectors, or by societal needs like requirements for safety or security standards. Micro and macro level needs represent a market pull for standardization, while societal needs often indicate a regulatory push. In any case, a need for standardization causes market participants to initiate the development of a technical solution by entering the ideation phase. During the ideation phase possible specification or implementation approaches and solutions are put forward, analyzed and evaluated until a promising initial concept has been identified. The process of de jure or de facto standardization begins with a proposed technical solution to a perceived need for standardization. This understanding is in line with the classic concept of the relationship of requirements, needs and demand in economics.
At this point the paths to an adopted standard already diverge. If the actors involved choose a formal standardization strategy, they enter the specification phase. Facilitated by a SSO, and applying the structured, disciplined and transparent process defined in their terms of reference, a specification for the wanted technical solution is authored and formally approved. Once this specification, the formal standard document, is published, it enables manufacturers to enter the implementation phase and compete with standard-compliant products that satisfy the original need for standardization. ITU-T V.24 (International Telecommunications Union [ITU], 2000) is an example for a formal technical standard that facilitated price competition by a multitude of implementers. This approach describes the early standardization model.
Alternatively, vendors may enter the implementation phase immediately by developing products and introducing them into the market without prior specification. The resulting products will not be systematically interoperable, even though market pressure may coerce vendors to afford their consumers a certain level of integration with competing products. Consumer demand and the assumed original need for standardization may motivate vendors to create formal specifications after their products have been introduced. By implementing first and specifying later, these vendors have chosen a late standardization model, as is common for FOSS communities. The Open Container Initiative for example was created after the dominant market position of the Docker container engine manifested an industry need for re-enabling competition through specifications of container runtimes and related products. It describes itself as “an open governance structure for the express purpose of creating open industry standards around container formats and runtime” (Open Container Initiative, 2016).
The process of technical standardization ends in adoption of one or multiple solutions to the original need for standardization by the demand side of the market. Once standards compliant products have reached diffusion, market participants engage in a combination of price competition for the standardized product attributes, and feature competition for their differentiating attributes. The success of their products will manifest itself in a weak or strong market position. In the ICT market, especially for network and platform products, network effects may lead to the market “tipping” towards one dominant supplier, and to their product emerging into a de facto standard (Shapiro and Varian, 1999). Independently of which strategy actors choose to convince the market to adopt a specific solution, the standardization process for this specific need ends when one solution has become the adopted standard.
In reality, the process of developing a specific specification and the corresponding implementations may not be so clear-cut (Cooper, 2016). SSO differ in the rigidity of their processes and their formal recognition. Businesses may opt to engage in the implementation and specification phases at the same time, for example to be able to create products while the formal standard is being developed or to build up intellectual property rights (IPR) portfolios while advocating for covered functionality to become part of a formal standard. Some organizations strategically decide to participate in standards development to decrease market uncertainty or to ensure conformance with later government policies (Blind and Mangelsdorf, 2016). As a third alternative next to early and late standardization, these actors have chosen a parallel standardization model (Lundell and Gamalielsson, 2017).
The four phase model developed in this study is able to describe a variety of early, late or parallel real-life standardization processes. Since FOSS initiatives commonly follow a late or parallel standardization model, the model will serve as a reference for a comparative analysis of SSO and FOSS based standards development. The key question to answer based on this model with regards to the transition from ideation to market diffusion is what determines the choice for early, parallel or late standardization.
4. Qualitative methodology based on expert interviews
Assuming as derived in the standardization phase model that SSO and FOSS are both alternative and viable strategic paths towards an adopted standard, a method was devised to gather data about the researched subject matter that reflects the still amorphous structures in the field of study. Both sides of the story represent a grown, established culture difficult to describe in quantitative metrics. Research for this paper was conducted in four steps. First, data was gathered through a series of qualitative expert interviews. Second, a model of common opportunities and threats caused by major developments in the ICT sector that affect both SSO and FOSS was created. Third, two individual SWOT analyses where conducted to structure the findings for both fields. Finally, a comparative analysis was performed contrasting the two SWOT results to identify possible areas of competing and complementary activities between SSO and FOSS.
4.1. Interview process and interviewee selection
The data for this study was gathered by performing a series of qualitative, open ended, semistructured in-depth expert interviews according to the Meuser-Nagel method (Ullrich, 2006). The chosen interview method focuses on making specialized expert knowledge accessible outside of their specific circles. Based on its recommendations, the interviews have been pre-structured to map out and structure the field of interest, with the individual questions being defined openly to leave room for a open and flexible course of discussion. This allows the interviewee to present a personal view of the subject, and avoids the potential collapse of communication possibly caused by an over-structured interview (Meuser and Nagel, 2002).
One possible risk with performing semi-structured qualitative interviews is that the interviewer must be capable to express his interest for a specific knowledge of the expert and at the same time be a competent dialogue partner at eye level. To mitigate that, the interviews have been conducted by two researchers with a distinct background and professional experience in both SSO and FOSS.
The interviewees have been invited to participate in the study based on their specific experience at the intersection between standards setting and FOSS development. We interviewed SSO representatives who are responsible for establishing open source policies for their organizations, especially ETSI, Deutsches Institut für Normung e.V (DIN) and Institute of Electrical and Electronics Engineers Standards Association (IEEE-SA) as well as FOSS community representatives in standards development at OASIS. The interviewees where all long-term engaged in the subject of the study and provided well-respected insight based on their experience. The level of experience provided by the interviewees was crucial for the overall success of the study. Each interview lasted between one and two hours.
The interviewees agreed that the interview will be recorded, and the audio archived at the chair of innovation economics of the Technical University of Berlin (See Acknowledgements). They agreed that the interviewees will be named in the paper, that all statements will be aggregated or anonymized, that no individual statements will be published and that any potential citations will be approved before publication. The interviews were conducted live in an office surrounding, via Internet-based video conference or as a Internet-based telephone conference. The circle of participants always consisted of the two researchers and the interviewee, in order to ensure that both researchers with their FOSS and SSO backgrounds could interject questions to make sure all views and aspects are captured. The interviews were not interrupted which allowed the interview to develop and create a unique dynamic, without losing direction. The interviews were digitally recorded and afterwards transcribed.
4.2. SWOT analysis applied to SSO and FOSS
A SWOT analysis is a strategic planning tool that is based on the understanding that the successful performance of an organization with respect to a specific goal depends on the way the organization interacts with the inherent characteristics (internal factors) of the organization and the broader context (external factors) in which the organization must act but has no direct control upon (Houben, et al., 1999). It is employed to evaluate the strengths, weaknesses, opportunities and threats of an organization with regards to a project, a strategic approach or any other situation that requires a managerial decision. Strengths are defined as capabilities that enable an organization to perform well. These are capabilities that should be leveraged. Weaknesses are defined as characteristics that prohibit an organization from performing well and need to be addressed. Opportunities are defined as outside trends, forces, events and ideas from the organization external environment that the organization could capitalize on. Threats, in contrast, are possible events, forces and trends outside of an organization’s control that the organization needs to plan for or decide how to mitigate (Harvard Business School, 2005).
The approach is to analyze the external factors opportunities and threats as well as the internal factors strength and weaknesses and to structure them into a matrix, which will then allow the derivation of strategic consequences. This matrix is commonly called “the SWOTs” of an organization with respect to a specific topic. It serves as input to strategy development by identifying whether there are strengths that can help capitalize on opportunities, strengths that can offset weaknesses, or opportunities that will offset threats. This process can be repeated for the different SWOT elements that have been isolated in the process. This list of possible strategic measures is then clustered and prioritized in order to identify feasible and effective strategic measures.
There is no common model to describe how two groups of organizations can successfully collaborate. To answer this question for SSO and FOSS, we devise a method to combine and contrast two separate SWOT matrices into a comparative analysis that highlights competing and complementary strengths and weaknesses of the two approaches. We believe that this approach is new and corresponds directly to the research question of finding areas of collaboration and competition between SSO and FOSS. The approach assumes that both organizations are operating in a common space of technical innovation with the same underlying trends, which means that two of the four dimensions of the separate SWOT analyses, strengths and weaknesses, are independent, while the other two, opportunities and threats, describe the same space. A strong overlap between the opportunities and threats identified is to be expected in the results, even though they may be perceived to have dissimilar effects. The comparative analysis is performed by evaluating, against every identified opportunity or threat, whether there are strengths and weaknesses of both camps that negate each other, indicating an area of potential competition, or that reinforce each other, indicating an area of potential collaboration.
An analogy can be drawn between the idea of comparative SWOT analysis and the economic theory of comparative advantage, where two countries mutually benefit from each other through specialization. It is also possible to extend the approach to a “multilateral” SWOT analysis where the cross connections between the organizations increase in complexity and generate exponentially more potential strategic ideas. However, the conceptual extension of the original SWOT analysis serves specifically the purpose of contrasting two disjunct constituencies and depends on them operating in the same space of technical innovation.
5. Empirical analysis of the interview results
5.1. Threats and opportunities in the ICT ecosystem
With regard to the subject of this study, SSO and the wider Open Source community operate in the same space of technical innovation and are influenced by threats and opportunities caused by market trends, technological developments and long-term societal paradigm shifts that are at least in the short-to-medium term outside of their control. The widespread use of computers and the creation of the internet represent digitalization and the emergence of the digital society. While other recent technical progress appears evolutionary, digitalization has the impact of a radical innovation at global scope. Digitalization is a revolution (World Economic Forum, 2016).
The essential effect of digitalization in our context is the drastic reduction of transaction costs incurred from collaboration and information sharing. Three significant paradigm shifts related to digitalization have been identified in this study: the development of better methods of collaboration, a general trend towards openness and transparency, and a shift of relevance from national to supra- and international collaboration and regulation. A fourth influential trend is the shift in understanding of the role of the modern state. “Formerly conceived in many countries as a provider of jobs through the civil service and a producer of goods and services through public enterprises, in its modern form the state ideally sets the rules and intervenes to correct market failures, rather than substituting itself for the market as a mediocre manager of enterprises.” (Tirole, 2017) While they may perceive the effects of these paradigm shifts differently, both SSO and the wider FOSS community respond to them and in the interviews considered them as key factors in their interaction with each other and with society.
The development of improved methods of collaboration is directly related to the use of the Internet as a means of direct user-to-user communication. Online collaboration tools remove the need to publish and distribute physical documents, facilitate participation independent of physical vicinity, and enable levels of transparency that previously were impossible due to the prohibitive cost of participation and sharing information. Detailed formal standards are useful in a work flow where these standards authored up-front in direct collaboration become the specification for the following independent development of conforming products. This work flow was effective because direct collaboration was costly and time-consuming. Its benefit is less clear today, especially in the realm of software and software related technologies, where permanent online collaboration and the pervasive availability of all relevant documentation are the norm. Less centralized and more inclusive decision-making models continue to emerge, making formally and informally regulated committee work and the level of trust and authority embedded into the appointed committee members increasingly redundant. This change may be perceived as both an opportunity or a threat depending on the extent to which working in formally appointed committees is central to the culture of the organization, and possibly embraced by regulators. Some SSO like IEEE-SA reacted by decentralizing their committee work. FOSS communities are generally organized in a more or less decentralized way. Other stakeholders struggle with the perceived loss of control. Regulatory influence is especially challenged by the loss of relevance of national legislation. Meritocracy in online communities means that an appointed representative of a large industrial country should not expect to have more influence than a representative of a developing country, or a senior engineer more than a contributing young developer. Opportunities for regulatory capture and rent-seeking become increasingly rare, while stakeholder diversity increases. These opportunities for a more balanced global industrial innovation process will be seen as a threat by those entities that benefitted from the old ways. SSO depend on new technical solutions and qualified experts engaging in their formal standardization activities. Developing market relevant standards requires innovative committee members as well as access to cutting edge technology championed by participating member companies. This challenge for SSO requires them to re-think collaboration and committee work patterns and opens an opportunity to collaborate with innovators in the wider Open Source community.
New possibilities of information sharing drive a major trend towards openness and transparency. What started with FOSS as a movement towards essential user freedoms (Stallman, 2002) spread to open access in science, open data, open organizations (Whitehurst, 2015), more inclusive political platforms and other areas. Existing institutions have partially developed under the assumption, as in representative democracies, that direct, decentralized and pervasive collaboration between all stakeholders is practically impossible. However, through digitalization the technical means for such decentralized collaboration now exist, resulting in an emerging expectation that transparent and open collaboration methods should be applied more widely. FOSS communities are one example of new institutions that developed to match the paradigm of transparent collaboration.
Deeply embedded into the culture of SSO are rules for the handling of IPR both towards the standards as products in their own right as well as to inventions embodied in the specifications of the standard. It is common, for example, that standards defined by DIN are sold by the copy through a publisher. Detailed IPR licensing policies of SSO regulate how SEP are made available to implementers. Although many SSO consider themselves to be transparent, inclusive and open, the economic models of SSO are closely intertwined with notions of exclusivity, linking the trend towards openness to a perceived conflict between exclusivity and open collaboration. Exclusivity can result in an advantage for players with earlier access to information than their competitors. SSOs can offer their members market influence, control over IPR and time-to-market advantage, which is why formal standardization resonates with industry as well as regulators. Even though the disconnect between exclusivity and the trend towards openness has been described as a conflict between incumbent businesses and FOSS participation during some of the interviews, many businesses also state that they are successfully combining business and FOSS activities. The number of enterprises engaging in collaborative projects at FOSS umbrella organizations like the Linux Foundation indicates there is no general difficulty for enterprises to adopt open and transparent collaboration models, and that the reported difficulties are most relevant in specific industry verticals where the traditional model of standardization in combination with IPR licensing is most beneficial to the participating companies, in particular the telecommunication and mobile communication sectors.
The debate at the EC level about the role of patents, SEP and FRAND licensing in ICT standardization demonstrates a strong stakeholder polarization, preventing the adoption of compromises even though both opportunities and threats present themselves to all involved parties. This intense influencing of policy-makers and established institutions like the European Patent Office (EPO) is perceived by the wider Open Source community as a threat, namely the repeating pattern of using other IPR or contractual agreements to diminish the user rights granted by FOSS licenses. In the past, contributor license agreement (CLA), trademark licensing programs, trade secrets for example in the form of delayed source code releases, SEP in combination with FRAND licensing and other means have been applied to maintain a privileged position of one entity at the cost of software freedom. Other actors have attempted to redefine what the term open source stands for with the goal to prevent reuse of the source code or the development of derivative works. Activities like this are known in the wider community as spreading “FUD” (fear, uncertainty and doubt) and are considered a threat to the viability of the upstream/downstream model. Usually, these attempts are not successful, and software related businesses attempting them expose themselves to ridicule [8]. To be able to publish relevant, adequate and timely standards, SSO regard their IPR rules and SEP policies as an opportunity that incentivizes innovators to secure a return of investment on research and development. Other technology developers may hope to establish a de facto standard by offering their technical solutions under a FOSS license, reducing their motivation to participate in standards setting at SSOs. The convergence of technologies, digitalization and the trend towards openness increase the importance of interoperability and interface standards. Participants have a choice to collaborate on creating specifications, joint implementations or both. This presents an opportunity as there is an increasing demand for standards development that SSO can respond to. SSO have the opportunity to facilitate standards development and to provide the collaboration platform for the interaction between standards and FOSS development. FOSS communities are particularly sensitive to the perceived dangers of SEP claims covering their products, and the potential moral hazards originating from information asymmetries between patent rights holders and the implementer community. This perceived threat is aggravated by the lack of definition of what FRAND stands for, and the unpredictable behavior of non-participating entities that are not bound by SSO licensing policies asserting rights against joint implementations. The wider Open Source community is however usually confident in their own innovation capabilities which reduces the threat of non-participating entities gaining valid patent grants that cover essential FOSS technologies (Blind and Boehm, 2019).
The shift of the role of the modern state from an employer and producer to a regulator creates a new balance between societal or regulatory interests and industry (Tirole, 2017). Formal standard setting gains importance in its role as a provider of frames of references and rules that regulators can use to set directives or framework contracts. In this context, standards support certainty in compliance and legal matters by documenting expected behavior. This is an opportunity for national standards bodies that are integrated into the regional or international cooperation of standards bodies since their remit matches the regulatory reach. This trend reinforces expectations towards the openness of standards. The European Interoperability Framework requires for open standards to give all stakeholders the opportunity to contribute to the development of the specification, the availability of the specification to everybody to study, and for the relevant IPR to be licensed on FRAND terms in a way that allows implementation in both proprietary and open source software, and preferably on a royalty-free basis (European Commission, 2017b). There seems to be a general expectation that if regulators mandate compliance with a standard, then that should be an open standard according to these principles. This attitude is related to the general trend towards openness and collaboration described above. Like with standards, an expectation develops that software developed using public funds should always be released under a FOSS license. The public money — public code (PMPC) (Free Software Foundation Europe [FSFE], 2018) campaign is a community effort lobbying for this approach. The stronger focus on regulation bears opportunities both for SSO and for FOSS communities. One potential mismatch exists between technical evolution and social responsibility that regulators need to take into account. It is common that SSO enter into treaties with the state or are entirely state run, agreeing to obligations to include a wide range of stakeholders into standards setting processes as well as to keep social responsibilities into account. This existing institutional integration between SSO and the public puts SSO in a unique position to develop standards that then become mandated. The self-regulated FOSS community is not only not obliged to keep social responsibilities into account, it often explicitly refuses to be influenced by stakeholders that are not actively participating in the development of their products. Voluntary participation is an effective regulator to ensure that the communities themselves are open to a diverse range of contributors. It does not however steer communities to keep outside interests in mind. Since the wider Open Source community causes an important and noticeable impact on society, an articulated public interest in the development of FOSS exists that regulators may eventually act upon. This can be understood as the risk of a potential disruption of established norms of collaboration of the wider Open Source community that until now primarily self-regulates. Most communities are not fully aware or acceptant of this possibility.
The final major change identified in the interviews is the shift of relevance from national to supra- and international collaboration and regulation caused by globalization. It is obvious that the benefits from standards increase the wider they are adopted. The various shapes of power plugs are a regular reminder that SSO originally developed in their countries, and only later started collaborating. It is also obvious that the parallel development of technical standards in different national standards bodies constitutes a welfare loss similar to parallel invention in patent races. Interaction with regulators in Europe however happens at the national and the European Union (EU) level. The resulting need for new boundaries of responsibilities is both an opportunity as well as a threat for SSO. The development of standards may shift towards international, possibly sector specific standards development organizations, while the dissemination, translation and adoption of standards to a country’s environment may remain the responsibility of national standards bodies. National borders never played an important role for FOSS communities, even though cultural barriers do. Cohesion within the wider community is strong and clusters in regions with a common cultural and language background. There is, for example, little interaction between the Chinese and the European FOSS community. Global collaboration is understood as an opportunity for FOSS communities, even though their international integration is not yet perfect. Businesses participating in standards development and in FOSS activities at a significant level usually operate in multiple countries and benefit from the reduced barriers to market entry caused by the convergence of technical standards. Regulators at the national level may find it difficult to exercise influence over de facto standards development, and may even find themselves facing a competition for defining standards that reduce their ability to implement their responsibilities towards their own constituencies. This is already apparent in the diffculties in regulating large Internet platform businesses based in the U.S. or China. ISO, the SSO recognized by the EC and the national standards bodies need to find a new balance of shared responsibilities that matches their social responsibility at each level.
5.2. Strengths and weaknesses of FOSS
The strengths of FOSS emphasized as most relevant with regard to this study during the interviews are rapid prototyping, a global development model based on early and regular releases, voluntary participation in community activities, and the established overall development process of the wider Open Source community in a complex upstream/downstream network facilitated by umbrella organizations, especially FOSS foundations. Weaknesses are a lack of established supply chain management processes, uncertainty and arbitrariness in license compatibility and achieving license compliance, and a meritocracy that focuses primarily on product contributions at the neglect of other potential stakeholders.
Rapid prototyping refers to the ability to quickly sketch solutions to upcoming technical problems, and evaluate them based on the response of other participants. This enables a competitive evolutionary selection of solutions in an early stage, limiting costly up-front investments. It also facilitates challenging existing de facto standards, reducing the hysteresis caused by an existing, outdated solution. As a result, FOSS market segments are “tippy”, they tend to quickly replace even widely adopted solutions that many actors are invested in if a new, more promising solution appears more convincing. A recent example is the decline in relevance of the OpenStack project that has seen massive investments by a large number of actors in 2016 once more efficient container-based technologies like Kubernetes emerged. The large overlap of actors that used to invest into OpenStack and now invest in Kubernetes indicates that newer solutions displace outdated products, but not the community of contributors engaged in this particular market segment. Collaboration is more important than the specific technology it produces, since products are comparatively short-lived. The resulting rather aggressive creative destruction showcases shortens innovation cycles and reduces large up-front investments in technologies that later fail to reach diffusion in the market.
Release early, release often describes a community norm of publishing intermediate results as early as possible, inviting feedback and contributions from other interested parties. It is related to rapid prototyping, but survives the exploratory steps and is also applied once a solution has gathered interest and a community begins to form around it. By enabling users of the solution to get involved in collaborative development early, the resulting feedback cycle is “an order of magnitude faster than most commercial software projects” (Weber, 2004). Since all contributions are almost immediately published in the product source code, all inventions embedded in them become prior art, and the original inventor is difficult to identify in the collaborative development process. Additionally, each individual contribution usually only embodies only a small, incremental inventive step. FOSS communities collaboratively invent, but are almost never able to acquire patents on their inventions even if they wanted to. This contributes to the lack of perceived utility of the patent system as a whole in the wider Open Source community, and to the reputation of the Open Invention Network (OIN), a royalty free cross-licensing network that covers core FOSS technologies in its license agreement and has been joined by about 3,000 FOSS participating entities [9]. Contributors exhibit an expectation of shared stewardship of the results of the collaborative process that extends to copyright, inventions, but also to the communities as entities. Additionally, because of the described dynamic of the constant generation of prior art, rights holders of patent claims that read on inventions originating in the wider FOSS community that do not cross-license their inventions under royalty-free terms or through OIN are almost exclusively non-participating or non-practicing entities, further reducing their reputation and that of patents on computer-implemented inventions in general.
Voluntary participation in FOSS activities is fundamental to the understanding of the self-correction capabilities of governance in communities. Every individual or organizational participant contributes their resources voluntarily to the overall FOSS process. While this is well understood and to an extent researched with regards to the motivation of individual volunteer developers (Lakhani and Wolf, 2003), it also applies to businesses investing in community projects. There is no obligation to contribute, so organizations must have an inherent business reason to participate in general, and must be convinced that engaging in a particular community is the best alternative available to them. Because of that, communities are constantly pressured to develop governance principles that embody the open source way (Whitehurst, 2015), and match the expectations of their existing and potential contributors. Once engaged in a particular community, participants face a voice-or-exit dilemma of constantly evaluating their choice to participate, and are always free to leave if they are not interested anymore (Hirschman, 1970). This behavioral corrective combined with overall strong fluctuation of contributors ensures that governance within communities is self-healing, converges towards open source culture, and that communities appear, grow, shrink and disappear depending on how well they serve their purpose, and without necessitating public investment or interference. In this environment, it is highly unlikely that actors that violate community governance norms regarding shared stewardship or other aspects of collaboration will be successful.
The upstream/downstream model of collaboration within the wider FOSS community uses the mental image of a large river that collects the water from many smaller and smaller tributaries (the communities) and delivers it to the ocean (the users). To create products of the complexity of a whole Linux distribution like Debian, or the standard package index of a major programming language like Python [10], requires a coordinated effort of potentially thousands of individual communities. Product improvements originate in the communities and then are integrated “down the stream” by more and more complex aggregate products. Feedback like bug reports and requests for improvement, but also patches meant for integration into the upstream projects are generated closer to the users, and then travels “up the stream” to be eventually integrated by the community where the solution originates. Aiming for maximum reuse of code changes, the wider community developed a strong preference for working upstream, as in making an effort to have changes integrated as close to the original solution as possible (Whitehurst, 2015). FOSS licenses are applied to all products in the upstream/downstream network and facilitate the frequent integration and redistribution of aggregate products. Since there are potentially thousands of communities involved, the essential terms of all FOSS licenses are codified and always embed the “four freedoms of software”, namely to use, study, modify and redistribute it (Stallman, 2002). Similarly, the wider FOSS community applies basic normalized processes of how bug reports and patches are disseminated upstream. Linux distributors for example participate routinely in providing smaller patches and reporting issues to a multitude of upstream communities with minimal friction. Tools like version control systems and issue trackers are used as de facto standards that model a common work flow. More recently, Github has shaped the upstream/downstream model with their (proprietary) pull request work flow that has been very widely adopted. A complex network of many upstream and downstream participants following their own self-interest would be prone to anti-commons situations in which the cost of negotiations would grow to be prohibitive to collaboration (Heller, 1998). Therefore the licenses applied by FOSS communities are non-negotiable. The upstream communities offer the use of their product under a specific license, and the downstream users accept that offer by using the software, or decide not to use it (Phipps, 2011). Similarly, but not to the same extend, behavioral norms like open access, transparency or meritocracy are non-negotiable in the wider FOSS community. The result are negligible transaction cost of participation in the upstream/downstream network. Standardized governance norms are beginning to emerge in the ICT industry and are facilitated by trade associations like the Eclipse Foundation or the Linux Foundation. An important role of these umbrella organizations is to establish common governance norms that facilitate collaboration in the wider Open Source community.
The weaknesses of FOSS identified in the interviews mirror the importance of the efficiency of the collaborative development processes.
FOSS currently lacks widely adopted supply chain management processes. The upstream/downstream model efficiently enables collaboration across the wider Open Source community. However, it does not help businesses structure the relationship to their software suppliers. Unlike in other industry sectors, common attributes of deliverables like provenance of parts of the product or compliance with FOSS licenses are not commonly contracted. Out of the overall responsibility for license compliance of the final product, vendors need to evaluate the complete software stacks of their products, even if major elements of those have been provided by otherwise trusted suppliers. The well-established norms of collaboration in the wider FOSS community have not yet been completely translated to best practices or de facto standards in the ICT sector, leading to inefficiencies, especially to high cost of maintaining license compliance and compatibility, and to barriers to the adoption of FOSS in commercial products. The OpenChain [11] project is a recent attempt to specify supply chain requirements. Long-term maintenance of FOSS products that matches the life cycle of durable industrial products is also difficult to establish.
Maintaining license compliance is a precondition for shipping products that contain FOSS or a mix of FOSS and proprietary code. Through legal instruments like injunctions, contributors that hold copyright on the product may stop businesses from selling their products if the vendor violates the obligations resulting from the redistribution of FOSS code. There is however a perceived uncertainty and arbitrariness in how FOSS licenses are enforced. License defense and litigation support is offered by community representatives like the Software Freedom Law Center (SFLC) [12]. Cases also exist where individual copyright holders litigate against FOSS business users, sometimes for their personal gain (Meeker, 2017). Occasionally, businesses have even been recommended to avoid the family of GPL licenses altogether, which would unnecessarily lead to one third of the existing body of FOSS solutions not being used. This uncertainty has been addressed by the FSF in their “principles of community-oriented GPL enforcement” (Gay, 2015), with the “Linux Kernel Community Enforcement Statement” (Kroah-Hartman, et al., 2017), and others. GPL version 3 affords license violators more time to correct mistakes before litigation can begin. However, most existing software licensed under the GPL still use version 2. Some influential vendors releasing code under GPL version 2 have begun to publicly commit to applying the GPL version 3 “healing clause” to their products (Red Hat, 2017). These initiatives indicate that managing license compliance is not yet as normal and standardized as it could be.
Meritocracy is a key tenet of governance in FOSS communities. Every participant, no matter if it is an individual volunteer, a representative of an organization, or an organizational entity itself, earns merit based on their concrete contributions to the community product. Contributions are however not all valued the same, in that one hour or one Euro invested would create equal merit. Improvements of the core product of the community are usually valued more than translations to rarely spoken languages or administrative support, even if they are just as important to the societal aspirations of FOSS communities. A Linux kernel developer gains vastly superior merit compared to a documentation author. On one hand, this is a direct expression of the auto-organization in communities. On the other hand, FOSS meritocracy discounts the importance of other stakeholders that represent interests in the community product but do not participate directly. This is partly intended — communities regularly try to focus their governance on those directly participating, trying to keep politics or “mere talkers” from interfering with the process. For regulators, representatives of civil society interests and other outside stakeholders, it may appear as if the FOSS communities evade responsibility for the externalities caused by the products they create. Even FOSS user groups happen to report a lack of interest by communities in their feedback. By building up loyalty to and standing within their community over time, an insider culture may develop where being a part of the community becomes an aim in itself. Contravening the idea of open governance, this erects barriers to entry for new contributors or previously not present stakeholders. Meritocracy in FOSS seems to be a double-edged sword.
The weaknesses of the FOSS ecosystem identified in the interviews represent risks from participating in the development and from using FOSS in proprietary products, born out of a lack of supply chain management, compliance and governance standards. There is analytical bias in this study towards aspects of standardization since the interview candidates have been selected for their knowledge in this field. The results however match current trends in the ICT sector, especially efforts to mitigate manageable risk through the specification of supply chain, compliance and governance norms. While there have been improvements mostly from consorted industrial initiatives in recent years, at the moment businesses still cannot insure the residual risk of using FOSS. This indicates that the identified weaknesses are relevant and important for the continued success of the wider Open Source community.
5.3. Strengths and weaknesses of SSO
The strengths of SSO emphasized as most relevant with regard to this study during the interviews are the mature formal standardization processes, a powerful reputation in a large stakeholder network, widely accepted terms of reference and IPR frameworks, signaling of market opportunities and value-added SSO services. Weaknesses are organizational inertia, a dependency on powerful stakeholders, an ecosystem where responsibilities are allocated based on historical developments, under-defined IPR frameworks and reliance on outdated revenue streams by some SSO.
Through a long history of setting formal standards SSO have evolved to be connected platforms with well-established tools and processes for formal standardization. The formal standardization process allows every legal entity to participate in the consensus-based development, documentation and approval of the recognized state of the art, while ensuring that all relevant stakeholders and the public are informed, consulted and invited to participate. Some SSO are obliged to consider social, environmental and public responsibilities during the formal standardization process, thus SSO are a great tool for the transfer and diffusion of technical solutions into the market, national and international economic policy implementation, market regulation, creation of legal certainty and implementation of security and safety measures.
The impact of standards development builds upon the powerful reputation in a large stakeholder network that SSO established throughout their history. The internationally integrated SSO ecosystem connects industry with government and research institutions. Participating in this network amplifies the reach individual actors can achieve in the market. By successfully including a technical solution into a formal standard it changes into an accepted state of the art that more easily finds adoption among national and international implementers and business partners, significantly boosting diffusion in the market. Some SSO are accredited by governments or in other ways recognized to represent the interests of the countries economy and enterprises on the international stage. Participants in national standardization have the chance to gain global visibility if standards achieve recognition at ISO. Governments can influence formal standardization as an instrument to implement economic and trade policy.
The cooperation between competitors in a market segment that is necessary for standards development raises concerns of collusion and anti-competitive behavior. An inherent conflict also exists between sharing technical solutions and the ability of participants to create a relevant IPR portfolio. SSO provide a platform to manage these concerns through widely accepted terms of reference and IPR frameworks. These frameworks help to attract innovative technology developers by providing policies regarding the disclosure and licensing terms of IPR covered by the standard, especially SEP. Licensing policies with regard to SEP are designed to give inventors the prospect of a return on investment on their research and development efforts, while still making these proprietary technologies available for standards development. Frameworks for disclosure and FRAND licensing commitments reduce uncertainty and maintain competition in the market. IPR policies ensure access to SEP, while leaving the concrete terms of technology licensing to market-specific agreements. The inclusion of patented technology in formal standards is considered necessary for early standardization approaches in research and development heavy market segments and especially enable business models that rely on inventing and licensing IPR while leaving manufacturing to other parties.
The work program of SSOs usually follows long term roadmaps based on mission statements and standards development strategies. By connecting the activities of technology development and mass-market production, SSO are signaling market opportunities and facilitate research and development as well as manufacturing centered business models. The formal process of setting a standard may last between one and five years, which provides the necessary lead time to build manufacturing capacity and ensure standards compliance. For market segments with shorter innovation cycles, some specification instruments of SSO like DIN-SPEC [13] or the CEN Workshop Agreement (CWA) [14] reduce this process to less than a year by creating pre-standards rather than full standards. Released standards are systematically revised usually every three to five years. This allows stakeholders and the public to update, confirm or withdraw a standard and businesses to direct investments into implementing products. Technical committee members may have significant influence with regard to technical decisions. This increases predictability of standards development and acts as an incentive for market actors to participate in standardization, especially in market segments with high cost of change.
Especially long-term standards development participants benefit from value-added SSO services. Formal standardization provides a secondary market where IPR and information are strategically shared among participants. SSO offer match-making between parties interested in standards development, discovery of technical trends and indicators for market diffusion. Engaged participants enjoy a club advantage from early access to market-relevant information and the opportunity to influence the resulting standards. This may lead to a competitive advantage especially for large enterprises engaged in a multitude of standardization activities.
The weaknesses of SSO identified in the interviews mirror the struggle with the faster pace of innovation caused by digitalization. This is true especially for technological fields with low costs of change, for example computer software, that are characterized by rapid technology changes and volatile trends. The formalized processes of SSO are at times too slow and too inflexible to adequately meet those market needs in time. The standardization process of some SSO is required to consider all stakeholder interests. This not only slows down the process, it also reduces the attractiveness of formal standardization for businesses that are under competitive time-to-market pressure. Industry actors may be incentivized to rather set de facto standards to circumvent the formalized process. This makes it difficult for SSO to release market relevant formal standards in time.
Interviewees mentioned a “standardization habitus” sometimes exhibited by employees of SSO. Organizational inertia manifests itself in an affinity for formal processes and little passion and vision for new approaches, new ideas and new topics. The staff of SSO focuses on administrative tasks and is usually far removed from innovation in the industry. As all institutions, SSO developed their own interests that may deviate from their original purpose, like maintaining budget and staff size or ensuring long-term employment safety. The fast paced innovation in the ICT sector may be in conflict with those goals. This is an issue that SSO like DIN and ISO have identified and are trying to mitigate jointly by following new approaches for attracting new experts or modernizing future technical committee processes (DIN, 2017). CEN and CENELEC are investigating machine-readable publication and modern collaboration methods with the Digital Transformation Initiative (CEN/CENELEC, 2017).
SSO depend on powerful stakeholders among the participating and member organizations for their budget and for developing market-relevant standards. Especially large enterprises may use their influence to maintain control over standards that are important to their business interests. This limits the ability of SSOs to react to market signals and to adapt to new technical developments. Released standards may not be those most wanted by the market, or the standardized technical solution is watered down during consensus finding. Especially in highly concentrated markets with a small number of actors like the telecommunications sector, the influence of powerful member companies on SSO governance may undermine the covenants in terms of reference and IPR frameworks against collusion and anti-competitive behavior.
The distribution of responsibilities between the various national, regional, sector-specific and international SSOs developed against a background of strong nation states and a primarily industrial economy. SSOs form an ecosystem where responsibilities are allocated based on historical developments. National standards bodies sometimes develop competing standards in a “race to the moon” to claim relevance for new technological areas. This battle for relevance ignores that technical solutions today compete in a global digitized market. What role national standards bodies or even European SSO play within the global standardization ecosystem is a key question for their future relevance. This issue is more related to digitalization and improved methods of collaboration than to the relationship with the wider Open Source community.
While the IPR frameworks of SSO are mostly well-established and accepted and mainly considered a strength, the under-definition of IPR frameworks in some aspects has been identified as problematic. IPR frameworks establish common expectations and provide conflict resolution mechanisms crucial to standards development. To reduce uncertainty of legal risk, IPR frameworks are expected to provide clarity about the obligations and commitments of participants when the cooperation on standards development begins. Some SSO accept voluntary disclosures of SEP based on goodwill, which provides little safety against undeclared SEP. Some refer to FRAND, which in reality is not clearly defined. In most cases, the concrete agreement that the FRAND commitment promises is left to negotiation between competitors. Multiple interviewees referred to cases where technology users refused to license SEP, or where SEP holders refused to license to their direct competitors. Since the licensing agreements are usually confidential, participants cannot verify that the terms offered to them are in fact fair and non-discriminating. This acts as a barrier to participation in standards development, to market adoption and negatively affects the reputation of the respective SSO, especially when compared to the absence of negotiation when engaging in FOSS development. Royalty-free licensing of SEP can be considered a subset of FRAND, however it is only applicable to FOSS distribution if no explicit licensing negotiation or registration is required. In reality IPR policies of SSO that require any form of negotiation or license management are often generally avoided as a cultural mismatch or a distribution risk by the wider Open Source community.
Some SSO rely on outdated revenue streams that are in conflict to the general trends towards closer collaboration as well as openness and transparency. For example, some SSO that grew as a combination of standards-development platform and standards publishing business continue to rely on revenue from selling access to standards for a fee. While such revenue generation may still be viable today, it can be expected that selling content that is essentially community developed and can be copied at negligible cost may conflict with the overall trends in the ICT sector.
6. SSO and FOSS communities — Partners or competitors?
After structuring opportunities and threats in the ICT sector as common external influences that affect both SSO and FOSS communities, and breaking down their strengths and weaknesses separately, it is apparent that SSO and FOSS communities both complement each other and compete for relevance at the same time, but for different aspects of the functions they provide. When comparing their respective strengths, there is no clear winner:
SSO possess a brand that promises tested, proven processes of standards development and a long-term roadmap providing stability to industry, research and policy-maker participants. By defining and documenting the state of the art of technical innovation, they facilitate the interaction of a wide range of stakeholders and act as a bridge between industry and regulation. The wider FOSS community develops technical innovations at a fast pace, steers investments effectively through eliminating failing approaches early in the process and practices evolutionary product development with early and regular releases. Contributions are allocated self-healingly and efficiently through voluntary participation. Foundations act as the umbrella organizations that facilitate the upstream/downstream model. This opens the possibility for SSO to create standards based on “code first” FOSS solutions, similar to how the OpenDocument format was standardized (OASIS OpenDocument Technical Committee, 2009). This combination of a FOSS implementation with late formal standardization was repeatedly mentioned in the interviews and would apply the early competitive selection of FOSS processes to the selection of technical solutions for standardization. Even though this is not yet a common approach, it could improve the competitive selection of technical solutions for formal standardization. Since the continuous non-differentiating cooperation model reduces the need for specifications for interoperability reasons, formal standardization needs to be useful for other reasons, for example for quality management or compliance with safety standards or export regulations.
The most significant determinant identified in this study for which model is most efficient is cost of change. FOSS communities flourish in an environment where changes and corrections to products and specifications can be made almost instantaneously. The kernel development community integrates changes into Linux at an average rate of 8.5 patches per hour (Corbet and Kroah-Hartman, 2017). The cost of each individual change in this environment is almost negligible. Mistakes can be fixed easily and quickly, reducing the usefulness of specifications that would also be hard to keep up-to-date at this pace. On the other end, changes to the protocols used for wireless network communication potentially require hardware updates and would be costly and time-consuming. These extremes span a continuum where the cost of change decreases and the pace of innovation increases. Somewhere on this continuum is a point where the cost of change is the same for SSO and FOSS communities, dividing the field into two sectors where SSO or FOSS respectively are more efficient. The pace of innovation is usually inversely related to the cost of change, since software is easier deployed than new hardware. Commoditization influences the cost of change, making specification less relevant for products that become less costly to update. Based on this understanding, it is apparent that SSO and FOSS communities complement each other as processes for the management of technical innovation that are more or less efficient based on intrinsic attributes of the specific field of innovation.
Compared to the strengths of the FOSS community the weaknesses of SSO are mostly product development related and most apparent in environments with low cost of change.
Where communities allow numerous attempts at finding the best solution to a technical problem to fail early until a promising technology emerges, SSO sometimes “fail never” because of stakeholder inertia. In extreme cases they produce standards that are rarely or never implemented. In a rather radical process of creative destruction, FOSS communities drive innovation in computing by being more efficient in the evolutionary selection of competing solutions. The wider FOSS community understands well that the release early — release often approach creates software faster and at higher quality, compared to the slow and thorough committee work SSO apply even in cases where it may not be necessary. Voluntary participation allocates contributions to where they are most useful and ensures that contributors are first and foremost enthusiastic about the software they create together. The communities attract eager inventors more than skilled administrators.
Individual volunteers contributing to FOSS usually self-identify with their tasks and work without direct remuneration. The communities they participate in may encourage, but not direct them to engage in standards setting activities. Industry-driven communities may be sufficiently funded, but still not be motivated to invest into participating in standards development activities that in their perspective mostly benefits others. FOSS contributors that engage in SSO activities are unlikely to gain merit from that within their communities. Norms for participation in formal standards setting processes that expect them to be salaried representatives of a corporate entity which also funds their activities, membership fees and travel time pose a barrier of entry that is likely prohibitive towards the participation of FOSS contributors. To encourage them to participate, SSO require rules of participation and governance norms that reflect voluntary participation, and may need to align the sources of funding with the benefits from collaboration.
Some SSO are funded partly through the sale of access to standards. The trend towards openness and transparency raises expectations of open standards, at least in case they are mandated by regulators or in any other way preconditions for the entry into markets with any form of public investment. FOSS contributors will only collaborate in standards development if the resulting standards are freely available. SSO may be pressured to transition the share of their budget raised from selling access to standards to other sources of funding, like increased revenues from membership fees, professional services for their members and public funding. By providing services to facilitate their FOSS activities, SSO have the opportunity to offer a wider range of standards setting related services to their members from a single source, which may increase membership and open up new revenue streams.
FOSS communities are generally open for participation to contributors from all over the world. Sometimes it is difficult to identify which country a community is based in, and it does not matter much. The global setup matches the trend towards supra- and international regulation, whereas SSO may possibly be seen as narrow-minded especially in cases where they develop competing standards in national standards bodies. The decentralized organization of the wider Open Source community incurs negligible transaction cost of a global participation. This matches the mindset of inventors that rather work on developing products than deal with administrative processes.
The strengths of SSO compared to the weaknesses of FOSS focus on process and a narrow definition of meritocracy. Where FOSS communities struggle with establishing useful norms for supply chain management, SSO not only provide stable processes and documentation that shape the supply chain for the industry and how regulators influence it, they even set explicit formal standards for it. Unlike FOSS, SSO are present beyond the ICT sector, and streamline the supply chain at a global scale.
Where FOSS communities struggle with the complexity of maintaining compatibility and compliance with FOSS licenses in complex software stacks, SSO establish IPR policies that are common across sectors. While there may be disagreement over what the best IPR licensing models are, SSO enjoy a higher acceptance as intellectual property (IP) arbitrators across a more diverse group of stakeholders, including regulators.
FOSS communities are attractive to contributors of code. Often they lack funding and personnel for other tasks like community management, marketing or political representation, making it difficult especially for smaller initiatives outside of influential groups to become viable. Especially if these projects have been initiated by some of their member companies, SSO could host and support them, offering similar services to FOSS umbrella organizations.
Where FOSS contributors attain merit based on a narrow definition of product-focused contribution, SSO provide well-accepted multi-stakeholder platforms and routinely involve civil society, environmental groups and other interested parties. The general acceptance of the balanced SSO process reinforces their brand as public benefit oriented stewards of technical innovation, which in turn secures sufficient funding and political support.
SSO represent well-established instruments for directing industry investments and policy-making. Some FOSS communities are not yet prepared to take on similar responsibilities. Industry-driven umbrella organizations like the Linux Foundation are steering the community to adopt behavioral norms that enable them to engage with a wider range of stakeholders.
Even relating the weaknesses of SSO with the weaknesses of FOSS delivers interesting results. FOSS communities reward product contributions in their fast-paced meritocracy, while SSO apply a well-defined, slow and thorough process to their committee work. Innovations that do not fit into either template but still benefit from standardization pose a challenge to both camps. Especially large-scale ground breaking research that requires significant upfront investments like the development of pharmaceuticals or mobile communication protocols and hardware fit neither FOSS nor SSO, and is usually performed by industry consortia or competing large enterprises. Neither SSO nor FOSS are well-equipped to deal with the resulting thickets of SEP, especially against the general trend towards more openness and transparency. As a result, industry sectors where SEP are an inherent element of invention exhibit difficulties of adopting FOSS. Suppliers in these markets tend to participate mostly in sector-specific SSO like ETSI where they can exert strong influence over the developed standards.
Globalization challenges the role of national standards bodies and the established order of SSO in general, while FOSS still lacks well-working norms of supply chain management. Outside of FOSS, standards are still not developed at a global scale, and are still considered instruments of industrial policy by regulators, even though the macroeconomic benefit would be maximized by the widest possible adoption of a standard. To avoid the history of different railway gauges and power socket designs from repeating, standards should be developed in global collaboration, which is the case for many national standards bodies under the umbrella of ISO, but not necessarily for sector-specific SSO. FOSS still struggles with this responsibility, and some SSO are not yet ready to give up part of their territorial authority.
The IPR licensing policies of SSO originally developed against the backdrop of an industrial society. They where meant to manage access to specifications of physical goods with long product cycles where the cost of change is high and the effort of specification or even publishing standards as printed books is comparatively low and justified. FOSS communities developed tools for immediate development of specifications and implementations in public, and are still working out how to maintain license compatibility and compliance in complex software stacks. These approaches barely overlap. As a result there is no common platform, for example, to establish what the requirements for open standards are, or the exact meaning of FRAND, or the right balance between enforcing standards with mandates and making them freely available, and many other fundamental questions about the future of standardization.
The “open source way” enables the development of new models of collaboration, especially continuous non-differentiating cooperation (see Section 3.3). The co-existence of SSO and FOSS communities affords participants in technical standardization a choice of which of their complementary models best fits their particular environment. Many of the arguments produced by FOSS proponents emphasize the political nature of the FS movement. The majority of communities today however understand it as their mission to create software and establish industry standards. They apply the FOSS model because they believe it is the better way to achieve that goal. This pragmatic approach should not be misunderstood as indifference towards the ethical underpinnings of software freedom. Most contributors are consciously aware that by creating FOSS, they are also being virtuous by benefiting the common good. The realization that contributing to FOSS means being enjoyably productive and doing the right thing at the same time is key to understanding the success of FOSS. Participants expect reciprocal behavior and shared stewardship of the results of collaboration as well as transparency and openness in the process. Models of collaboration between SSO and FOSS need to reflect that reality.
7. Managerial and policy recommendations
The goal of this study is to compare SSO and FOSS processes and activities that create a standardizing effect and discuss potential implications for FOSS communities, SSO, regulators and enterprises. After analyzing the strengths and weaknesses in context of the ICT sector specific threats and opportunities, our study supports a number of conclusions about the interaction between SSO and FOSS from a product, process and societal perspective.
The product view is that formal standards are products that specify how a technical solution should be implemented, while FOSS creates products that implement these solutions. SSO are better at developing formal standards, while FOSS communities have an advantage at collaboratively developing non-differentiating implementations. If there is demand for both specifications and implementations, SSO and FOSS can and already do successfully complement each other.
SSOs implement a top-down, specification-first process, while FOSS communities implement a decentralized, code-first process. For every particular product development activity, participants need to choose one or the other approach. Depending on which process design is more applicable to the desired outcome, actors will choose to participate in SSO or FOSS. For endeavors that involve the development of multiple products, like a formal standard and a reference implementation, different approaches can be combined, and the results may cross over between them. Regarding process, SSO and FOSS are competitors.
At the societal level, SSO report to regulators and are used as a policy instrument to define safety requirements, competitiveness as well as anti-trust regulation and to implement industrial policy goals in general. FOSS communities operate based on voluntary participation and an authority that rests within the communities. Regulators have a choice to influence, support or provide guidance to both SSO and the wider FOSS community to drive innovation and competitiveness and to enforce policy goals. From a societal perspective, SSO and FOSS are independent and complementary standardization instruments available to policy-makers.
Implications for FOSS communities: The wider Open Source community will benefit from applying a principled definition to what makes a contribution and from treating all contributors as equals, no matter if they are individual volunteers, businesses, research organizations or governmental agencies. Historical prejudices sometimes shared in the “hacker community” that FOSS is the prerogative of civil society and hackers are not justified considering that today’s community composition includes a majority of corporate contributors. Global FOSS collaboration offers a unique opportunity to build bridges between the interests of individual, civil society, enterprises and the state, as long as they are willing to contribute to the FOSS commons. The wider community can work towards realizing this potential by actively influencing the quality of the collaboration process as perceived by the different types of participants through community management and setting governance norms, while maintaining and reinforcing the principles of FOSS like meritocracy, transparency, non-discrimination, shared stewardship and open collaboration. By identifying and lobbying for software freedom as the overarching goal, the FOSS community can build the foundations for a successful integration with regulators and societal institutions like SSO. Only standards that are accompanied by specifications are likely to be referenced in legislation, so communities have a choice to produce the specifications themselves, or to collaborate with SSO and benefit from their reach, brand, and network for that purpose. Communities should expect to be held to higher standards regarding social responsibility in the future, and should consider this a sign of their success in contributing to the common good.
Implications for SSO: Standard setters could invest into gaining deeper knowledge of the mechanics and principles of FOSS collaboration to understand the strengths and limitations of the open source way. Knowledge of the applicability of FOSS to software and software/hardware interface innovations will help to delineate activities in higher cost of change areas from the domain of FOSS communities. SSO can confidently position themselves in technology areas where high cost of change and a slow pace of innovation make diligent up-front specification worthwhile. When engaging with FOSS communities, it should be considered important to understand the behavioral norms that have solidified in the collaborative zone. SSO should be especially wary with violating the expectation of shared stewardship by supporting or facilitating the appropriation of collaboratively developed work by private enterprises through SEP or other IPR that may become standard essential, like trademark licensing policies. SSO may decide to support and encourage participation by FOSS contributors even if they do not create direct revenue from their participation. Membership fees, requirements for nominations to committees and other barriers to participation could be waived since they not only pose a barrier of entry, they also undermine the acceptance of the SSO by violating meritocracy. Resistance can be expected from some SSO member companies against facilitating FOSS activities either out of a lack of understanding or because the results may negatively affect how participating in standards development aligns with their business interests. Regarding their own business models, SSO should actively reconsider and prepare to move away from models that depend on selling information goods like copies of a standard for a fee. Price discrimination in the form of giving free copies of standards for research or FOSS use is already applied in some places and may continue to be an intermediate solution. In general, membership fees for participating enterprises are accepted in the wider FOSS community, while fees for the use of specifications or products are more controversial. SSO may consider to accept that the traditional approach to standards setting does not work well in the low cost of change/high pace of innovation software industry, and decide to instead shift some of their activities so that they become part of the wider Open Source community. By accepting the FOSS community as equals in the standards development field, SSO could become part of the meritocracy of the community itself and broaden their service portfolio by offering their members insight into standardization and FOSS activities related to a specific field of technology.
Implications for enterprises: To remain competitive, enterprises need to focus their research and development spending towards features that differentiate products in the eyes of their consumers. Enterprises pool investments into non-differentiating features with other collaborators or even competitors, reducing their share of the cost of provisioning the necessary functionality. This allows them to increase the share of research and development spending invested into what makes their own products unique under a policy referred to as “differentiate or collaborate”. Participating in FOSS activities is a proven method for continuous non-differentiating cooperation collaboration (see Section 3.3). It is a complement, not a replacement for engaging in standards developing activities. To successfully participate, enterprises need to understand the different behavioral norms applied in the collaborative environment of FOSS compared to the competitive environment. The general application of non-negotiable licenses and governance norms means enterprises should refrain from attempts to appropriate the results of collaborative development processes through secondary restrictions to software freedom. Once it is accepted that FOSS products represent the non-differentiating state of the art, acquiring exclusive rights to functionality developed in the collaborative environment becomes meaningless. To be accepted as “good citizens” of the wider Open Source community, enterprises should continue to adapt to the behavioral and governance norms of the wider Open Source community when participating. The decisions to participate in the specification and the implementation of standards need to be made separately and considered complementary.
Implications for regulators: SSO and FOSS engage in a healthy competition from the process perspective which fosters technical innovation. For both to be considered alternative industrial policy instruments, regulators may choose to create a level playing field. This requires creating exchanges between the evolutionary selection process in FOSS and the formalization of SSO, but also may add additional obligations like working with multi-stakeholder platforms or adherence to minimal standards for governance norms that support the long-term viability of the FOSS development model. For this purpose, the role of FOSS umbrella organizations should be considered closer to that of SSO than the role of individual FOSS communities, which is also apparent in their membership structure as well as in the variety of projects hosted by the foundations. The public support of FOSS foundations could be raised to a level comparable to the support provided to SSO, especially if they commit to a charitable cause. The acceptance of the public interest in the contributions FOSS makes to the common good could justify the establishment of European FOSS development organizations either next to or integrated with existing SSO. Careful consideration needs to be applied to avoid disrupting the upstream/downstream model peer production process that is based on self-identification. This can be avoided by selectively awarding competitive, time-limited grants similar to current research funding by the EU. Governmental and regulatory representatives should expect to be received as welcome contributors, but also to have to earn their merit in the communities like any other contributor. When developing policy measures aimed at fostering FOSS development, sector specific experiences may not be generally applicable. In particular the highly concentrated, regulated and politically influenced mobile communication sector may not be a useful yardstick for the development of general public FOSS policy. Experiences from a plurality of highly innovative technology areas like cloud-native computing, automotive platforms or programming languages that involve standards setting and implementation should be taken into account. Practices need to be developed that reflect the trend towards openness and transparency. Exclusive third-party rights to formal standards that are mandated or where compliance is a barrier to market entry will find less acceptance and may be considered by the public as inappropriate rent-seeking or invitations to morally hazardous behavior. Next to welfare losses from the lack of adoption of formal standards, public policy that facilitates SEP may undermine the competitiveness of local industry sectors by inviting outsiders to compete by participating in global collaboration on developing FOSS solutions. The availability of formal standards where compliance is mandatory or practically required as open standards would eliminate this possibility.
The assumption that the state should avoid displacing the economic activities of private enterprises in the market does not generally hold for FOSS activities. If the collaboratively created product is made available under a FOSS license as a public good with perfectly infinite supply, contributions by the state do not negatively affect the market or compete with specific private enterprises. Government agencies may decide to participate in FOSS activities to satisfy their own needs in collaboration with community and enterprise contributors without negatively affecting competition, which supports the arguments made by the PMPC campaign (Free Software Foundation Europe [FSFE], 2018). Public contributions to FOSS should be considered pro-competitive as they enable all enterprises to refocus their investment on differentiating product features. The argument that all information goods produced by the state should be released under FOSS licenses since they belong to the public should be investigated earnestly. Establishing an agency to foster and support FOSS development at the EU level or tasking existing EU SSO or national standards bodies with that responsibility will help to leverage the innovativeness of the wider Open Source community.
To answer the question of whether SSO and the wider Open Source community are partners or competitors, our study identifies significant changes induced into the ICT sector by digitalization (see Section 5.1). Improved methods of collaboration, a global trend towards openness and transparency, the shift in the role of the modern state to a regulator and a transition from national to supra- and international collaboration and regulation present both opportunities or threats to ICT market participants.
Against these changes, we analyze standardization as a path that leads from ideation to industry-wide diffusion through specification and implementation (see Section 3.1). To answer perceived standardization needs caused by market pull or regulatory push, we introduce the concept of standardization instruments that cause the transition to a widely adopted standard by exerting standardizing effects. Based on that, we introduce a phase model of standardization that is able to describe early, late and parallel standardization approaches. By deciding to participate in standards setting, FOSS development or both, participants elect standardization instruments that promise to efficiently lead to market diffusion. We believe this standardization phase model explains more types of standards development activities compared to the document-centered ISO definition or institutional models that assume standardization is what SSOs do. In particular, it describes the processes of both SSOs and the wider Open Source community.
In the SSO ecosystem, we find that the reputation of individual SSOs in the ICT sector depends on relevance more than on formal recognition (see Section 5.3). The importance of interoperability changes as new technologies may now be incubated as FOSS before being standardized, leading both to higher quality standards and potentially to single joint implementations available as public goods, decreasing the importance of data format or communication protocol specifications. With global collaboration methods available, especially national standards bodies now compete more closely for relevance, which opens up both opportunities for a more efficient distribution of responsibilities and a challenge to retain mind share and to restructure accordingly.
o better illustrate the FOSS ecosystem, we introduce new or more precise definitions for the concepts of community, wider Open Source community, umbrella organizations, contributors, contributions, FOSS licenses and upstream/downstream model (see Section 5.2). We believe that these concepts are intuitively well-understood by participants, but so far not present in academic literature in a coherent and interconnected way. We introduce the concept of continuous-non-differentiating cooperation that partially replaces pre-competitive cooperation, and identify that industry participants apply a principle to either differentiate or collaborate. Voluntary participation, indicated by the competition for contributors and the looming threat of forks, acts as a corrective force that cause community governance norms to converge on the expectations of the wider Open Source community. Our study reiterates that FOSS licensing minimizes transaction costs by eliminating negotiations, thus preventing the numerous FOSS licensing relationships from causing an anti-commons situation.
When assessing the relationship between SSO and FOSS, relevant standards need to contain software components or interfaces between hardware and software components (see Section 6). Standards exclusively covering physical goods are not implemented as FOSS. Our study identifies cost of change and pace of innovation, which are usually inversely correlated, as factors that influence the decision to focus on specification or implementation first. The results indicate that SSO and FOSS communities compete for relevance as alternative process choices based on their suitability to address specific needs for standardization, and that some topics where both SSO and FOSS processes show weaknesses, like early-investment heavy research and development efforts not suitable to open collaboration, are currently not efficiently served by either process. Finally, the results show that the roles of FOSS umbrella organizations and SSO exhibit signs of convergence, with both influencing the governance and IPR frameworks of innovation and the development of standards and acting as platforms for consensus building.
Overall, our study describes a utilitarian approach to standardization where a perceived need for a technical standard is satisfied by the diffusion of a technical solution in the market through standardizing effects caused by the application of standardization instruments. This approach signals that standardization serves a purpose instead of being a goal in itself. SSO and the wider Open Source community both cause standardizing effects. By creating a level playing field where SSO and the wider Open Source community can collaborate in technical standardization and also compete as standardization instruments based on voluntary participation, innovators and policy-makers can ensure that the most applicable process is chosen for the development of a standard. SSO and FOSS are competitors and complements at the same time. Combined they contribute to realizing the opportunities and help overcome the threats that result from globalization and digitalization. By recognizing the contributions of both SSO and the wider Open Source community to the common good, society has the opportunity to build the foundations for modern institutions that shape and facilitate technical innovation.
About the authors
Mirko Boehm is a visiting lecturer and researcher on free and open source software at the Technical University of Berlin and co-founder of Endocode, now part of Hoverture.
E-mail: mirko [dot] mb [dot] boehm [at] gmail [dot] comDavis Eisape is is a researcher and guest lecturer at the Technical University of Berlin. He is an experienced business developer with a standardization background currently developing platform business models.
E-mail: davis [dot] eisape [at] outlook [dot] de
Acknowledgements
This study would not have been possible without the help of many motivated individuals from academia, industry, the standards development community and the FOSS ecosystem. In the spirit of open collaboration, the authors invited comments and critique as the study progressed. We would like to thank the fellows of the OpenForum Academy, members of the Legal Network and representatives of IEEE-SA, DIN, Linux Foundation and Open Source Initiative and of course our fellow academics for their incredibly valuable feedback. All errors and mistakes inevitably remain our own fault.
The interviewees who participated in this study each have a long-standing professional background and are long term contributors to their respective roles and organizations. We would like to thank Alpesh Shah (IEEE-SA), Dave Neary (Red Hat), David Faure (KDE Community and OASIS), De-Won Cho (DIN e.V.), Dirk Weiler (Nokia and ETSI), Mike Schinagl (Document Foundation and Free Software Foundation Europe [FSFE]) and Thorsten Behrens (LibreOffice) for participating in our study.
For further research the recorded expert interviews are archived and can be obtained at the chair of innovation economics at the Technical University of Berlin.
Notes
1. https://www.iso.org/protecting-our-planet.html.
2. https://www.iso.org/isoiec-27001-information-security.html.
3. https://www.iso.org/iso-9001-quality-management.html.
4. https://www.coreinfrastructure.org/.
5. See for example the LEON CPU architecture, which is licensed under GPL and commercial terms; https://www.esa.int/Enabling_Support/Space_Engineering_Technology/Microelectronics/LEON2-FT.
7. https://www.automotivelinux.org/software.
8. https://opensource.org/docs/peru_and_ms.php.
9. https://www.openinventionnetwork.com/.
11. https://www.openchainproject.org/.
12. https://www.softwarefreedom.org/services/.
13. https://www.din.de/en/about-standards/din-spec-en.
14. https://boss.cen.eu/developingdeliverables/CWA/Pages/default.aspx.
References
O. Almeida, J. Oliveira and J. Cruz, 2011. “Open standards and open source: Enabling interoperability,” International Journal of Software Engineering & Applications, volume 2, number 1.
doi: https://doi.org/10.5121/ijsea.2011.2101, accessed 27 June 2021.J. Baron and D.F. Spulber, 2018. “Technology standards and standard setting organizations: Introduction to the Searle Center database,” Journal of Economics & Management Strategy, volume 27, number 3, pp. 462–503.
doi: https://doi.org/10.1111/jems.12257, accessed 27 June 2021.Y. Benkler, 2002. “Coase’s penguin, or, Linux and The Nature of the Firm,” Yale Law Journal, volume 112, number 3, 369–446.
doi: https://doi.org/10.2307/1562247, accessed 27 June 2021.K. Blind, 2011. “An economic analysis of standards competition: The example of the ISO ODF and OOXML standards,” Telecommunications Policy, volume 35, number 4, pp. 373–381.
doi: https://doi.org/10.1016/j.telpol.2011.02.007, accessed 27 June 2021.K. Blind, 2002. “Driving forces for standardization at standardization development organizations,” Applied Economics, volume 34, number 16, pp. 1,985–1,998.
doi: https://doi.org/10.1080/00036840110111158, accessed 27 June 2021.K. Blind and M. Boehm, 2019. “The relationship between open source software and standard setting,” European Commission.
doi: https://doi.org/10.2760/937637, accessed 27 June 2021.K. Blind and A. Mangelsdorf, 2016. “Motives to standardize: Empirical evidence from Germany,” Technovation, volumes 48–49, pp. 13–24.
doi: https://doi.org/10.1016/j.technovation.2016.01.001, accessed 27 June 2021.CEN/CENELEC, 2017. “CEN and CENELEC Digital Transformation Initiative: Why do we need a strategic approach?” at https://www.cencenelec.eu/news/brief_news/Pages/TN-2017-011.aspx, accessed 11 April 2020.
R.G. Cooper, 2016. “Agile-stage-gate hybrids,” Research-Technology Management, volume 59, number 1, pp. 21–29.
doi: https://doi.org/10.1080/08956308.2016.1117317, accessed 27 June 2021.J. Corbet and G. Kroah-Hartman, 2017. “2017 Linux kernel development report,” Linux Foundation at https://www.linuxfoundation.org/wp-content/uploads/linux-kernel-report-2017.pdf, accessed 27 June 2021.
H. de Vries, H. de Vries and I. Oshri, 2008. Standards battles in open source software: The case of Firefox. London: Palgrave Macmillan.
doi: https://doi.org/10.1057/9780230595095, accessed 27 June 2021.Deutsches Institut für Normung e.V (DIN), 2017. “Main topics of the ISO week in Germany,” at https://open-zone.org/topics.html, accessed 11 April 2020.
European Commission, 2017a. “Communication from the Commission to the European Parliament, the Council and the European Economic and Social Committee: Setting out the EU approach to standard essential patents,” at https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=COM:2017:0712:FIN, accessed 27 June 2021.
European Commission, 2017b. “The new European interoperability framework,” at https://ec.europa.eu/isa2/eif_en, accessed 27 June 2021.
European Telecommunications Standards Institute (ETSI), 2012. “Open Source MANO (OSM),” at http://www.etsi.org/technologies-clusters/technologies/nfv/open-source-mano, accessed 19 January 2019.
K. Fogel, 2005. Producing open source software: How to run a successful free software project. Sebastopol, Calif.: O’Reilly.
E. Folmer, M van Bekkum and J. Verhoosel, 2009. “Strategies for using international domain standards within a national context: The case of the Dutch temporary staffing industry,” at https://ris.utwente.nl/ws/portalfiles/portal/5476537/strategies.pdf, accessed 27 June 2021.
Free Software Foundation Europe (FSFE), 2018. “Public money, public code,” at https://publiccode.eu/, accessed 11 April 2020.
U. Gasser and J. Palfrey, 2007. “When and how ICT interoperability drives innovation,” at https://cyber.harvard.edu/interop/pdfs/interop-breaking-barriers.pdf, accessed 27 June 2021.
J. Gay, 2015. “The principles of community-oriented GPL enforcement” (30 September), at https://www.fsf.org/licensing/enforcement-principles, accessed 11 April 2020.
R.A. Ghosh, 2011. “An economic basis for open standards,” In: L. DeNardis (editor). Opening standards: The global politics of interoperability. Cambridge, Mass.: MIT Press, pp. 75–96.
doi: https://doi.org/10.7551/mitpress/8066.003.0009, accessed 27 June 2021.Harvard Business School, 2005. Strategy: Create and implement the best strategy for your business. Boston, Mass.: Harvard Business School Press.
M.A. Heller, 1998. “The tragedy of the anticommons: Property in the transition from Marx to markets,” Harvard Law Review, volume 111, number 3, pp. 621–688.
doi: https://doi.org/10.2307/1342203, accessed 27 June 2021.A.O. Hirschman, 1970. Exit, voice, and loyalty: Responses to decline in firms, organizations, and states. Cambridge, Mass.: Harvard University Press.
G. Houben, K. Lenie and K. Vanhoof, 1999. “A knowledge-based SWOT-analysis system as an instrument for strategic planning in small and medium sized enterprises,” Decision Support Systems, volume 26, number 2, pp. 125–135.
doi: https://doi.org/10.1016/S0167-9236(99)00024-X, accessed 27 June 2021.International Telecommunications Union (ITU), 2000. “V.24: List of definitions for interchange circuits between data terminal equipment (DTE) and data circuit-terminating equipment (DCE),” at https://www.itu.int/rec/T-REC-V.24-200002-I/en, accessed 11 April 2020.
R. Jenkins, 2001. “Corporate codes of conduct: Self-regulation in a global economy,” United Nations, Research Institute for Social Development, Technology, Business and Society Programme Paper, number 2, at https://www.unrisd.org/80256B3C005BCCF9/(httpAuxPages)/E3B3E78BAB9A886F80256B5E00344278/$file/jenkins.pdf, accessed 27 June 2021.
D.J. Kappos and M.Y. Harrington, 2019. “The truth about OSS-FRAND: By all indications, compatible models in standards settings,” Science and Technology Law Review, volume 20, number 2.
doi: https://doi.org/10.7916/stlr.v20i2.4771, accessed 27 June 2021.M.L. Katz and C. Shapiro, 1986. “Technology adoption in the presence of network externalities,” Journal of Political Economy, volume 94, number 4, pp. 822–841.
doi: https://doi.org/10.1086/261409, accessed 27 June 2021.G. Kroah-Hartman, C. Mason, R. van Riel, S. Khan and G. Likely, 2017. “Linux kernel community enforcement statement” (16 October), at http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/, accessed 11 April 2020.
K.R. Lakhani and R. Wolf, 2003. “Why hackers do what they do: Understanding motivation and effort in free/open source software projects, ” SSRN (15 September).
doi: http://dx.doi.org/10.2139/ssrn.443040, accessed 27 June 2021.J. Lerner and J. Tirole, 2005. “The economics of technology sharing: Open source and beyond,” Journal of Economic Perspectives, volume 19, number 2, pp. 99–120.
doi: http://dx.doi.org/10.1257/0895330054048678, accessed 27 June 2021.B. Lundell and J. Gamalielsson, 2017. “On the potential for improved standardisation through use of open source work practices in different standardisation organisations: How can open source-projects contribute to development of IT-standards?” In: K. Jakobs and K. Blind (editors). Digitalisation: Challenge and opportunity for standardisation: Proceedings of the 22nd EURAS Annual Standardisation Conference. Aachen: Verlag Mainz, pp. T137–T155.
B. Lundell, J. Gamalielsson and A. Katz, 2015. “On implementation of open standards in software: To what extent can ISO standards be implemented in open source software?” International Journal of Standardization Research, volume 13, number 1, pp. 47–73.
doi: http://dx.doi.org/10.4018/IJSR.2015010103, accessed 27 June 2021.G. Luxbacher, 2017. Din von 1917 bis 2017. Berlin: Beuth Verlag.
H. Meeker, 2017. “Patrick McHardy and copyright profiteering” (24 August), at https://opensource.com/article/17/8/patrick-mchardy-and-copyright-profiteering, accessed 11 April 2020.
M. Meuser and U. Nagel, 2002. “Expertinneninterviews — vielfach erprobt, wenig bedacht,” In: A. Bogner, B. Littig and W. Menz (editors). Das Experteninterview: Theorie, Methode, Anwendung. Wiesbaden: VS Verlag für Sozialwissenschaften, (pp. 71–93.
doi: https://doi.org/10.1007/978-3-322-93270-9_3, accessed 27 June 2021.OASIS OpenDocument Technical Committee, 2009. “OASIS Open Document Format for office applications,” at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office, accessed 11 April 2020.
Open Container Initiative, 2016. “FAQ,” at https://opencontainers.org/faq/, accessed 11 April 2020.
OpenForum Europe, 2017. “Standards and Open Source: Bringing them together,” at https://openforumeurope.org/publications/standards-and-open-source-bringing-them-together/, accessed 11 April 2020.
P. Parker-Johnson and T. Doiron, 2018. “Succeeding on an open field: The impact of open source technologies on the communication service provider ecosystem,” at https://www.linuxfoundation.jp/wp-content/uploads/2018/03/LFN_ACG_2018_Impact_of_Open_Source-C_03.26.18.pdf, accessed 27 June 2021.
B. Perens, 2017. “On usage of the phrase ‘Open Source’” (26 September), at https://perens.com/2017/09/26/on-usage-of-the-phrase-open-source/, accessed 11 April 2020.
S. Phipps, 2011. “Open source procurement: Copyrights” (21 February), at https://opensource.com/law/11/2/open-source-procurement-copyrights, accessed 11 April 2020.
T.C. Pohlmann, 2013. “Attributes and dynamic development phases of informal ICT standards consortia,” SSRN (1 March).
doi: http://dx.doi.org/10.2139/ssrn.1633403, accessed 27 June 2021.Red Hat, 2017. “Increasing stability and predictability in open source license compliance: Providing a fair chance to correct mistakes” (27 November), at https://www.redhat.com/en/about/gplv3-enforcement-statement, accessed 11 April 2020.
J.-F. Schrape, 2019. “Open-source projects as incubators of innovation: From niche phenomenon to integral part of the industry,” Convergence, volume 25, number 3, pp. 409–427.
doi: https://doi.org/10.1177/1354856517735795, accessed 27 June 2021.C. Shapiro and H.R. Varian, 1999. Information rules: A strategic guide to the network economy. Boston, Mass.: Harvard Business Review Press.
D.-H. Shin, H. Kim and J. Hwang, 2015. “Standardization revisited: A critical literature review on standards and innovation,” Computer Standards & Interfaces, volume 38, pp. 152–157.
doi: https://doi.org/10.1016/j.csi.2014.09.002, accessed 27 June 2021.S.M. Spivak and F.C. Brenner, 2001. Standardization essentials: Principles and practises. New York: Marcel Dekker.
D.F. Spulber, 2008. “Consumer coordination in the small and in the large: Implications for antitrust in markets with network effects,” Journal of Competition Law & Economics, volume 4, number 2, pp. 207–262.
doi: https://doi.org/10.1093/joclec/nhm031, accessed 27 June 2021.R.M. Stallman, 2002. “Free software, free society: Selected essays of Richard M. Stallman,” at https://www.gnu.org/philosophy/fsfs/rms-essays.pdf, accessed 27 June 2021.
F.F. Suárez and J.M. Utterback, 1995. “Dominant designs and the survival of firms,” Strategic Management Journal, volume 16, number 6, pp. 415–430.
doi: https://doi.org/10.1002/smj.4250160602, accessed 27 June 2021.J. Tirole, 2017. Economics for the common good. Princeton, N.J.: Princeton University Press.
V. Torti, 2016. Intellectual property rights and competition in standard setting: Objectives and tensions. London: Routledge.
P. Ullrich, 2006. “Das explorative ExpertInneninterview: Modifikationen und konkrete Umsetzung der Auswertung von ExpertInneninterviews nach Meuser-Nagel,” In: T. Engartner, D. Kuring and T. Teubl (editors). Die Transformation des Politischen: Analysen, Deutungen und Perspektiven; siebentes und achtes Doktorandinnenseminar der Rosa-Luxemburg-Stiftung. Berlin: Dietz, pp. 100–109.
H.R. Varian, 1998. “Markets for information goods” at https://people.ischool.berkeley.edu/~hal/Papers/japan/, accessed 27 June 2021.
B. von Stamm, 2008. Managing innovation, design and creativity. Second edition. Hoboken, N.J.: Wiley.
W3C, 2015. “XML technology” at https://www.w3.org/standards/xml/, accessed 11 April 2020.
S. Weber, 2004. The success of open source. Cambridge, Mass.: Harvard University Press.
J. Whitehurst, 2015. The open organization: Igniting passion and performance. Boston, Mass.: Harvard Business Review Press.
P.M. Wiegmann, H.J. de Vries and K. Blind, 2017. “Multi-mode standardisation: A critical review and a research agenda,” Research Policy, volume 46, number 8, pp. 1,370–1,386.
doi: https://doi.org/10.1016/j.respol.2017.06.002, accessed 27 June 2021.World Economic Forum, 2016. “Digital transformation of industries: Societal implications,” at http://reports.weforum.org/digital-transformation/wp-content/blogs.dir/94/mp/files/pages/files/dti-societal-implications-white-paper.pdf, accessed 27 June 2021.
Glossary
community
A FOSS community consists of the network of participants that contribute to the creation of specific FOSS software products, predominantly computer programs, in a collaborative peer productions process based on voluntary participation. Communities may be set up implicitly or explicitly as unincorporated associations, as for-profit or not-for-profit legal entities or under FOSS umbrella organizations.
continuous non-differentiating cooperation
Continuous non-differentiating cooperation is a collaboration model implemented in FOSS communities and facilitated by FOSS foundations that enables otherwise competing market actors to continuously cooperate to develop a common software stack that serves as basic, non-differentiating technology prerequisite to products that combine free and proprietary software. In contrast to pre-competitive cooperation on the development of proprietary, differentiating products, anti-trust concerns are not relevant in the continuous non-differentiating cooperation model since collusion is impossible if the results are immediately available to the general public and the development process is generally open for participation to all interested parties. The possibility of forks limits the control individual entities can exercise over the development process.
Eclipse Foundation
The Eclipse Foundation is a not-for-profit industry association (US § 501(c)(6)) that provides a global community of individuals and organizations with a mature, scalable, and commercially focused environment for collaboration and innovation.
fair, reasonable and non-discriminatory
Licensing under fair, reasonable and non-discriminatory terms is a voluntary commitment some standards development organization (SDO) request from a patent owner that participates in standards development. What FRAND commitments entail exactly is not normalized. It is left to negotiation between market participants and usually confidential. This makes it difficult to ensure non-discrimination and is considered to disadvantage FOSS communities, which makes the FRAND concept controversial.
free and open source software
The term free and open source software refers to software that is distributed under a license which complies with the Open Source Definition or respectively the definition of FS provided by the FSF. The Open Source Initiative is the steward that approves licenses for being compliant with the Open Source Definition. Free and open source software is made available to everybody under a license that gives the user the freedom to run, copy, distribute, study, change and improve the software. “‘Free software’ is a matter of liberty, not price” (Stallman and Lessig, 2010). The FSF and the Open Source Initiative maintain lists of licenses15 that provide at least those “four essential freedoms” to recipients of the software. The terms of all licenses that provide these terms turn the product into a public good and also ensure that the product itself will continue to be freely licensed. This effect may or may not extend to derivative works and future versions, resulting in the classification of the licenses into reciprocal and permissive categories.
Free Software Foundation Europe
The Free Software Foundation Europe “is a charity that empowers users to control technology”.
FSF
“The Free Software Foundation (FSF) is a nonprofit with a worldwide mission to promote computer user freedom.”
ICT
“Information and communication technology” describes the computing and telecommunications industry sector. The sector serves the information processing, storage and networking demand of the digital economy.
implementation
In the context of standardization, the term implementation refers to a product that is compliant with the specification of a standard.
intellectual property
Intellectual property (IP) is a term that describes intangible creations of the human intellect that can be controlled by an owning entity, like artistic works, inventions and designs. IP is made a tradeable good through the application of IPR.
intellectual property rights
Intellectual property rights (IPR) is a concept that includes copyright, designs, patents, trademarks and other rights that are associated with IP and are utilized to control permission to use the work through licensing and other relationships.
International Organization for Standardization
The International Organization for Standardization is an international, independent, nongovernmental standard setting body that consists of delegates from national standards bodies, with headquarters in Geneva, Switzerland.
interoperability
Interoperability describes “the ability to transfer and render useful data and other information across systems [...], applications, or components” (Gasser and Palfrey, 2007).
KDE e.V.
KDE e.V. is a non-profit organization registered in Berlin, Germany that represents the KDE Community in legal and financial matters.
Legal Network
The FSFE Legal Network, initially called the European Legal Network, is a “neutral, nonpartisan, group of experts in difierent fields involved in Free Software legal issues. Currently the Legal Network has over 400 participants from different legal systems, academic backgrounds and affiliations”.
Linux distribution
A Linux distribution is a software collection based on Linux that aggregates the work of the wider Open Source community into a complete operating system. Linux distributions are an integral part of the upstream/downstream model because they make FOSS accessible to specific applications like end-user desktops or embedded systems.
Linux Foundation
The Linux Foundation is a not-for-profit industry association (US § 501(c)(6)) dedicated to building sustainable ecosystems around open source projects to accelerate technology development and commercial adoption.
meritocracy
In the context of FOSS, the term meritocracy is used to describe a system where contributors gain reputation in a community solely based on the value of the contributions they make.
national standards body
Countries nominate one SSO that represents them in ISO. These appointed SSOs are referred to as national standards bodies. They often have a special privileged relationship with their country. For example, a treaty between the federal republic of Germany and DIN declares DIN to be the national standards body of Germany, and in turn obligates DIN to the public benefit, among other terms.
open source
The term “open source” is used in this paper and many other contexts as a synonym to FOSS. It originally describes a campaign to promote free software to business (Perens, 2017).
open source culture
A synonym for the open source way.
Open Source Definition
The Open Source Definition formulates the terms software must comply with to be considered FOSS. It is maintained by the Open Source Initiative. By way of the Open Source Definition, especially its unanimous acceptance, the term “open source” gained a precise meaning across the wider Open Source community, and is therefore a term of art and part of open source culture.
Open Source Initiative
The Open Source Initiative was founded in 1998 by Eric Raymond and Bruce Perens. It is dedicated to the promotion of open source software. The term “open source” was coined by the initiative’s founders. It created the initial Open Source Definition. Today the Open Source Initiative is the steward of the Open Source Definition (OSD) and the community-recognized body for reviewing and approving licenses as OSD-conformant. It publishes the list of all approved open source licenses. The The Open Source Initiative is a California public benefit corporation, with §501(c)3 tax-exempt status.
open source way
The colloquial term “the open source way” describes the mutual understanding of software freedom, values and principles applied by the wider Open Source community, especially the norms of non-negotiable FOSS licenses, open governance and meritocracy.
open standard
The European Interoperability Framework requires for open standards to give all stakeholders the opportunity to contribute to the development of the specification, availability of the specification to everybody to study, and for the relevant IPR to be licensed “on FRAND terms, in a way that allows implementation in both proprietary and open source software, and preferably on a royalty-free basis” (European Commission, 2017a).
public good
A public good is a good that is both non-excludable and non-rivalrous. The application of a FOSS license makes software source code a public good.
software freedom
“Software freedom” is what distributing a work under a FOSS license affords the user. While the terms FS and open source are used mostly synonymously today, “software freedom” is a political goal elements of the FS movement aim for. It can be circumscribed as the absence of coercion to use proprietary software (Stallman and Lessig, 2010). Organisations like the Software Freedom Conservancy and the Software Freedom Law Center work to advance software freedom.
specification
In the context of standardization, the term specification refers to a set of documents that describe the requirements to be satisfied by a technical standard.
standardization
Standardization describes an activity of establishing, with regard to actual or potential problems, provision for common and repeated use, aimed at the achievement of the optimum degree of order in a given context (EN 45020:2006).
standardization instrument
A standardization instrument is a mechanism applied by stakeholder that causes a standardizing effect. Examples for standardization instruments are recognized SSO, normalized customs and practices enforced by tradition, codes of behavior that are prevalent in some industry sectors, especially trade, but also industrial consortia, professional charters, or FOSS governance.
standardizing effect
A standardizing effect is observable in the adoption of a common technical solution that results from the application of a standardization instrument.
standards development organization
A standards development organization is an entity whose primary activities are developing, coordinating, promulgating, revising, amending, reissuing, interpreting or otherwise maintaining standards that address the interests of a wide base of users.
standards essential patent
A standards essential patent claims an invention that must be used to comply with a technical standard. SSO establish policies that regulate towards their participants how standard essential patents are expected to be licensed.
umbrella organization
An umbrella organization hosts individual projects within a single administrative structure. The Eclipse Foundation, Linux Foundation and KDE e.V. are examples for umbrella organizations for FOSS projects.
upstream/downstream model
The analogy of the upstream/downstream model uses the mental image of a large river that collects water from many smaller and smaller tributaries (the communities) and delivers it eventually to the ocean (the users). Key tenets of the upstream/downstream model are the nonnegotiability of the FS licensing terms and community governance norms.
wider Open Source community
The phrase wider Open Source community is commonly used to describe the totality of individuals, smaller and larger communities, umbrella organizations and entities collaborating on developing the commons of FOSS in the global upstream/downstream model.
World Wide Web Consortium
The World Wide Web Consortium is an international community that develops open standards to ensure the long-term growth of the Web.
Acronyms
CLA
contributor license agreement
CWA
CEN Workshop Agreement
DIN
Deutsches Institut für Normung e.V
EC
European Commission
EPO
European Patent Office
ETSI
European Telecommunications Standards Institute
EU
European Union
FLOSS
free/libre and open source software see FOSS
FOSS
“free and open source software
FRAND
fair, reasonable and non-discriminatory
FS
free software
FSFE
Free Software Foundation Europe
IEEE-SA
Institute of Electrical and Electronics Engineers Standards Association
IP
intellectual property
IPR
intellectual property rights
ISO
International Organization for Standardization
OIN
Open Invention Network
OpenDocument
Open Document Format for Office Applications
OSS
open source software see FOSS
PMPC
public money — public code
RAND
reasonable and non-discriminatory see FRAND
SDO
standards development organization
SEP
standards essential patent
SFLC
Software Freedom Law Center
SSO
standards setting organization, see SDO
SWOT
strengths, weaknesses, opportunities and threats
W3C
World Wide Web Consortium
Editorial history
Received 9 July 2020; revised 25 February 2021; accepted 27 June 2021.
Dedicating the article to the public domain. This allows anyone to make any use of the article at any time, including commercial use.
Standard setting organizations and open source communities: Partners or competitors?
by Mirko Boehm and Davis Eisape.
First Monday, Volume 26, Number 7 - 5 July 2021
https://firstmonday.org/ojs/index.php/fm/article/download/10806/10183
doi: http://dx.doi.org/10.5210/fm.v26i7.10806
