Today, software development is built around APIs. Instead of embedding a vendor's product into their application, developers can call an API to consume services from a vendor. The developers don't need to know what's responding to their calls on the backend; they simply need to know what the vendor's API expects from their code and what they can expect to receive back from the API. It is, in many senses, wonderfully non-intimate.
This is an inversion of the traditional open core model behind many commercial open source strategies for enterprise application layer products. In open core, the product's core is open source, and in the enterprise edition, vendors provide and support proprietary enhancements. Using the API approach, the product's core is often not visible in the cloud, and the only way in and out of the product is through the API.
Because of APIs, we are seeing the differentiation, enhancement, and value in enterprise editions migrating to the perimeter via tools, widgets, and components. These can be closed source and/or open source, but we should see more open source in the perimeter, because many vendors can make money by supporting their core and charging for API calls or transactions. The two best examples of this are Twilio and Stripe.
How this is like a home remodeling project
A simple way to understand this scenario is to compare it to a home renovation project. If you want to add a new bathroom to an existing house, you generally need to hire a plumber and a general contractor. The plumber brings in the pipes and "roughs them in." The contractor then builds the bathroom around those basic services.
Most people generally don't care or even want to know where those pipes come from or how they connect to the general plumbing system. We simply know what our input value is (yup, you guessed it) and what our output value looks like (clean water). We know that these need to work and to work well. We have a generally accepted service level agreement (SLA), which is a performance expectation around how that plumbing should work. If we flush the toilet, everything should disappear into our plumbing (the API). And when we open the faucet, potable water needs to flow with a certain pressure (another API performance SLA).
The point here is that the only information we need is how the API (the plumbing) is performing. This performance expectation is the SLA. If you are designing a bathroom, you will spend time thinking about the style of the sink you want to buy, the type of tile you want to install, and the overall layout of the new bathroom. This "look and feel" is what adds value to our home. We still have to pay for the plumber, but it would be crazy to reinvent the plumbing in your entire house every time you do a bathroom or kitchen renovation project. The innovation here has moved from the core to the perimeter.
This is exactly what is happening with the rise of the API. Developers are realizing that sourcing a high-performance API from a vendor allows them to focus on their value-added services.
Classic open core applications
Let's look at some classic examples of open source enterprise software that uses the open core model.
- Sugar: Sugar CRM makes its source code available to customers and partners. The enterprise edition of Sugar adds specific enterprise-level functionality, such as enhanced reporting, better workflow, and other enterprise-specific features and add-ons.
- JasperSoft: JasperSoft offers open source business intelligence reporting. There were more than 30,000 developers registered in its community as far back as 2007. Jasper provides SDKs and RESTful APIs to interact with its product.
- Odoo: Odoo's open source enterprise resource planning (ERP) application has become a very popular alternative to proprietary software. Around its open core, Odoo and its partner channel have added hundreds of different paid modules that extend the open source core. The core framework contains about 30 modules, and there are thousands of modules created by the community. Some of these are free, but many others are paid and closed source.
- ProcessMaker: ProcessMaker offers open source business process management (BPM) and workflow software. Developers can enhance the open source edition using JavaScript and PHP. ProcessMaker offers a series of enterprise plugins, including Advanced Active Directory integration, dashboards, and enhanced developer tools.
Many software companies that adopted the open core model did so after an initial open source project gained significant traction (i.e., millions of downloads), so they formed a company to support the open source code. Gradually, those companies developed extensions and subscriptions based on the open source. As cloud and software-as-a-service models became more prominent in the early and mid-2000s, these companies often developed cloud versions based on the open source core to further differentiate their offering from the open source version.
Perhaps the two biggest drivers to the rapid adoption of many open source products were the open source license and the frictionless distribution model via download sites like SourceForge.
What's changed
This commercial open source model became widespread in the late 1990s and early 2000s. However, a change is sweeping the industry: the rise of APIs. The API has become increasingly important for several reasons:
- The need to build more scalable software
- The need to build more connected software
- The need to accelerate the pace of innovation
- The need to deal with growing complexity
Software is more complicated, must connect to more types of applications, and has to scale to handle greater demand (in orders of magnitude). Combine these three factors, and you quickly realize why the API is so important. Developers can no longer develop a monolithic code base and allow other applications to connect to it however they want and expect to maintain the software and ensure that it performs well at scale. The API is the clear and declared way that two or more services interact with one another. By knowing how another software expects to work with my software, I can maintain its quality and judge it against this expectation, even as my software grows and evolves.
API-based business models
Some companies have already adapted to an API-based business model. Here are a handful:
- Twilio: Twilio offers communications-related APIs to support messaging, voice, and video. Twilio's marketplace offers third-party add-ons that integrate with Twilio through its API. Add-on builders leverage the content Twilio provides and enhance it with information from their own sources; their product is then published as an API in the marketplace.
- Stripe: Stripe's payment-processing platform, which provides a RESTful API for submitting payments, handles billions of dollars in payments each year. Third-party extensions offer additional features by making API requests for the user's Stripe account. There are also third-party libraries to support development and plugins that enable Stripe to work with other products.
- Factual: Factual provides location-based data for mobile advertising and other mobile applications. It offers a set of APIs that developers can use to build extensions that integrate with Factual's product offerings. Some of Factual's location data is available to partners through a download license.
- ProcessMaker I/O: ProcessMaker I/O offers a workflow-as-a-cloud microservice. Enterprise ISVs can use the ProcessMaker API to add enterprise workflow functions to their product stack. The workflow API can connect to any backend and can scale to millions of transactions per second. Developers can use SDKs in Java, Python, JavaScript, PHP, or other languages to connect to the API.
- Form I/O: Form.io delivers a powerful API for managing web forms. These web forms can populate data sources in any type of serverless architecture.
Advantages of the API model
The API model has real benefits for developers. Open source and open core mean there are constant changes, which produce (regardless of testing) constant risks from unintended side effects. By ignoring the product's inner core in favor of the API model, developers can focus on using exposed functionality that offers a reliable behavioral contract. This enables faster innovation (and more of it!) at the perimeter of an application, instead of slowly tinkering at the core, where you would need a much greater depth of knowledge about a project to contribute to an innovation.
Because APIs can offer the same functionality as different backend systems, the API approach offers access to vendor-supported applications while decreasing the risk of vendor lock-in over the long term. Of course, in the short term, hooking into a vendor's API means you'll be dependent on that API. If it goes down, your application has to figure out how to deal with it. But API providers that consistently don't meet their SLAs will be replaced by more reliable providers. It is relatively easy for competitors to replicate an API, which provides security to developers that an API can be replaced if necessary.
Developers can test the functionality of the APIs independent of the backend and focus on combining these specialized microservices into the larger applications they need to create, supporting their business users. They can focus on their core competency—specialized business knowledge—rather than infrastructure to hold the application together. More focus on business knowledge means the end product is more targeted towards business needs.
Small providers have a large role to play
Considering that APIs are the new plumbing of applications (and hence the new plumbing of the internet), it is hard to think that small providers can make a difference. Yet they absolutely can. API services are proliferating at an amazing rate; they are the true new driver of long-tail innovation. The reason is that APIs can expose a true microservice. Developers then mash these microservices up into meaningful applications. I expect that after a few years of massive API proliferation, we'll probably start to see API consolidation. But we won't see that story play itself out for a little while; until then, smaller players have a large role in the API economy.
Comments are closed.