Open Source driven API economy

I did some research (my doctoral research) on nascent 3D printing ecosystem 2010–2016. In 3d Printing I identified 5 layers. At the bottom is Peer Production community (hacklabs, open source and open design driven 3D printing development), on top of that is open design driven 3D printing community. Next layer is 3D printer manufacturers who develop 3D printers and utilize open source components (hw and sw). Design markets emerged after people had access to easy to use 3D printers and community started to share digital models for 3D printable objects. Last layer is device and software markets. In it manufacturers have products for three markets: developers (DIY), early adopters (self constructed from ready-made pieces) and layman markets (plug and play, easy to use). In this market segment there’s also 3D modelling tools (software and online) as well as sales channels such as Amazon.

More details can be read from the thesis (PDF available).

First feeble attempt — open source driven API ecosystem map

Inspired by the initial model for open source driven 3D printing ecosystem I started to draft (without hard evidence yet) a preliminary model for emerging open source driven API economy.

While drafting the drawing above some questions and thoughts arised. Below is a few of them opened.

Business model tools will arise

Lean startups have lean startup canvas. Manfred Bortenschlager introduced API Model Canvas a few years back and there was even a landing page for the online tool. Then the plug was pulled off. Tool and idea was right, but it lacked context (cycle where it fits as one part). In addition the model needs a little fine-tuning. Now at least a few companies are moving forward with productisement of “API Model Canvas”. This tool will be the initial step in API development cycle. With this tool business reasons and non functional features can be captured, planned and iterated. After that we can move to for example API design and MVP implementation.

End of Spec wars will change API management

The so called spec wars in which rival API specification formats (Swagger, RAML and API Blueprint) ended in April 2017 when company pushing RAML joined OpenAPI initiative. Before that API economy industry players were not sure which way will be de facto standard to define and document REST APIs. Now that the war is over and OpenAPI (was known as Swagger) dominates and is de facto standard, we will wittnes changes in API management solutions as well.

Ease of use and automation

Most API management systems will limit support to OpenAPI format only since it will cover major share of the markets needs. Niché markets will be served by some naturally, but maintaining support for several formats is a burden and requires resources.

In addition the amount of automation in adding APIs to API management will become default function. API management vendors will (and some have done so already) support “one stop shop” for OpenAPI spec driven APIs. API owners will be able to add APIs to catalogs and management with one click by providing spec file. This will ease the API owners’ life and make the customer experience more pleasant. Now API management vendors need to build one pipeline just for one format.

Toolchain development will become faster

At the same time speed of toolchain development build around OpenAPI spec will increase. That includes at least specification viewers (documentation for consumers), code generators and spesification authoring tools.

Better tools to spec authoring and sharing

The authoring tools are going to change. So far OpenAPI spec has been written mostly in YAML or JSON format. Proper tools to focus on content instead of technical format has been lacking. Swaggerhub is technically oriented. API spec should a tool to communicate plans regarding API among different people. Not all of the people working around API spec are technical.

Open source entering API economy — fragmented and excluding solutions

The amount of open source gateways and API management solutions has increased a lot during the last 6 months or so (just a gut feeling, no facts). A lot of tools in API development have been licensed with open source license some sort of. The fragmentation of tools and isolated solutions exemplify the nascent nature of API economy. Widely accepted and adopted fluent toolchains are still not there yet. Yes, we have API frameworks to build APIs, but connecting them automatically (DevOps style) for example to API management is not there yet (with exceptions).

What we are lacking is the glue between tools and systems without tight old skool integrations.

What we are lacking is the glue between tools and systems without tight old skool integrations. The other visible method to get fluent toolchains is to accept what the vendor has decided to integrate. The model does not give any space for replacing some tools with another (unless you pay extra).

Finnish API economy scene

Since I live in Finland and build business around API economy in APInf Oy, I discuss with Finnish and Scandinavian clients a lot. Based on those discussions for the past 2 years I have found some discoveries (with speculations) in the Nordic markets.

Focus on data

In Finland the push for Open data has been heavy for past 5 years or so. The push has come from public sector mostly, but some companies (still niché) have entered the scene as well. Open data started serving more or less static data dumps through sharing platforms such as CKAN. There were high hopes on building new vibrant ecosystem of new businesses around open data. Millions of euros has been spend on that (6Aika). The results are possibly not as good as “the markets” would have expected.

Role of APIs still seen in limited scope

After a few years back discussions about APIs started to emerge in Finland. However, possibly because of the focus and emphasis on data, API development (lead by public sector) has gone towards data APIs. API is seen just as a pipe to data and that’s it. The more vibrant API market of functional APIs has been neglected. Data is always controlled by someone who manages the backend (until we have MyData during 2018). On the functional API side such “data vendor locks” do not exist. In other words API as a product is new to Finnish market players. The same phenomenon is seen in integrations. APIs are still seen a lot as a replacements for legacy integrations. APIs as products has not really yet kicked in (at least in Finland).

Some research questions

Some interesting research questions arised to my mind:

• What happens now to “looser” specification formats and tool markets build around them?
• What are the effects of end of spec wars for toolchain development?
• How to enable glue between components from different vendors? De facto standards?
• What are the reasons for Finnish market players neglecting functional API markets?