Interaction in general

The case study report illustrates how most SDOs and OSS communities historically started as coalitions of interested stakeholders. The formal recognition achieved by some SDOs as either national standards bodies or recognised entities at the European or international level is in some specific cases assumed to be a motivator for OSS communities to collaborate with these formal SDOs. OSS communities, however, value partners only based on the contributions they make in a meritocratic model. Open source communities are interested in collaborating with SDOs that do relevant work in the field they are working in. What unifies SDOs in the eye of the OSS world is that they produce specifications for relevant standards. What unifies OSS communities is that they focus on implementation. Formal recognition was not a relevant differentiator of SDOs in the eyes of interviewees from an open source community background, even though it is important for the relationship between SDOs, industry and possibly policy makers.

The results from the literature review, the case studies and the survey all suggest that market actors pragmatically choose combinations of OSS with

proprietary hardware and software. Today, such

combinations are the norm and seen as the working model of most industrial OSS consortia, like the Linux Foundation or the Eclipse Foundation. There is no indication that the market pulls towards a situation where only open source solutions are used. Technology

areas with high cost of change as well as competitive, differentiating product features do not favour open source development models. Voluntary participation also means that neither SDO nor OSS contributors are likely to choose such areas for their OSS development work.

The viability of collaboration between SDOs and OSS communities is influenced by all three layers of

interaction identified in the expert interviews, i.e. cultural fit, governance models and legal framework in

that collaboration has to be possible and to be preferable over working separately. Since neither side can instruct the other, collaboration probably needs to be envisioned as an integrated cyclic process with feedback loops between specification and implementation, and shared responsibility for both aspects between all participants.

Based on the insights from the case studies, we can derive the following general conclusions about the interaction between SDOs and OSS communities.

Where SDOs and OSS communities’ processes are combined, the processes and governance

in the working groups and communities often converge. This may lead to parallel OSS development

processes that incubate new features combined with standardisation processes to establish consensus, as well as a choice for participants of two alternative platforms for collaboration and consensus-building.

It appears that a well-working relationship develops if standards developers and OSS implementers largely overlap and many entities potentially contribute to the development process. Where there

is no such overlap, or in situations where few suppliers maintain control over the market, it can be assumed that cooperation is less likely to develop, and the majority of market participants are merely (commercial) consumers of technology with no participation in standards development.

From the perspective of SDOs, study participants consider their interactions with OSS communities mutually beneficial and serving their joint interest in a specific technical area. The OSS contributors

help to incubate the developed technology and to test the specification, which helps maintain high quality in standards. The partner OSS community often creates the first or only reference implementation, which might become the de-facto standard implementation later in the process. Interaction with the OSS community also inspires the modernisation of SDO processes, for example through the adoption of new collaboration methods and platforms and increased transparency of decision making. Since experts in the specific market segments are rare, there is a noticeable but partial overlap between the individuals involved in standards development and OSS implementation.

The OSS communities describe their interaction with SDOs as fruitful and productive. The

collaboration and consensus building processes encourage the stability of specifications, that would otherwise change quickly and cause interoperability issues. OSS implementations sometimes overshoot the functionality specified in the standards based on the faster pace of development. This may cause a shift in the scope of the technical development. In such cases, SDOs may be slower to update working group mandates and charters compared to the rigorous self-selection processes in OSS development.

Some of the larger collaborative projects do not consider the creation of multiple, standards-compliant implementations as useful, since they prefer all potential contributions to be combined into a single product.

While standards help achieve interoperability of proprietary products that do not share an implementation, OSS users tend to choose a joint implementation for that purpose. In such a scenario,

the best interoperability can be achieved by reducing the number of implementations, ideally to one. Based in that,

some cases explicitly exclude participating in standards development from their organisations remit.

Freedom to operate is a key precondition for contributors to participate in the development process. Confidence in access to the implemented

functionality either through cross-licensing, explicit patent grants in OSS licences or contributor IPR policies are considered necessary for a fast-paced development process. This confidence reduces investment risks and is expected to be achieved at the beginning of collaboration. Multiple case study participants emphasized that they consider the ex-ante acquisition of the required IPR and the absence of negotiation as key advantages of the OSS development process.

Study participants state benefits and costs of a closer integration of standards and OSS development. The combination of SDO and OSS processes may, however, lead to trade-offs, especially to a slower pace of development and lower innovativeness.

Another benefit is that in areas of high technical complexity,

detailed specification in standards and working OSS implementation may support each other and lead to both higher quality standards and better code. A further at least possible cost is that the existence

of IPR frameworks that include SEPs may impose a barrier to collaboration by reducing the number of potential participants, while royalty-free licensing norms on OSS communities may similarly impede contributions from SEP holders.

Even in an open OSS development collaboration, participants are uncomfortable with the possibility that other actors may use the OSS product, including their contributions, to create competing products. While permissive licences like the MIT licence do not provide any protection against such scenarios, reciprocal licensing terms have been mentioned repeatedly as a viable IPR regime that protects contributors from future competition based on their own investments.

The risk of competitors creating commercial, proprietary derivative work is a relevant concern to those participants. An IPR regime based on reciprocal licences like the GPL is considered sufficient protection by those participants. The last section of the stakeholder questionnaire was eventually focused on the interaction between standardisation and OSS. Both in the literature review and in the case studies different types of interactions have already been identified. All three options, i.e. standards

as input into OSS, OSS as input into standardisation and parallel development in addition to the general interconnectedness of standard development and OSS activities are perceived by the respondents to happen on average “sometimes”. The distinction between large and small organisations reveals some more differentiated insights. More than 50% of the organisations with less than 250 employees report that their standardisation and OSS development activities are always or often connected, whereas this is only the case for less than a third of the larger organisations. In particular, for more than half of the smaller organisations OSS is used as input for standardisation, whereas this is only claimed by 15% of the larger organisations. In contrast, there is no difference

between large and small organisations in using standards as input into OSS development. Finally, more than a third of the small organisations claim parallel developments in standardisation and OSS, whereas this is claimed only by 15% of the larger organisations. Overall, standards development and OSS activities are much more interconnected for smaller organisations taking their size into account, which much more often transfer OSS as input into standardisation, whereas

this transfer and even the parallel development is not so common for larger organisations taking their size into account. In relative terms, small organisations contribute much more to the integration of OSS and standardisation than large organisations.

At first, we structure the insights about the interaction between SDOs and OSS according to the three scenarios established already in the literature, i.e. the specification first scenario starting with standardisation, the implementation first scenario driven by the implementation of OSS and finally parallel standards and open source development.

5.5.3.1. Specification first scenario

In the literature, we find a few examples of standards originally released by consortia, in particular OASIS, or SDOs, like ISO and its process to develop public available specifications, which created the basis for further OSS projects. The most prominent is certainly the PDF specification. Common to most of these examples is that they are either released by SDOs following an explicit RF policy, like W3C or OASIS, or referring to an explicit public patent licence. Both proprietary and OSS licensed projects, e.g. under the GPL licence, have implemented these few standards.

According to Phipps (2019), in particular formal SDOs are characterised by an implementation-led rather than a requirement-led standardisation approach.

There are also some standards released by SDOs applying the FRAND regime. However, there are very few declarations of SEPs related to these standards with the exception of the mobile and wireless technologies. Nevertheless, there is still the latent fear of conflicts with potential SEP holders, because of the general contradiction between the FRAND regime and some OSS licensing terms. In particular, the popular GPL is incompatible with FRAND, but there are several other OSS licences, like the MIT or BSD licences, that are likely

compatible with FRAND according to Kappos and Harrington (2019). However, there is no general consensus about this conclusion, because others argue that they are just complementary, but not compatible (Phipps 2019). In

addition, the notion of the incompatibility of the licensing regimes is endorsed by a significant percentage of open source programmers (Bekkers and Updegrove 2013). There are some differences in the interpretation of licences either as contracts or as sui generis legal instruments that make these assessments situational to the applied jurisdiction and difficult to compare. Due to the highlighted relevance of standards implementation for their quality and success, the concerns of the OSS communities related to the ambiguity in the licensing conditions gain further in relevance. Some SDOs have recognised that OSS implementation as an option to promote their standards.

The majority of the projects among the case studies do not consider a specification as the necessary starting point of an implementation. Those that create specifications state well-known benefits like interoperability or enabling independent third-party implementations to improve competition and the general availability of products in the market. This indicates an increasingly utilitarian point of view towards the role of specifications. Specifications are authored, if they provide a tangible benefit. Projects that do not benefit from written specifications often omit them.

Procurement processes, safety or compliance requirements and other conditions, however, continue to reference specifications provided by standards. Fulfilling such external requirements is