The theme this week at Meshed was standards and open source. A recent post explained how open source and open standards are essentially unrelated, almost contrasting concepts joined philosophically by some based on their application in some industries. Two posts this took look at the consequences of that reality. To summarise the contrast in this context:

• Open source describes a process with a widely adapted software work-product under an OSI-approved license that is in actual deployment by many people, who collaboratively evolve it in sync with their needs – typically rapidly. As such it needs every user to be free to use, improve and share the software and their improvements freely, without negotiation ex ante (or indeed post hoc negotiation, which is the ultimate buzz-kill for open source).
• Meanwhile open standards describes a process that’s open to all potential stakeholders to create a singular work product where the design of future systems can be made interoperable by default – no inherent rush. As such it needs to be methodical, precise, evaluate every character added to the document, check for contributors advantaging themselves unfairly and focused on delivering an immutable final document.

On cultivating blueberries

Those don’t sound too similar, and they aren’t. While there is scope for links (such as using open source tools like Git for both), creating a “hybrid” of these two things is a bit of a leap and pretending one can be done under the rules of the other is pure fantasy. So Tuesday’s post wove an allegory of gardening, considering how the gardener cultivates different plants according to their different needs and concluding that, just as with growing both blueberries and flowers, cultivating open source at a standards organisation means creating a specially-crafted set of conditions so it can flourish.

As if to endorse that, the Linux Foundation’s Mike Dolan posted comparisons on Twitter between two projects trying to solicit open source collaboration with the same technologies, one using open standards rules and one using open source licenses and approaches.

5 ways to accommodate open source at an SDO

Thursday’s post then drilled down into that conclusion, proposing a five-layer model for accommodating open source at a standards body.

Most standards bodies are well advanced along that model but there are one or two where certain companies with high revenues from collecting royalties from implementers on patents they were permitted to embed in “open” standards have heavily pushed back, attacking even the mention of open source and preventing the emergence of sound policies at the SDOs in question. So the post proposed ending that stalling and creating carefully separated “spaces” at their SDOs where open source can be cultivated under rules that actually encourage open source collaboration. The post highlighted tools to help that progress, such as policies from other SDOs (especially ECMA and OASIS) and the matter-of-fact guidance of OSI’s Open Standards Requirement for Software.

All this could prove a discussion point for next Thursday’s OFE Standards Lounge. Let’s see! Meanwhile we expect the discussion to return to OSPOs here on Tuesday. Please subscribe to make sure you don’t miss anything.