The case for open protocols

In my previous post on making groups work I argued that a centralised, cooperatively owned platform could be one of the most effective ways to catalyse the co-creation of a new economy, right now.

My argument for centralisation is based wholly on practicalities – and the urgency of the need. The climate emergency, coupled with the other systemic challenges we face (debt, inequality etc), require urgent collaborative action right now. We do not have a second to lose.

In her excellent post on Redecentralize, Ira Bolychevsky argues that instead of breaking up big tech, we need to break them open. Ira urges:

“We need to regulate Facebook and others to force them to open up their APIs to make it possible for users to have access to each other across platforms and services.”

I agree although, in this age of the omni-potent tech giant and sold-out governments, I’m not sure how likely that is… However…

There is a clear argument to be made for utilising open protocols rather than relying on centralised platforms to enable collaboration to flourish.

It’s not immediately obvious what that means – let me try to explain with an example:

You can use an Android phone to call an iPhone because telephone calls use an open protocol. The protocol enables any device, made by any manufacturer, to call any other device by specifying the ‘standard requirements’ for a phone call.

Email is another good example:

You can email from Gmail to Hotmail, or any other email provider or host because emails run on open standards such as SMTP, POP3 and IMAP.

It look me a while to grasp the importance of this – and the value that open protocols offer over closed platforms (i.e Facebook), and even cooperatively-owned, open source platforms without a means of communication with other systems (an API) which effectively makes them ‘walled gardens’. The more you think about it, the more obvious it becomes that developing open protocols, in every sector and every industry would liberate decentralised collaboration at scale.

Mike Masnick, argues that:

“Moving to a world where protocols and not proprietary platforms dominate would solve many issues currently facing the internet today. In short, it would push the power and decision making out to the ends of the network, rather than keeping it centralized among a small group of very powerful companies. At the same time, it would likely lead to new, more innovative features as well as better end-user control over their own data. Finally, it could help usher in a series of new business models that don’t focus exclusively on monetizing user data.”

I made the case for “protocols over platforms” at OPEN 2018 and, although the world did not change overnight, the idea did resonate with at least one person. Tony Shannon has been developing ways to collaborate on the building of open protocols for several years – promoting the case for open protocols in healthcare.

Developing open protocols

Tony grew up in the NHS, working in emergency medicine. He learned about how change happens (and doesn’t) within organisations and witnessed an NHS IT project (estimated cost £6 billion – final cost £12 billion) end in disaster. Tony moved on to found the non profit Ripple foundation, which promotes open standards and protocols in health care.

At Ripple, they’ve developed a system called OpenEHR (pronounced “open air”) to identify the core processes of healthcare – and the related data requirements – to make it easier to share data between all the people and processes within the healthcare system. But, as Tony points out, the activities which underpin openEHR are not just relevant to healthcare – they are generic pattern which underpins all of human endeavour.

The four activities which underpin openEHR, and all problem solving processes, are:

1. Observation
2. Evaluation
3. Instruction
4. Action

If we take farming as an example, and look at what farmers do, they follow the same steps: They observe the field and the weather and evaluate which seeds to plant, where and when, they instruct people or machines to take action to plant the seeds and observe and evaluate the results, and so on, in a continual loop from sowing to harvest.

We do the same activities ourselves when we walk down Oxford Street. We observe the crowds, evaluate a safe route forward, instruct our legs which way to move and take action as we walk forward. And repeat.

The point here is that by breaking things down into these four activities we have an approach for developing open protocols which could be used in any sector.

In Tony’s sector they have been using openEHR to define an open protocol for how to measure someone’s blood pressure, and hundreds of other kinds of observations and assessments in clinical medicine. The ‘maximum archetype’ they have developed for blood pressure contains every possible attribute you might need to know in relation to blood pressure and has been peer reviewed by thousands of people around the world. An editor coordinates discussion about the development of the archetype and the platform translates between users – making it language independent.

This ‘maximum archetype’ for blood pressure provides an international standard which can be used locally, as required. A local physician might only record partial data when measuring someone’s blood pressure but, by conforming with the standard the data remains technology, vendor and language independent, avoids translation and makes it infinitely more usable by other healthcare systems – massively benefiting the patient and reducing cost for the industry.

Open protocols supersede open APIs by an order of magnitude

If you work with technology you will have noticed the increased frequency with which you hear the initials API. An API is an Application Programming Interface which, put simply, enables one system to interact with another.

In healthcare, just like every other industry, people have realised it would be much better if all their different systems could talk to each other and are working on APIs to send data from one system to another. The same is happening in banking, in farming and every other sector.

Tony is not convinced that this is the answer:

“The efforts are noble, but they are treating each others’ system as black boxes – they’re not working on real collaboration between systems! The usual process means they end up agreeing a minimum data set between providers, rather than maximum data sets – so they lose a huge amount of value.”

He has a point. Why would we not want to standardise all the components within our systems?

“It’s not just about sharing data – challenge #1 is making sure the systems we design fit with the generic processes of the provider who is working with that system. You then have to ask “What are the generics processes and components which work for everyone?” If you take a generic approach to components it makes it possible to deploy the system in other settings. Shared protocols supersede open APIs by an order of magnitude.”

Platform co-ops, and the collaborative economy, need to take a federated approach to architecture. We need to work out ways of developing open protocols, together.

The challenges are vast. In the short term there is no doubt that APIs have a role to play as does the development of common components – but there’s a huge education job to be done to increase the understanding and development of open protocols.

You could argue that a well used API is an open protocol but if it’s not designed collaboratively as a ‘maximum archetype’ it’s always going to be lacking something, for someone. And, as Tony points out, the healthcare sector has gone for 10 years trying to agree APIs – and they’ve still not managed.

Isn’t it time we tried a different tack – and focused our efforts on developing open platforms and protocols which enable technology, vendor and language independent collaboration – so we can really start to collaborate at scale?

Could we, as a sector, work together to define what an open protocol for platform co-ops would look like?

And what about an open protocol for mutual credit – as the foundations of a global mutual credit economy?

If you are interested in discussing ideas for open platforms and protocols please join us at OPEN 2020 in London on the 11th and 12th of June.