I’ve been involved in a few conversations recently about what “open” or “being open” means in different situations.
As I’ve noted previously when people say “open” they often mean very different things. And while there may be a clear definitions of “open”, people don’t
often use the terms correctly. And some phrases like “open API” are still, well, open to interpretation.
In this post I’m going to summarise some of the ways in which I tend to think about making something “open”.
Let me know if I’m missing something so I can plug gaps in my understanding.
Openness of a “thing”
Digital objects: books, documents, images, music, software and datasets can all be open.
Making things open in this sense is the most well documented, but still the most consistently misunderstood. There are clear definitions for open content
and data, open source, etc. Open in these contexts provide various freedoms to use, remix, share, etc.
People often confuse something being visible or available to them as being open, but that’s not the same thing at all. Being able to see or read something doesn’t give you any legal permissions at all.
It’s worth noting that the definitions of open “things” in different communities are often overlapping. For example, the Creative Commons licences allow works to be licensed in ways that enable a wide variety of legal reuses. But the Open Definition only recognises a subset of those as being open, rather than shared.
Putting an open licence on something also doesn’t necessarily grant you the full freedom to reuse that thing. For example I could open source some machine learning software but it might only be practically reusable if you can train it on some data that I’ve chosen not to share.
Or I might use an open licence like the Open Government Licence that allows me to put an open licence on something whilst ignoring the existence of any third-party rights. No need to do my homework. Reuser beware.
Openness of a process
Processes can be open. It might be better to think about transparency (e.g. of how the process is running) or the ability to participate in a process in this context.
Anything that changes and evolves over time will have a process by which those changes are identified, agreed, prioritised and applied. We sometimes call that governance. The definition of an open standard includes defining both the openness of the standard (the thing) as well as the process.
Stewardship, of a software project, or a dataset, or a standard are also examples of where it might be useful for a process to be open. Questions we can ask of open processes are things like:
- Can I contribute to the main codebase of a software package, rather than just fork it?
- Can I get involved in the decision making around how a piece of software or standard evolves?
- Can I directly fix errors in a dataset?
- Can I see what decisions have been, or are being made that relate to how something is evolving?
When we’re talking about open data or open source, often we’re really talking about openness of the “thing”. But when we’re making things open to make them
better, I think we’re often talking about being open to contributions and participation. Which needs something more than a licence on a thing.
There’s probably a broader category of openness here which relates to how open a process is socially. Words like inclusivity and diversity spring to mind.
Your standards process isn’t really open to all if all of your meetings are held face to face in Hawaii.
Openness of a product, system or platform
Products, platforms and systems can be open too. Here we can think of openness as relating to the degree to which the system
- is built around open standards and open data (made from open things)
- is operated using open processes
- is available for wider access and use
We can explore this by asking questions like:
- Is it designed to run on open infrastructure or is it tied to particular cloud infrastructure or hardware?
- Are the interfaces to the system built around open standards?
- Can I get access to an API? Or is it invite only?
- How do the terms of service shape the acceptable uses of the system?
- Can I use its outputs, e.g. the data returned by a platform or an API, under an open licence?
- Can we observe how well the system or platform is performing, or measure its impacts in different ways (e.g. socially, economically, environmentally)
Openness of an ecosystem
Ecosystems can be open too. In one sense an open ecosystem is “all of the above”. But there are properties of an ecosystem that might itself indicate aspects of openness:
- Is there a choice in providers, or is there a monopoly provider of services or data?
- How easy is it for new organisations to engage with the ecosystem, e.g to provide
competing or new services?
- Can we measure the impacts and operations of the ecosystem?
When we’re talking about openness of an ecosystem we’re usually talking about markets and sectors and regulation and governance.
Applying this in practice
So when thinking about whether something is “open” the first thing I tend to do is consider which of the above categories apply. In some cases its actually several.
This is evident in my attempt to define “open API“.
For example we’re doing some work @ODIHQ to explore the concept of a digital twin. According to the Gemini Principles a digital twin should be open. Here we can think of an individual digital twin as an object (a piece of software or a model), or a process (e.g. as an open source project), or an operational system or platform depending on how its made available.
We’re also looking at cities. Cities can be open in the sense of the openness of their processes of governance and decision making. They might also be considered as platforms for sharing data and connecting software. Or as ecosystems of the same.