InfoQ asked Kin Lane, the leading API evangelist, to share his views on open API designs and on what led him to launch the API Commons initiative last November with Steven Wilmott.
After receiving positive reactions, Kin is even more convinced of the importance of open sourcing API designs and shaping common patterns from which all API designers can benefit.
He explains how translation and interoperability between the emerging API description languages matters, and how an open internet culture should prevent API Commons from doing the same mistakes as past initiatives like UDDI.
InfoQ: Hi Kin, can you briefly introduce yourself and explain what led you to launch the "API Commons" initiative last November?
I am the API Evangelist, not for any specific API, but APIs in general. I provide analysis on the business and politics of APIs, across all business sectors and the government, via my blog API Evangelist.
Steven Wilmott from 3Scale, and I were having a series of conversation last fall, following some work I did on a brief filed in the Oracle vs. Google, by EFF. We both felt like there should be a place where API providers could publish the API designs, defined using emerging API definition formats like API Blueprint, RAML and Swagger, and take a stance on the copyright of their API design, using the Creative Commons license of their choice.
We feel strongly that API designs should remain openly licensed, allowing for re-use of the best API patterns available today. People tend to emulate what they see, and without common patterns, providers tend to reinvent the wheel each time. In 2014, you should have common patterns for calendars, directories, images, videos and other resources we depend on every day for personal and business apps.
InfoQ: How was the launch received in the API developers' community and in the industry in general, and what have you learned so far?
The launch was very well received. In large part the response was positive, there were a handful of folks in the industry who feel it isn't the right approach, but that time would tell. The result has been lots of continued discussion online, and at events like API Strategy & Practice, API Days and Gluecon around why this is important.
We have learned that much more conversation and education must occur around different approaches to API design, the multiple formats available, and the varying motivations for why you want to not just define your API, but publish it publicly in a commons.
The API Commons won't be built overnight. It will take the work of many leaders from the API space, several years to fully realize the original vision of the API Commons.
InfoQ: What are the incentives for API providers to share their API definitions? Shouldn't they fear about losing an advantage if their competitor can re-implement their API?
When you publish your API publicly, you are already putting it out there. Anyone can reverse engineer your API design, and re-use. Why not take a stance as the provider, be proud of your design, publish it in a machine readable format, with an open license that fits your objectives—take control.
Your API definition is not your secret sauce, it's the resource behind the implementation. You are better off taking a lead stance with the design, in a way that encourages partnership, and re-use, within your control, as opposed to someone doing it without your knowledge. It is happening, people borrow and re-use API designs already - they just aren't talking openly about it.
Why not bring these conversations out in the open, showcase the best patterns in the space and have a conversation around how they are used much like we already do with open source software.
InfoQ: There is an ongoing legal battle between Oracle and Google regarding the implementation of Java APIs in Android. What did you learn so far from this case regarding the ability to copyright APIs and the "fair use" of APIs?
Java is an excellent example of the industry and community that can rise up around a meaningful interface. This is what we are seeing around photos and videos via APIs like Flickr, YouTube, Facebook, Instagram and Twitter, and numerous other segments like payments, advertising.
Through my research as part of the EFF brief, I really saw how API reuse was fundamental in the growth of two of the major movements on the Internet in the last decade: social & cloud. Both of these areas have transformed how we live and conduct business in 2014. API re-use is critical to this, and if we allow companies like Oracle to lock up the best API design patterns - we all lose.
InfoQ: You advocate the usage of Creative Commons licenses for the APIs registered in the API Commons. If we consider API definitions in formats like Swagger like source code, why don't you support open source licenses as well?
We advocate the usage of any licensing format you wish to bring to the table. We chose Creative Commons, because it was the best we saw available, to meet our immediate needs. Why re-invent the wheel? We welcome any API definition or licensing model you desire, publish your APIs, reference the license you desire, and you are in the commons.
InfoQ: As the API Commons registry only contains licensing information about APIs and a pointer to its external definition file, how can you ensure that this definition will still be around in the years to come?
I don't think we can ensure anything will be around in the coming years, but having these references out in the open, in a common place will be critical to the evolving conversation that will surround API licensing and definition formats coming and going.
There won't be any absolutes in the API space, things will move forward rapidly, and the best way to address is within the commons, and trying to establish a common language for describing APIs as well as licensing them in ways that are best for the entire API economy.
InfoQ: Do you think that a common API language unifying the existing initiatives (RAML, Blueprint, Swagger, WADL, etc.) is going to be necessary? Does API Commons intend to initiate or support such effort?
I think translation and interoperability between the formats will be necessary to evolve the space, and encourage collaboration between API design platforms. I don't think "unifying" will be required. I think the differences will be each of their strengths, and won't always perfectly translate. API Commons won't be advocating for any specific language or format, but will advocate for groups working together.
InfoQ: How the vision of API Commons is different from the vision of previous efforts at software reuse such as online component libraries, UDDI registry circa 2000, etc. and what do we need to avoid from those previous failed efforts to ensure success?
While a directory of APIs is a by-product of the API Commons, it is not the goal of the commons. The API Commons is focused on public sharing of API definitions, encouraging collaboration and re-use of the best API design patterns, from across the space, while also forcing the critical topic of API copyright front and center—something that is critical to a healthy API economy.
API Commons is an outward, public, open approach to sharing the best patterns in the API space; earlier efforts were driven from purely technical or business objectives, where the API Commons reflects the positive elements of what we have learned on the open Internet, from open source software, and developing distributed, social applications that scale via cloud computing.
InfoQ: Since the launch, what additional features have you added to the API Commons platform and what are you planning to build next?
The most recent addition to API Commons was an API, allowing the submission and querying of API definitions in the commons. The next thing we plan on building is adding more API endpoints and integration tools so that publishing to the commons is default in any API design and deployment platform.
InfoQ: Thanks very much Kin for all your answers. I have a final question for you. How can API enthusiasts help you out and contribute, beyond publishing their APIs to the commons of course?
Craft stories around APIs, their design, deployment and impact they make—stories that matter to end-users, not developers. If you craft stories that resonate with users, and describe the value generated by APIs, others will re-tell the story. This can have the biggest impact for APIs across the public and private sector—so please, tell stories.