In The Cathedral and the Bazaar, Eric Raymond recounts the early years of Linux. Specifically questioning how the “part-time hacking of several thousands of developers scattered all over the planet” could create perhaps the most complex, functioning application in history. How could a “babbling bazaar of differing agendas and approaches” coalesce into a coherent and stable system without some form of centralized planning?
The fact that this bazaar style seemed to work, and work well, came as a distinct shock. As I learned my way around, I worked hard not just at individual projects, but also at trying to understand why the Linux world not only didn’t fly apart in confusion but seemed to go from strength to strength at a speed barely imaginable to cathedral-builders.
Eric Raymond — The Cathedral and the Bazaar
Often when I’ve been working on API related projects, developers and managers tend to take a viewpoint opposite of Eric. That is, instead of focusing development on a marketplace of APIs in the bazaar-style, they adopt a central-planner mentality with a lot of up-front API design. The thought process being that to develop coherent and quality APIs requires a heavy amount of forward planning and API design to achieve a quality experience.
In this article, I argue that a healthy internal and external API ecosystem can be created by enacting some small governance measures to create a bazaar-style marketplace, without resorting to top-down cathedral-style planning or draconian governance boards.
Making a Market
A bazaar or souk, is a permanently enclosed marketplace or street where goods and services are exchanged or sold.
A bazaar exists as an agreed upon location where sellers and buyers meet to exchange goods. If we want to create a healthy API ecosystem using a bazaar model, it is up to the API project manager to create the location where sellers and buyers meet and then set the conditions that allow the bazaar to thrive.
We can use prior research to help guide us in setting up the market: the Mercados project investigated 20 markets various sizes in cities large and small across five countries in South America and condensed the research down into ten common characteristics of successful markets:
- Full-Day Hours of Operation
- Accessible and Central Location
- Protection from the Elements
- Navigable Aisles
- Broad Selection of Goods
- Affordability
- Safety
- Prepared Food and Seating
- Multi-Level Vending
- Integration of Public Space and/or Pedestrian Streets
Julie Flynn — 10 Common Characteristics of Successful Markets
These rules can be distilled down into a few guidelines: create a common and secure location where producers can provide their goods and consumers can discover and use them. An API marketplace works in the same way as these other marketplaces, allowing providers to list APIs and developers to consume them. Like other types of marketplaces, a typical API marketplace has several components including a developer portal and an API provider portal.
The developer side of an API marketplace allows developers to find and connect to APIs. Ideally, developers can look through categories, collections, or do a search to find the API they are looking for. The categories and collections can be particularly helpful if developers are looking for specific functionality, but have not selected exactly which API to use. The marketplace also makes it easy to compare different APIs and consume documentation that helps developers make a decision about what API is best for their needs.
The producer side of an API marketplace allows API providers to publish APIs so developers can discover them, and monitor how those APIs are used so they can respond to customers. The producer portal also allows API developers to manage the entire lifecycle of their API, from design to release to retirement.
Providing an API developer portal that API providers publish to and that API consumers consume from meets the criteria for a successful marketplace according to the Mercado study. But, this study leaves out some implicit assumptions that may not be true for a digital market. The first being a common standard of exchange.
Creating a Common Currency
For a marketplace to thrive, producers and consumers must be able to exchange their goods. Using a common currency facilitates this exchange by minimizing the fluctuation risks of multiple currencies and eliminating the exchange costs for producers and consumers.
When the European Union was founded in 1957, the Member States concentrated on building a ‘common market’ for trade. However, over time it became clear that closer economic and monetary co-operation was needed for the internal market to develop and flourish further, and for the whole European economy to perform better, leading to the decision to use a single strong and stable currency for all European Union Member States: the euro.
The benefits of the euro are diverse and are felt on different scales, from individuals and businesses to whole economies. They include:
- More choice and stable prices for consumers and citizens
- Greater security and more opportunities for businesses and markets
- Improved economic stability and growth
- More integrated financial markets
- A stronger presence for the EU in the global economy
- A tangible sign of a European identity
Many of these benefits are interconnected.
In an internal API marketplace, we can similarly reduce fluctuation risks and the minimize the cost of exchange by adopting a common currency. For APIs, this means adopting a common data interchange format and set of standards to make it as easy as possible to participate in the API exchange. Any standard interchange format can be adopted for this purpose, but the most ubiquitous standard for APIs today is RESTful HTTP encoded with JSON. To develop a successful API marketplace, adopt a common interchange format and set of API design standards to facilitate the free exchange of APIs between producers and consumers.
API standards can be governed centrally by publishing them in a centralized API developer portal. But to avoid stifling creativity, a bazaar-style marketplace may want to consider a bottom-up governance strategy instead of a top-down approach. While the main objective of adopting common API standards is to apply structure to the marketplace of APIs, a bottom-up approach to fulfilling these standards meets this requirement by enabling each business function or team to independently manage its respective APIs, including updates or design enhancements to these published APIs.
Providing the Right Incentives
If you have a platform or two-sided marketplace, like the App store, Uber or Etsy, you’re familiar with this scenario. One side of your marketplace is the Inventory side, the people providing the apps, rides or crafts. The other side is the Buyer side, the people buying the apps, rides or crafts.
Sometimes it’s simple, both Inventory and Buyer sides want monetary exchange. But sometimes it’s not, the Buyer side is willing to pay, but the Inventory side isn’t motivated by money. The latter is a common challenge among developer communities.
Carrots For Web Marketplaces And Platforms: How To Design Non-Monetary Incentives
Beyond creating a portal and setting the API standards, enterprises also need to incorporate incentives in the marketplace that promote development of high-quality APIs and drive API adoption. Within organizations, the incentives typically do not have a monetary value. For example, companies may maintain a leaderboard that highlights top API publishers and application developers. Enterprises can also track which APIs have the most subscribers and display them on dashboards on the developer portal. Workshops and hackathons that allow developers to learn and apply skills from the API marketplace can also serve as incentives.
The ultimate goal is to motivate the behavior you want using the carrots available to you, which may not be monetary. How you dole out the carrots is at the heart of your incentive design. There’s no prescription for this, every platform will find its own way through experimentation. But there are likely some good starting points: are you able to provide simple rewards for highly-leveraged APIs, can you track consumer satisfaction with APIs and surface highly reviewed APIs, can you create pre-defined templates that drive API use and re-use, can you reward the most innovative use of APIs to accomplish a business task?
The Market, the Currency, and the Incentives
In this article I outlined what I believe are three necessary conditions for creating an effective API marketplace in the bazaar-style: the market itself, a common currency, and the right incentives. Together, it is the responsibility of the API program manager to create these three conditions to foster a healthy API ecosystem and marketplace. We can meet these conditions with a few implementation options. It is up to you to decide which ones meet the needs of your organization.
- The Market
- An API Developer Portal
- Products exist to meet this need that are easily deployed. Consider something like SwaggerHub, Stoplight.io, Postman, or RapidAPI.
- The Currency
- Standardized Interchange Formats
- The ubiquitous standard for APIs is RESTful HTTP encoded with JSON. You may also consider other API formats like gRPC or GraphQL depending on the nature of you API program.
- In addition to a specification, you may also need a standard for URL design or payload structure. Consider something like JSON:API or HAL.
- Incentives
- Incentives reward the right behaviour in the market. These are typically organization specific and they may change over time. Experiment with what works best for you.
Given these three conditions, you can create an effective API marketplace without requiring unnecessary upfront planning and top-down control in favour of a thriving marketplace economy of APIs. This changes the role of the API product manager from one of top-down API design and development to one of discovery, curation, and promotion, while letting development teams to operate independently to create and deploy APIs.