Will Open Source Projects be the Standard Setting Organisations of the Future?

25 November 2015

Author: Graham Taylor

It is eight years since I last was able to present to a conference organised by ETSI. Then I gave to an audience solely made up of telecoms professionals the good news about the impact that Open Source was likely to have on the market, and the ‘demise’ of FRAND licensing model in favour of RF. Predictably my messages then were not met with overwhelming joy and favour, but what a difference eight years make. This week ETSI hosted a Summit on Standardization and Open Source with the synopsis talking about the ‘ubiquity’ of Open Source and a genuine wish to grasp the practical issues involved of aligning Standardisation with Open Source.

The surprise for me at least was the degree to which mainly telecoms projects and standards under development have already embraced Open Source – both in their selection of tools, processes, reference implementations etc., and in their engagement with Open Source-based code development projects. But just how far were they developing open standards themselves that would allow Open Source projects to flourish?

The surprise for me at least was the degree to which mainly telecoms projects and standards under development have already embraced Open Source.

Alongside me speaking were strong examples of work in progress, as well as well known fora/consortia like OASIS, W3C, IETF, ECMA etc. For them, unsurprisingly, Open Source clearly was already the norm – they’ve managed to develop the governance, IPR and relationships that made active and pragmatic collaboration a reality.

So my chosen focus was to concentrate both on the business drivers that are encouraging industry to see Open Source participation as a fundamental aspect of its business development, as well as the blockers that I saw still limiting collaboration.

Using the analogy of Open Innovation, I talked about the realisation of core business value, the essential collaborative nature and the real impact of open communities. Fortunately within all the talks there was commonality and acceptance of the differing roles of a standards body and of an Open Source development project – for the former the key deliverable was the specification, for the latter it was the code itself. So my proposition was very much the opportunity for synergy and collaboration. Interoperability is a common objective, but for software projects the options were either to fully utilise existing open standards, if available, or, if not, to realise the potential of internally developed APIs. For the latter, wouldn’t it be a better approach to collaborate with an Standards Setting Organisation (SSO) which maybe has more refined processes in place to ensure the long term governance and maintenance of that standard?

Currently, it seems to me that the perceived needs of SSOs (particularly outside the main fora/consortia) to work with Open Source probably outweigh those of Open Source project developers to work with SSOs. But that might only be a transient position. As the growing maturity of leading Open Source projects, such as those organised under the aegis of groups such as (for example) the Apache Software Foundation, the Eclipse Foundation, the Linux Foundation and the Document Foundation… have shown, the ongoing maintenance of the entire stack becomes fundamentally important in long-term planning. So the choices might be either for the project effectively to become an SSO itself, or to seek the symbiotic relationship that an SSO might offer. I know where I would put my money.

So full credit to ETSI for the event, but it’s not to say there were not elephants in the room. Firstly, the lack of attention to IPR – who selects the licence in such a partnership? For many in telecomms, the wish to maintain the role of patents and FRAND licensing models remains. The promise from ETSI is a further workshop in 2016, but personally I would question the need for further high-level debates. The reality is that (in IT at least) the issue is now of detailed practical implementation rather than top level debates. The expertise is now there in abundance.

A second ‘elephant’ concerns the need for real understanding of the difference in terms – particularly Open Standards (rather than just ‘Standards’ or ‘Specifications’), to differentiate Europe’s legislative definitions. In IT, Open Standards are now well recognised – the debate has moved on – but if we’re to achieve true integration, then understanding that the rationale of Open Standards covering openness of the availability of the standard, as well as its governance, takes on a different dimension. Is it time to restart the education process?