Sometimes inspiration is not a straight-line thing. Today’s post is a case in point. I saw in a TAG Slack thread concerning “Web 3.0” (whatever that is) that folks were most interested in “expansion of open APIs, open data, etc.” Next, I saw an article about the hackers and IT folks that are combining forces to combat Russia’s invasion of Ukraine. These topics have nothing in common. So, I decided to mash them up.

(And a big BTW: Microsoft has announced that it is offering Teams Phone System calls to Ukraine for free.)

Some API Basics

Let me start with this. API is an acronym for Application Programming Interface. Think of an API as a box connected to an application. The box allows certain inputs to be entered and specifies what corresponding outputs will be delivered. For instance, consider a database application. The application has a workflow to create a database object, such as a customer account. The application was likely built on the idea that a person would interact with the application to create a customer account and provide the account details.

Enter the API. Imagine now that some other application wants to leverage our application to create a customer account. The database application API specifies that if an application supplies a CreateAccount command with certain parameters, the database application will create the account. One application is talking with another.

What makes this not an open API? Two things.

• The API is controlled by the database application developer. The developer decides which functions they want to support and which they want to keep hidden from others. This is so often the case that we do not bother to call them “closed APIs”. We just call them “APIs” because aren’t they all closed?
• The functions/capabilities that are included in the API are also controlled by the developer. Some of this limitation on what is “in scope” is defined by what the application does. A database application has no ability to determine if a message is spam. However, the developer chooses what capabilities or extensions they will allow. For instance, a database developer could decide whether to pass information to a ridesharing app.

Are Open APIs the Wild, Wild West?

Imagine that we want to create an open API. We were inspired by TAG’s efforts to Fix the Form and we want to create an open API that will make it easier for organizations to automate the grant seeking process.

What makes this open API like the Wild, Wild West of yore? You know: that time of chaos, when might made right and people could march around town with unpermitted weapons concealed from sight? (Can I get a date-check on that last sentence?) Here are three words to help explain things.

• Platform.
• Panacea.
• Control.

A Platform, a Product and an API Walk into a Bar

Sorry, I am still working on the joke.

Microsoft Excel is a great product. It has all kinds of financial, database and list-making functions. (And we continue to use a $ to specify a fixed cell reference. Tradition!) When Microsoft provided support for Visual BASIC, Excel became a platform. Application developers were able to create all kinds of apps using Excel as the underlying platform. No lie, I once bought an app that used Excel to run Monte Carlo simulations on market forecasts.

Platforms require care and feeding. Someone must specify the API and develop the supporting code that allows functions to be called and results to be output. A group must test apps that use the API, to help debug the apps and ensure a certain level of application quality. Another group must document the API and how to use it. Yet another group goes on barnstorming trips to encourage app developers to use the platform.

A Panacea is What You Get Before You Get Anything

You can read messages from folks about how Web 3.0 is going to solve all the problems of Web 2.0 What do these breathless statements have to do with an open API? They leave the problem space unbounded. Any problem can be solved because every problem is eligible to be solved. An open API means that people can ask for or create the use cases that any given problem needs to resolve.

An open API cannot truly be “open” if it intends to accomplish anything. There must be boundaries. Otherwise, many promising solutions are demonstrated but none make it to market. Getting something done requires saying “no” to most suggestions.

Control. Governance. Whatever You Call It, We Need It

At long last, I return to those 300,000 hackers for Ukraine. I can feel good about the spirit of volunteerism and the satisfaction of feeling like you are helping. I am more concerned about the tactics being used, for ethical and practical reasons. What happens if one of these hackers creates a piece of malware that ends up hurting more than its intended targets?

Imagine someone developing an open API to support this work. Who maintains it? Who controls its content? As I have written about previously with Open Source software, someone must be in charge. “Open” cannot mean “ungoverned”.

Exciting Times Ahead

These are exciting times for open APIs and open data. We are apparently headed for a third wave of Internet innovation. (I was not keeping score here, so this is news to me.) We will undoubtedly be amazed at the problems that we can solve with open APIs. Still, we do want to remember that understanding the problem space is crucial. And we should also remember that open APIs, while worthwhile, are not free.