Readers of the blog will know that I am an enthusiastic supporter of open platforms and was pleased to be able to contribute to the recent publication of “Defining an an Open Platform” by the Apperta Foundation. Assiduous readers will have noticed that the eight principles in this document are a evolution of those that first appeared here 18 months ago in 2016.
I had thought that “Defining an Open Platform” makes it clear that open platforms are agnostic with regard to software licensing and IPR. However, I’m receiving comments where people continue to conflate open platforms and open source.So to be clear:
Open platforms are about open standards they are not about and do not require open source software.
An open platform can be created without a single line of open source code or indeed without a single line of proprietary code if that’s what those building it want. While, in practice neither of those extreme choices is either likely or desirable both are possible.
Open platforms are about standards and while these standards will often be, but are not always, “open source” the software that implements them need not be.
The core principle of an open platform is that access to data and services on the platform is via a set of open APIs that accept and return data in an open, shareable and computable format. Definitions of these APIs need to be open so that any willing party can freely implement them. As long as all participants in a open platform ecosystem conform to these APIs both applications and data are portable and vendor lock-in is no more, irrespective of whether components and applications are open source or proprietary.
Today, most large scale implementations of open platforms (e.g. that in Moscow) consist primarily of proprietary applications running on a proprietary platform – Moscow uses the Marand openEHR Clinical Data Repository and the Forcare implementation of IHE-XDS, both are proprietary implementations of open standards. The key difference is that Moscow can, and indeed has, switch out these proprietary products and replace them with an alternatives if a vendor fails to deliver performance or value.
There are of course open source alternatives to these proprietary products and the existence of these is important in ensuring proprietary vendors stay true to the standards. It’s also true that proprietary implementations often contain open source components (many of which come from the proprietary vendors themselves who understands the wisdom of sharing and open sourcing certain components.)
My expectation is that successful open platform ecosystems will be a mixed economy of open source and proprietary components and applications. I think it more likely that economically sustainable open source models will emerge in relation to platform infrastructural components than for applications However, there is nothing in the definition in “Defining and Open Platform” that mandates an open source.