Porkchop sandwiches! It's a Shelby.tv API!
As a bunch of you may know, we’ve been up to some exciting stuff at Shelby.tv this summer and have announced hackday.tv, a hefty video hackathon in New York. We’ve only got a week or so to go, and we’re really excited about the press and ideas that people have been generating for the event.
“A hackathon for video hosted by Shelby… but Shelby doesn’t have an API, does it?” you ask, inquisitively.
Wrong, my friends. Turns out our resident brogramming cyborg has been building a pretty awesome API that will let you harness the power of what we’ve built with Shelby for your own nefarious purposes (world domination not included).
“Porkchop sandwiches!” you exclaim excitedly.
We’re building an API that allows you to easily create incredible social video experiences. Our API tells you what videos are being shared in a user’s social graph (twitter, facebook, tumblr, email etc..). It tells you what people are saying about these videos. It not only tells you what videos your users like, it tells you what they’re going to like. This data is accompanied by a universal video player that allows you to stream video from any source (YouTube, Vimeo, DailyMotion, CollegeHumor, etc) in one clean interface. Better yet, it allows your users to share the videos they’re loving with their friends, on any device, on any social network.
We’ll be rolling out API documentation this week that you can add to your bathroom reading list, but in the meantime, here’s a few ideas we’ve discussed while drinking, so attempt them at your own risk:
Party Shelby - Do your late nights on weekends usually end at someone’s apartment with “no no no, watch THIS web video” conversations? Well, build an app that uses any location based service (we dig foursquare) to compile a Shelby channel out of individual users all checked-in to a specific location.
Shelby Subtitles - Videos with subtitles are always more fun. Just ask Hitler. Throw some subtitles on a video with all of your friends and see who can come up with the most ridiculous ones.
Shelby Science Theater ∞ - MST3K fan? Use Soundcloud to add your own commentary over a video and throw it into your Shelby channel.
Check out our new API documentation here.
Charging for APIs...SRSLY?
This may be reading too much into random and unrelated things, but the idea of charging people for access to web APIs seems to be coming up more and more around the web. I saw it the other day on a Forbes article about Facebook (saying that one possible revenue stream for FB is to charge for Facebook Connect) and then in a random developer’s post about API-driven applications (saying that monetizing APIs is an good reason to build API-centric applications).
Side Note: I have no beef with the latter post in general…it was mentioned in just one paragraph in his post and he’s encouraging people to do something I wholeheartedly support (building your API as the core of your app). This just brought up an issue that I have strong opinions about and wanted to take some time to cover.
So to everyone out there who thinks it might be a good idea to charge for your API, I have one question for you:
There are a multitude of problems with this attitude. I’m going to tackle one on a specific front and then some more in a general manner.Charging for Facebook Connect: A Terrible, Horrible, No Good Very Bad Idea
Forbes thinks so highly of charging for access to Facebook Connect that they listed it as one of only three potential ways for the social networking behemoth to make money. Wow. Maybe I should forgive them, Forbes is a financial publication, not a tech one, but just wow.
If Facebook started charging for its development platform, that would do exactly one thing: cripple its development platform. From my experience Facebook already has a tenuous relationship with developers (built more on a sense of feeling obligated to integrate with Facebook than a real joy in it) and adding a toll booth at the entrance to Facebook integration is only going to snap that tenuous link.
That’s not to say that some wouldn’t pay the price. All of those multi-billion dollar brands would probably happily still pay for their Facebook promotions. Zynga would likely pay up (begrudgingly) so as not to lose their stranglehold over the free time of the casual Facebook gamer. But smaller companies, individual developers and startups? No thanks, I can build on top of someone else’s social graph if you’re going to make me pay for Facebook’s. I hear Twitter is integrated into the iPhone these days.
Charging for Facebook Connect (which is not even what it’s called anymore) is also completely orthogonal to Facebook’s company mission to Borg-style assimilate the concept of identity on the web. It is to Facebook’s enormous advantage to get every site they possibly can integrating with Facebook, because that only drives more data and more eyeballs to the advertising and other means that will actually make Facebook money over time.
OK, so now I’ve got this little rant about Facebook off my chest, but let’s talk about the general question because I can see how it would be tempting to charge developers for API access as an additional revenue stream for your startup.Why You Shouldn’t Charge for an API
If you’re building a startup (especially a consumer facing one), monetization might be a tricky question. You may have pressures from investors or even just yourself that say “I need to know now how I’m going to make money.” In general, that’s a good thing, I think the “just get an audience and money will work itself out thing” is a dangerous line to tread. However, if you’re thinking monetization and “I know! We’ll charge developers to access our API!” I’m here to put a stop to that madness before it gets worse.
- API friction is already a problem. It’s hard for developers to integrate with new APIs. They have to learn a whole new set of methods and no two APIs are really implemented alike. You will likely already have to pour blood sweat and tears into docs and developer relations just to get a decent community using your free API. Charging for it is only going to increase this friction.
- Your API is not your business. You are presumably creating a product that has some sort of business value beyond its API (if your API actually is your business, maybe you can charge; see the section below). But the moment you start charging for access, your API is your business. And paying customers are going to have big expectations, meaning you now have to serve your API customers in addition to your normal customers.
- APIs should enhance your core business. Do you remember why you wanted to build APIs in the first place? It was probably in the hopes that developers would make awesome tools for your product that you didn’t have to build but nonetheless drive additional audience and/or customers your way. Charging for your API makes it more likely that developers are going to charge for their API products and you lose out on this benefit almost entirely.
- Developers will go elsewhere. The problem with marketing yourself towards developers (and this is what you’re doing if you charge for API access) is that they’re going to be a savvy bunch. If they can find a way to do for free what you offer for charge, they’re going to flock to it. Expect zero traction unless your product is so unique and peerless that they have no choice but to buy in. And even then, many developers would just take their toys and go home rather than integrate with a paid API platform.
Hopefully this gives you some idea of why charging for an API is generally a massively bad idea. Of course, there are exceptions to every rule, and I’d be remiss not to point out that sometimes charging for an API can make a whole lot of sense.When is Charging for an API OK?
So when is charging for an API OK? When your API is your product. That’s it, that’s the only time.
What do I mean by that? Startups that cater to developers by providing means to accomplish difficult-to-do thing via a simple API. Think of a simple API for grabbing screenshots of web pages, or semantic text analysis as an API, or an API for sending and/or receiving faxes. You can charge for an API when your API is going to take pain away from developers because in that scenario the developer friction works in your favor. If your API is much, much easier to use than the free alternative, finally you have the leverage you need to charge developers, and they will gladly pay.
The other potential scenario where it makes sense is when the infrastructure costs of providing your API are so significant that you have no other option. Twitter’s firehose is an example of this. The sheer volume of data that has to be transmitted to firehose partners demands payment because it requires dedicated operations support and resources just to make sure it doesn’t all come crashing down. And that only works because Twitter already had millions of users when they started charging.
So please build APIs, because APIs are an important part of the current and future web. Here at Opperator we’re building an API-centric app where the web interface is just one more client. But don’t charge for your APIs; it’s bad for your business and it’s bad for the development community.
List of cities/states with open data - help me find more!
It’s the beginning of 2012 and statistics/data science has never been hotter. Some of the most important data is data collected about civic organizations. If you haven’t seen Bill Gate’s TED Talk about the importance of state budgets, you should watch it now. A major key to solving a lot of our economic problems lies in understanding and using data collected about cites and states.
U.S. cities and states are jumping on this idea and our own Baltimore was one of the earliest adopters. I thought I’d make a list of all the cities that have made an effort to make civic data public. Here are a few I’ve found:
- New York City
- San Francisco
- San Diego (not sure if this is official)
- Washington D.C.
- New Orleans
There are also open data sites for many states:
Civic organizations are realizing that opening their data through APIs or by hosting competitions can lead to greater transparency, good advertising, and new and useful applications. If I had one data-related wish for 2012, it would be that the critical mass of data/statistics knowledge being developed could be used with these data to help solve some of our most pressing problems.
Update: Oh Canada! In the comments Ani Ruhil points to some Canadian cities/provinces with open data pages.