More Thoughts on an API Commons

At Defrag this week got together with Kin Lane at API Evangelist to talk about something we’d been working on together for a while – an initiative to try to encourage sharing and reuse of API Definitions.

We’re greatful for all the feedback and coverage we received (see – Techcrunch, Forbes), Wired, ZDNET, Dr. Dobbs and elsewhere + also the Twitter and Event feedback. Some tweets summarized it best:

and there were interesting discussion points and questions (see below).

What’s is API Commons, and Why do it?

The presentation from the event is embedded below for the details, but in a nutshell the objective of API Commons is:

To encourage sharing and re-use of API Specifications – whatever form they may take

Hence the the initiative aims to encourage API Designers to share their interfaces in an open, un-encumbered way (using Creative Commons licenses) and permit other people remix, evolve and re-use those descriptions.

While it might not be appropriate or beneficial for all API owners to do this (in some cases it may cut into competitive advantage or have other consequences) in many cases there would be huge benefit both to API Owners and re-users to do this since it builds up an unrestricted body of reusable API definitions.

The more definitions are shared, the lest fresh code needs to be written for the various different instances of APIs doing similar things. As the number of APIs grows we see this as a major benefit in terms of:

  • Reducing the number of distinct API interfaces and increasing their robustness / quality over time.

  • Increasing the number of APIs out there by making best practice, client libraries and other code more easily available

Ultimately we think it’s one of the major factors that needs to function for a healthy API Economy to take off.

Who is it for?

We expect API Commons to initially be most useful for government, non-profit, education and other similar sectors since these have the most to gain. Ultimately though we think commercial APIs will also benefit significantly – publishing APIs to the commons will increase adoption of those desing patterns and re-use reduces labour. See the slide deck for more discussion on this.

What API Commons isn’t

As well as saying what APICommons is, it’s also worth saying what it isn’t (at least for a few specific items). Specifically:

  • It is not an attempt to promote a specific API Definition format. Any format is welcome – the point is just to enable people signal that a definition (whatever format it is in) is re-usable. A great twitter discussion started by Darrel Millar’s Tweet below highlighted this

  • It is not an approval process for API specifications. I.e. there is no vetting of specifications or quality control – we see this as a 100% bottom up effort and merley provide the means for people to state licensing for their designs. Each person who posts a design is responsible for the content.

  • It is not a standards organization. There are plenty of existing bodies for standardizing Internet and Web protocols (W3C, IETF etc.) and these should be used as and when appropriate. API Commons effort is solely to promote openness and sharing – there may be some decisions on formats for specifying licenses etc. – but these are informal and recommendations only, we do not expect them to take on the character of standards. Should it be appropriate in the future any results of this discussion would submitted to the corresponding existing body.

  • It is not a legal entity or part of any company. The initiative is purely informal at the moment and if in the future it proved useful a non-profit organization of some form would be formed. While 3scale and API Evangelist and moving the initiative along, there are no corporate objectives or aims behind this – we expect those that contribute most to ultimately have the most important voices in direction.

Here is the tweet from Darrel Miller:

See our follow ups.

What next?

The best way to get involved is to check out APICommons.org and also join the discussion list here. There are many technical challenges and no doubt the road to take up will be long, but hopefully a lot will be learned along the way!