I still remember the good ol’ times where I almost convince an entire company to allow their > 500 employees to contribute to an opensource or a free software project at least 1 hour a month.
The journey was hard. I prepared a strategy and facilitated the discussion, and spend numerous hours taking to smart legal people to create a framework for that.
Also kind of convinced everyone that this is a good thing and created a list of projects to contribute to, separated in categories – for developers, for testers, for marketing and sales, for the other experts we had.
I
also finally convinced the company that that one hour will be donated
(because the company owns all you do during working hours).
Well, nothing happens with that Initiative after I left. I still see some ideas mentioned on their blog, but it seems it’s not supported anymore.
Maybe you lost my train of thoughts and to be honest I am in the same situation as well. Haha!
I just wanted to brag about that I finished my #hacktober challenge this year and their goals it seems to be the same as mine while trying to convince the company – teach everyone why sharing is caring and why contributing to the Open knowledge is the best you can do.
You don’t have to be a developer or a byte guru to do so; Everyone can do that, and it makes you proud, and it makes you feel happy.
First, let me invite you to the magical world of Stephen King’s novel The Wind Through the Keyhole and in the precise moment when the Ka-tet is hiding from the Starkblast.
At this very moment, Roland tells a story that inspired me to write an article about APIs. Let me remind you of the story very shortly.
A very short summary of the story. Keep attention
The story starts off about a boy named Tim Ross who suffers a tragedy when his father Big Ross is killed by a dragon. A few months later his mother, Nell, marries his father’s best friend, Big Kells, so they can pay the Covenant Man their yearly taxes.
Things start going wrong when Big Kells starts to beat Tim’s mom. It starts to get worse until tax time comes and the Covenant Man gives Tim a magical key that can open any lock. Tim opens Big Kells chest and finds his father’s ax and his father’s lucky coin.
Enraged, Tim goes to talk to the Covenant Man who is in the endless forest. Once he gets there the Covenant Man shows him the body of his father and a vision of Big Kells beating his mother until she is blind.
Afterward, Tim runs home and checks on his mother who is aided by his previous teacher Widow Smack. He vows for revenge. Big Kells has disappeared and Tim wants to help his mother so he seeks out the Covenant Man again but only finds his wand. But he is able to see a man giving him an item that will help his mother’s vision. It turns out it is Maerlyn, a powerful wizard.
Tim tells Widow Smack of his plans and she warns him not to go but she gives him a rifle because she knows she cannot convince him otherwise. Tim then sets out into the endless forest to find Maerlyn.
Along the way, Tim is tricked by a sighe who leads him onto an Fagonard Swamp island where he is almost killed by a dragon, alligators, and is being jeered on by Mudmen across the lake. He finally kills an alligator with his rifle and the Mudmen then believe he is a gunslinger.
They help him off the island and give him a device from the old people…
Let’s talk about the device
I will stop telling you the story about Tim and will start the story about the future of APIs. Before I begin, I want to encourage you to buy the book and read the rest of the story and maybe the whole Dark Tower series. The movie sucks, by the way.
Alright.
Let’s focus on the device. What happens with Tim next – he discovers that the device can do some stuff, like orientation in off-road terrain, connection to (GPS) satellite, turning the light on and off and answering questions.
The description might sound like a modern Nokia for you (of course I am talking about the lights), but it does something more and those functionalities are not supported yet by any modern device.
Why don’t we look at the use-cases:
UC1: Can I eat that?
One of the questions the little Tim asked is ‘can I eat that mushroom’ and the device replied, hell no, this is deadly.
So the intent here is that the boy is hungry and he asks the device for information. How does the device know that this is edible or no in the context of the current technological world:
Point the camera to the plant
Send the image to be recognized
Check if edible = true
Return the result together with some information
Store the info for future use.
UC2: Is this person bad?
I am not sure if that question was asked directly in the novel, but when we are talking about Maerlyn in the Dark Tower, we must ask the question.
The intent here is to understand if this person has a good reputation or not in this case. How do we do that:
Describe the person if there is no picture
Analyze the content
Form a hypothesis and return the score in good/bad scale
If I am not mistaken the returned result was something like 50/50, maybe useless, maybe not, because it brings some hope to Tim.
There are more use-cases in the book and I am sure there are more use-cases in your head on what a device like that could do.
APIs
So, what is the connection with the API? If you look at the use-cases above, you might ask yourself – are there any mobile applications that are currently covering these use-cases? Of course, there are. Are there any APIs that do that? Most probably they exist. Then what is the problem?
Problem 1: The applications cover just one use-case, they are locked and they do not expose the information to the rest of the eco-system. What if I have a use-case similar to use-case one, but not for mushrooms, but for a plant or an animal? Shall I eat that animal or I shall run from it?
Problem 2: the APIs for many use-cases exist but it is not very easy to find them or to search for them from a device or a machine.
Let’s try and see if we could transform one of the use-cases in basic API calls to some services:
Open and search google for image recognition API
Plenty of options, some of them not really useful
Select one to explore or go to Programmableweb or other discovery service and repeat 1
I have found one, let’s use Imagga
Learn how to use it and get the results.
The search for a mushroom recognition API, repeat 5
Combine the result and return it to the consumer
Even if they have an API blueprint this could take days to implement.
Then what?
What if we have a way the devices to find and request the APIs they need. Imagine a request that does that:
Searches the API discovery service to find APIs for image recognition ordered by maturity and latency (we need good results, right)
Then returns the API blueprint as a result of the most useful for us API
Then searches for another API that could take the result of API 1, discovered in point 2 and to return the result to the consumer
…and all this for milliseconds.
Then repeat this for another use-case
This problem has been known for decades. Great APIs exists, great companies are investing a lot in building and exposing them, but they make the mistake of exposing them only to humans and to optimize the experience only to developers.
We are entering very exciting times and I believe the future of the APIs is to be easily discoverable by devices and used without the need of someone to program the interaction.
I do know there are a couple of teams working on that and I really want them to succeed, but this could be a very hard thing to do without changing the mindset of the business and of the developers.
There are tens of thousands of API’s available. More to come. Most of the companies though, have troubles engaging developers to use them. So I have decided to share a few thoughts and ideas on how you can do that, based on my experience.
Design your API well
Nobody likes powerful, but not developer-friendly APIs. Follow the “standards” in the area, but innovate a bit to make us (developers) happy and eager to learn more. I will not spend more time here, because I guess you are already building your API if you need the information below. If you are looking for more info on that subject, click here to read an excellent article.
Document your API
If you want other people to use it – document it well. Add examples for the most popular programming languages. Copy/ Paste/ Run is the first step to a great journey.
Do not forget the not-so-trending programming languages at the moment. Target people who explore them – they are the right group to start with.
Eat your own dog-food
Ask your internal developers to use the API. Get the feedback from them and make it better. I am not talking about the developers who wrote the API, they must use it of course. Try to engage other teams within the company (if you have any) to use the API.
Organize an internal Friday APIJam. Sit together in a room for a few hours and do something useful using the technologies you work with – don’t push them to learn new language or technique – just use the API focusing on the value.
Come up with nice awards for the most active participants, get some sweets and drinks (even beer) as well. Then ask the participants to present their work at the end and listen to their feedback.
Hack your API
Organize hackatons with external groups or jump into such organized by someone else – ask developers to hack the API and to create a small app that will serve theirs needs – then promote the effort and make those developers rockstars by using your PR channels.
The goal is not to test your API (as you do during the internal APIJam event), but to show the value that your API brings to the world. The Call for Action should be something like “use our API to build your own App”.
Create more initiatives like that. Repeat();
Connect
Get in touch with the local developer groups and go the their next meeting with some pizza and beer. Show them your data, ask for their feedback, show them your API, don’t be afraid to ask for help.
Then create a fair process to work with communities around you – what you want from them and what’s in for them.
Discuss
Push the discussion around your API and manage it. Respond to comments immediately, ask for feedback and show how it is implemented. Post your API to reddit, Dzone and other similar sites and get real, honest feedback (together with some trolls, that’s inevitable)
Equilibrium
Treat your community members equally. Sometimes a new member can have a kick-butt idea and if you ignore him/her this can have negative impact overall. Focus on the value!
Partner up
Find partners to help you to get traction. Why don’t you contact your local startup accelerators and do something together to include your awesome API as an requirement for the next call? Does it work? Oh yeah!
Explore
Constantly explore new ways and hacks on how to engage the community, but remember – this must be a fair deal – every part should be happy and equally satisfied. This is your way towards an engaged community.
