Postman: The role of open source in APIs - Part 2 of 2

This is part two of a two-part contributed piece for Computer Weekly Open Source Insider with part one linked here.

This analysis of the role of open source in APIs is written by Postman CEO Abhinav Asthana — with offices in Bangalore, Austin and San Francisco, Postman aims to simplify API development with its industry-standard API Development Environment. 

Postman has more than four million users — growing from a simple REST client in 2012, Postman now helps developers do everything from design, testing, mocking to monitoring and publishing in a real-time collaborative environment. 

Asthana writes as follows…

A critical thing that APIs can learn from open source is the importance of reimplementation. The ability to take an open source artifact or codebase and put it to use as part of your own open source or commercial offering without the typical hassles, hurdles, and licensing issues is a game-changer.

I think the Unix operating system is a good example of why this approach to software development is so valuable. Linux reimplemented Unix as an open source project, reimagining what was possible and paying it forward by introducing another powerful platform to help developers deliver software. Linux is now one of the world’s leading operating systems, proving that open source software also makes good business sense.

Closed source software typically likes to lock down ideas, but open source software is known for opening up ideas. API providers should adopt that same core philosophy with the open source software (OSS) movement. If there is a great existing API that people can reimplement in interesting ways, they should have the freedom to do that without legal or market repercussions. We see this reality playing out with the Oracle v. Google API copyright case that has been winding its way through the courts over the last eight years; Oracle has been shutting down the ways in which Google can reimplement Java APIs, while simultaneously throwing a wet blanket on innovation across the API industry. In the end, we are all building on what came before us, and our collective future depends on the constant reimagining of existing ideas.

Almost all technology companies have (at least publicly) sided with the concept that we should be able to reimplement each other’s APIs. The idea is that we try to compete on the merits of the software we have created rather than closing down access. This positions open source and open APIs as a foundational mode of doing business online, as we collectively work to identify (and minimise) practices that restrict users into a single platform or company.

We want to avoid the practice of API vendors trying to enforce lockdowns using APIs after their API is well-integrated with other pieces of software. For example, API documentation isn’t always open and there can be a lot of hidden APIs, as well as custom APIs that are delivered for specific partners but are not available to the wider community. These are all anti-patterns that exist in the API space that can be difficult to see. So as a community, we should be calling them out when possible. We should strengthen our collective belief in open source and push back on practices that lock users in.

One way to protect against vendor lock-in is to build a thin abstraction layer that lets you switch over to a different API if needed. It’s kind of like installing a connecting interface where many wires can be plugged in there as long as it conforms to the things that you want. You maintain the connecting layer while abstracting away the vendor service. You are free to potentially swap it out with another third party or internally developed service when needed.

Walled gardens limit innovation

Asthana: API are gateways, let’s stay open.

Hopefully, all of this sounds like an API future you want to support. Everyone working together for the greater good sounds like the sensible way to approach APIs, but in reality that will only go so far in addressing the vendor lock-in challenge.

Remember back in the early days of Facebook when we used to talk about the concept of a walled garden? What vendors are realising now is that there is financial profit in keeping people in a new kind of walled garden, which is still often defined by its API perimeter. 

That’s why Oracle sued Google, as noted above.

In the past, you might have been able to deal with one or two companies creating walled gardens. But now there are thousands of SaaS software and other cloud-based providers that have APIs. Today there’s a risk that instead of creating one great big walled garden, we’re creating thousands of smaller gardens. That, again, has the potential to limit innovation because it makes it difficult for organisations to find and integrate with the digital resources they need to operate their businesses.

There are many ways in which business rules are implemented and executed using APIs. Those business rules will either embrace openness or not. Ultimately, organisations at different levels will choose to play that game a little bit differently. While each organisation will be unique, openness is something API providers will have to think about in various ways as they evolve and grow their API-driven platforms.