A couple of weeks ago I was in Florida giving a talk on Open Source, Open Data in which I tried to describe what open data was. In preparation for that talk, I went looking for definitions of “open” as it applied to either field, and found myself drawing on the following documents:
In the end I structured my talk around the four freedoms because, let’s face it, they’re snappier — but this is all just background.
In any case, I’ve started to collect articles that talk about openness, and in the last couple of weeks I’ve seen a burst of them. Perhaps I’m just hyper-aware at the moment, or maybe we’re going through a phase of introspection about the whole idea. In any case, I thought I’d post a round-up of recent posts on describing, defining, and measuring openness for software, data, APIs, and the communities and processes that surround them.
From the OpenGeoData blog, The Cake Test for determining whether geodata is truly open:
What is the Cake Test? Easy: A set of geodata, or a map, is libre only if somebody can give you a cake with that map on top, as a present.
Cakes are empirical proof that most the data in most SDIs cannot be used freely, because of the licensing terms of the SDIs. And they are an empirical proof that attendants to the latest spanish SDI conference could taste themselves.
Louis Gray, The blurry picture of open APIs, standards, data ownership:
Following the much-discussed news of Facebook debuting its “Open Graph API” on Wednesday, I traded a few e-mails with a few respected tech-minded developers, and found, unsurprisingly, that not everyone believes Facebook is fully “open”. In fact, it’s believed some companies are playing fast and loose with terms that should be better understood.
To quickly summarize the discussion, there are essentially three major ways to bucket “open” APIs…
- open access
- APIs that leverage open standards
- open standard APIs like OpenSocial, OpenID, PubSubHubbub, AtomPub and others
In short, you have “open but we control the process”, “standing on the backs of open” and “truly open”, if this opinion is accepted. The developer adds, “In short, the first two mean nothing, the last one actually fits the dictionary definition. The Web is built on open standard APIs and protocols.”
Simon Phipps, A software freedom scorecard (video from a talk at the South Tyrol Free Software Conference last week) describes why an OSI-approved license isn’t enough to guarantee software freedom, and describes a number of indicators you can use to quantify the freedom of a given piece of software.
Matt Zimmerman, Open vs. open vs. open: a model for public collaboration describes three axes of openness for open source projects:
Open (available)
In order for your project to be open to anyone, they need to be able to find out about it and experience it for themselves.
Open (transparent)
The next flavor of openness is about transparency. This means enabling people to find out about what is happening in your project.
Open (for participation)
The third type of openness is open participation. This builds on transparency by creating a feedback loop: people observe activity in your project, react to it, and then actually change its course.
Finally, Melissa Draper posted about Open community, pointing out external commentary and even criticism is a natural part of having an open (transparent – to use mdz’s term) community.
(Note: Some blockquoted sections above have been edited for length.)
Got any other good links — especially recent ones — on the topic? I’m sure I’ve missed some.