According to Fog Creek CEO, Anil Dash, the way we typically evangelise APIs is broken. Here’s his description of how he believes most API companies do it today:
1 Your company builds an awesome API for its new platform
2 Management wants to show the new API off to the world
3 Developer evangelists fly out to conferences and events to tell people about your new API
4 Some people awkwardly stand around sponsor tables as various t-shirts and stickers are distributed
6 A couple of developers go to GitHub and download your SDK
7 Some of the developers get frustrated just setting up their dev environment
8 A few devs actually get your Hello, World app running and talking to your new API
9 Many of those devs get stuck on a new error message that isn’t on Stack Overflow yet
10 Maybe a handful of folks succeed with your API
11 Repeat steps 3–10!
This seems a little unfair. Sure, we’ve all seen examples of devrel done wrong but Anil’s description doesn’t reflect those developer relations professionals who use their creativity, hours of unpaid overtime and empathy to build successful developer communities.
Nonetheless, Anil is right: we can do more to make it easier to get people hands-on with our APIs.
Fog Creek’s answer to that is Glitch and, specifically, Glitch for your API. Glitch is a super-sandbox for building and deploying Node code. It offers a real-time collaborative code editor, hosting of your resultant app and remixing.
And remixing is where it gets interesting for people promoting an API. You can set up a sample project on Glitch that acts as a demo of your API. Whereas forking on GitHub leaves you with a new repo, remixing on Glitch puts you right into a combined editor and PaaS where you can play with the API and sample app with minimal effort. If you don’t have a demo app in Node already, they’re even offering to build one for you as part of their premium offering.
Glitch for your API looks like a fun way to get people hands-on with your product and the idea of remixing is true to the ideals of building on the work of others. Let us know if you use it for your project.
Different communities have different expectations and needs: what fits the internal may not suit the external.
Understanding your user’s emotional journey can make or break a product.