How similar are open source development and standards development? Not at all, and even the words they have in common mean different things in each.

It is often asserted that open source and open standards are in some way similar. For example, in the accompanying letter to a recent submission to the European Commission, a major European-based technology company that is very active is standardisation said:

“OSS development is a collaborative effort similar to collaborative standard development in SDOs.”

But there are very few similarities; most people with a good understanding of both consider them to be orthogonal. To start with, the word “open” itself is understood differently in the two contexts.

• In standards development organisations (SDOs) “open” relates to governance. It is used to refer only to the process being accessible to all stakeholders equally. There may be membership fees payable; there may be rights agreements that are mandatory; there may be a vote among existing members whether to accept the new member. All these apply, for example, at ETSI. But the process is considered “open” if no stakeholder is excluded per se. The standards generated, by contrast, may require a fee to access and may be subject to the need to negotiate royalties with multiple parties.
• In contrast, in open source development, “open” refers primarily to the work product being made freely available to anyone in the world to use, improve and share as they wish, possibly with conditions related to attribution and/or making the same freedom available to recipients but never with restrictions or the need to seek permission before use. This is achieved by using an OSI-approved license. The governance of the community is also always transparent but is less frequently included in the understanding of “open”.

The expression “open standards” needs special mention as it consequently has a dual meaning that is the root cause of so much conflict. The OSI created the Open Standards Requirement for Software to address this.

• To many (but not all) in the standards world it means a standard which, during its requirements gathering and creation, was under a process within which every potential stakeholder was free to contribute. In this interpretation an open standard is one created fairly.
• In open source it means one where every potential implementer is free to proceed without further negotiation. In particular, there will be no need to negotiate patent licensing terms. In this interpretation an open standard can be implemented freely.

Then the end product of the activity is very different.

• SDOs produce a standard — essentially a template for specifications. Their work product is not for end-users, but rather is a set of design decisions and metrics that an implementer in their field would use to write a specification and then use it to produce a product. Once complete a standard is inviolable, cannot be adapted, cannot be subsetted, cannot be improved without a full revision process.
• By contrast, an open source project is the final, shipped product received by the end user, which can also be modified in any way at all including to create a different work for different end users. It will be frequently improved and re-released — “release early, release often.”

Then the nature of the collaboration is different.

• The standard is a work of collective authorship at the level of individual words. Any given phrase may have had multiple authors proposing words, values and sentence structures, all themselves complying with a formal vocabulary. Each word, each phrase is a matter of endless debate, argument and compromise, in a process that epitomises rigor. At the end of the process the document fully satisfies no-one but represents instead an acceptable and final majority compromise that endures immutably.
• By contrast, open source software is a quilt made from fragments, each wholly written by a single author to meet their own requirements and contributed freely. Each patch will by default be included as long as it’s not faulty, and only a few parts will prove contentious or a matter of dispute. Each release will be endorsed by almost all developers as their work but will soon change and improve.

Asserting open source and open standards are related is a common trope that has endured for decades, but it’s basically untrue. In many ways they are opposites, and in all others they are orthogonal, even though there are excellent reasons to accommodate both so that their individual strengths can be combined. People that say they are similar either have little experience of one, or are following an agenda that requires the assumption. In both cases, it should be taken as a red flag.