The idea of an API commons is one of the most hopeful things I’ve ever worked on, and also one of the clearest measures of how much ground we’ve lost. A commons is a resource held and stewarded in common — not owned by any single party, not enclosed and extracted from, but shared, reusable, and governed for collective benefit. Applied to APIs, the commons is the radical-sounding but actually quite practical idea that API definitions, schemas, data models, and the public data flowing through them could be openly licensed shared goods rather than proprietary assets locked up for control and rent. I still believe in the potential of this more than almost anything, even as I’ve watched the platforms enclose more and more of what could have been common.
I launched the API Commons in 2013, with 3Scale, as a direct response to the Oracle v. Google fight over whether APIs could be copyrighted. The premise was simple and the stakes were enormous: provide a transparent mechanism for the copyright-free sharing and collaborative design of API specifications, interfaces, and data models. A Creative Commons for API designs. The reason this mattered is that API interfaces are how software interoperates, and if interfaces could be copyrighted and locked up, the entire premise of an open, interoperable web was in jeopardy. The API Commons was a GitHub-based place where the most important and meaningful API interfaces and their underlying data models could be hung out in the open, licensed for reuse, so the industry could build on shared designs rather than reinventing and re-enclosing the same patterns endlessly.
What I understood even at launch, and what I’d emphasize most about the potential, is that the API Commons was always more than the definitions, specifications, and schemas it held. The largest benefit was never going to be the artifacts themselves — it was the process, the community, and the culture that would form around them. The real work was bringing everyone out of the shadows, getting them to work on their API designs in a collaborative, reusable way, across government and across industries. A commons isn’t a repository; it’s a practice of working in the open together. The artifacts are just the residue of that practice. That’s the part I’d want anyone to grasp about the potential — the value isn’t in a pile of openly licensed OpenAPI files, it’s in an ecosystem of people who’ve agreed to design in common.
The copyright fight is the foundation under all of it, because copyright is the mechanism of enclosure. APIs had technically been copyrightable since a 1989 case, but the industry had mostly ignored it until Oracle decided to monetize Google’s reimplementation of the Java APIs. I signed onto the EFF briefs and the computer scientists’ brief urging the courts to keep APIs free from copyright, because the freedom to reimplement and extend existing APIs is exactly what produced robust software and hardware industries in the first place — UNIX, the IBM PC BIOS, the C language, Pinboard reimplementing the Delicious API. My favorite way to explain it is the restaurant menu analogy: the API design is the menu, not the restaurant. The value and the real intellectual property are in the kitchen, the ingredients, the service — the backend. The menu just tells you what you can order. If you can’t see the separation between an API and its design, you either don’t understand APIs well enough or you’re too concerned with monetization and control. And by the time the case was heading to the Supreme Court, I’d come to see API copyright as part of a larger pattern — the relentless expansion of intellectual property law, driven by large corporations, reducing every form of creativity and expression down to a transaction so it too can be owned. The commons is the answer to that enclosure.
Schemas and shared vocabularies are where the commons potential is most underexploited and most obviously beneficial. I generated OpenAPI specifications for hundreds of Schema.org types because Schema.org is exactly what a data commons looks like — a rich shared vocabulary that lets everyone speak the same way about common things. When APIs speak using common, shared schema, everything works more smoothly and we make sense to a wider audience. The failure to define our schema in shared, machine-readable, reusable form is a big part of why the API space is so cluttered and fragmented. The potential of a schema commons is enormous: stabilize and standardize APIs by getting them to speak a common language, so that integration stops being a bespoke act of translation every single time. We have the pieces — Schema.org, the specification standards, open licensing — but we’ve consistently under-invested in actually holding them in common.
Public data is where the commons stops being a technical idea and becomes an urgently political one. Our economy depends on a steady flow of data from the public sector, and APIs are how we quantify, defend, and evolve that value — or how we let it be extracted. I’ve used the public lands analogy deliberately: public data is like public land, a shared resource, and the lesson of public lands is that you can allow renewable extraction — water, minerals, timber — as long as it’s managed and the value flows back to the public rather than being privatized. The Google Maps story is the cautionary tale. Cash-strapped public agencies generate enormous public value, Google builds on it, and the value flows into Google while the agencies get nothing. That’s enclosure of the commons in real time. My argument in the public data commons work was that we should use the same API management practices the private sector uses — keys, plans, rate limits, observability — not to lock public data up, but to quantify and protect it from exploitation, ensuring collective public resources keep benefiting everyone and not just the few technically savvy entities positioned to extract them. API management in service of the commons rather than against it. Locking up a public taxonomy, the way some organizations still do, is short-sighted and wrong — there are other ways to fund and evolve shared infrastructure, the way open source already demonstrates.
My more recent thinking has reframed the commons in language that meets organizations where they actually are. I’ve started preferring “common” over “centralized,” because the words set the tone. Centralization is what out-of-touch leadership mandates — being told to do something without being given the resources to do it. Common is something shared across teams, put into a commons that makes sense to the people on the ground. It’s a small linguistic shift with a real political difference: centralization is control imposed from above, while the commons is shared stewardship that teams can actually buy into. The same instinct shows up in how I think about specifications now. When most people see an OpenAPI or AsyncAPI spec, they see technology. I see a common language and a common understanding — the hard-won, expensive, accumulated work of getting people on the same page, speaking the same way about how they integrate. Specifications are commons. The years of investment in getting an enterprise aligned around shared specs is exactly the process-and-culture value I was describing back in 2013, just realized inside organizations instead of across the whole industry.
The honest reckoning is that the potential of the API commons has been largely unrealized, and that’s a political outcome, not a technical one. The early API economy had a genuine commons character — shared, accessible, interoperable, built on the back of publicly subsidized infrastructure that everything on the web still owes a debt to. Money and power enclosed much of it. Platforms that rose on open APIs locked them down. Public data got extracted by commercial interests. The copyright fight had to be fought because the enclosure instinct never went away. But the potential is still there, and it’s still worth fighting for, because the alternative is a fully enclosed digital landscape where every interface, every schema, every public dataset is someone’s proprietary asset to meter and control. The commons is the political claim that some of this should belong to all of us — that the surface area of how software interoperates, the vocabularies we share, and the public data our economy runs on should be held in common, openly licensed, collaboratively stewarded, and protected from enclosure. I built the API Commons because I believed that, and I still do. The work now is less about a single platform and more about defending the commons instinct everywhere it still survives — in open specifications, in shared schemas, in public data, and in the simple, radical idea that we’re better off designing in the open, together.
References
- Help EFF Make The Case For No Copyright On APIs
- Helping EFF Urge The Courts To Block Copyright Claims In Oracle v. Google API Fight
- Putting The Open In API With The API Commons
- API Commons Is More Than Just The Definition, Specification Or Schema
- Green Button (Energy) API Added To API Commons
- Restaurant Menus As Analogy For API Copyright
- OpenAPI Specifications For 642 Of The Schema.org Types
- Using Public Lands As An Analogy When Talking About Public Data APIs
- API Copyright Heading To The Supreme Court
- Helping The Public Data Commons Drive Our Economy Using APIs
- Using Common Instead Of Centralized
- You See A Spec, I See A Common Language, And A Common Understanding
