Using Open Source to Bootstrap Your Data Service

Last week SimpleGeo and their partner Stamen Design jointly released a project they have been working on together called Polymaps.  It’s absolutely beautiful and a stunning example of what you can do with the SimpleGeo API.  They’ve released the Polymaps source code on GitHub so any developer can quickly see how the API is used, play around with real production code, and modify the base examples for their own use.

When I first started program, it was 1979.  I started on an Apple II – I learned BASIC, Pascal, and 6502 Assembler.  I studied every page and example in the Apple II Reference Manual (the “Red Book”).  Whenever I got source code for any application at a user group meeting, I stared at it, played with it, and tried to understand what it was doing.

When I started programming on an IBM PC in 1983, I did exactly the same thing.  I spent a lot of time with Btrieve and there were endless source code examples to build on.  I had a few friends that were also using BASIC + the IBM BASIC Compiler + Btrieve so we shared code (by handing each other floppy disks).  We built libraries that did specific things and as each of us improved them, we shared them back with each other.

In my first company, we were heavy users of Clarion.  While Clarion was compiled, it still came with a solid library of example code, although we quickly built our own libraries that we used throughout the company as we grew.  When I started investing in companies that were building Web apps in 1994, it was once again all HTML / source code and examples everywhere.  My friends at NetGenesis (mostly Raj Bhargava and Eric Richard) wrote one of the first Web programming books – Build a Web Site: The Programmer’s Guide to Creating, Building and Maintaining a Web Presence – I vaguely remember NetGenesis getting paid something like $25,000 (which was a ton of money to them at the time) to write it.

In the last few months, the phrase “data as a service” has started to be popular.  I’m not totally sure I understand what people mean by it and I’ve been involved in several larger discussions about it and even noticed an article today in the New York Times titled “Data on Demand Is an Opportunity.”  I’ve invested in several companies that seem to fit within this categorization, including SimpleGeo, Gnip, and BigDoor, but we don’t really think about them as “data as a service” companies (SimpleGeo and Gnip are in our Glue theme; BigDoor is in our Distribution theme).

When I reflect on all of this, it seems painfully obvious to me (and maybe to you also) that the best way to popularize “data as a service” is to start with an API (which creates the revenue model dynamic) and build a bunch of open source examples on top of it.  Your goal should be to make it as simple as possible for a developer to immediately start using your API in ways relevant to them.  By open sourcing the starting point, you both save an enormous amount of time and give the developers a much more interactive way to learn rather than forcing them to start from scratch and figure out how the API works.

I like how SimpleGeo has done this and realize that this can apply to a bunch of companies we are both investing in and looking at.  I’m not sure that it has anything to do with the construct of “data as a service” (which I expect will quickly turn into DaaS) but it does follow from the long legacy of how people have learned from each other around the creation of software, especially around new platforms.

While we are using SFLA (silly four letter acronyms – we’ve got PaaS, and IaaS, along with our old friend SaaS), any ideas what ZaaS is going to stand for?

  • http://twitter.com/rodyancy @rodyancy

    I don't know what ZaaS is going to stand for, but I can can say that SimpleGeo open sourcing and iPhone SDK and an augmented reality SDK is a big reason why we us their service.

    • http://www.feld.com Brad Feld

      Neat – glad it's working for you.

  • andrew watson

    That’s one reason Twilio has been so successful. They have a kickass API, kickass documentation and lots of examples AND helper libraries available so it’s really easy to get up and running quickly. People have literally started businesses in a single weekend using their API to drive all the telephony.

    Oh and they give some free time to play with the API so it doesn’t cost you anything to try it out.

    Did I mention they have a kickass API? :)

    • http://www.feld.com Brad Feld

      Yup – Twilio is a great example of this and I've got it on my list of “companies I hope to regret not having invested in – I'm a big fan.”

  • nicholasnapp

    Here's a new "aaS" for you — UaaS: Underwear as a Service. See http://www.ManPacks.com. The more I think about it, the more I think it's not as silly as it first sounds…

    • http://www.feld.com Brad Feld

      I love manpacks.com – it's a brilliant idea that I saw a few weeks ago.

  • ZAO

    NICE

  • Pete Soderling

    Totally agreed that APIs are the foundation of DaaS. (Just had to use the acronym, sorry ;)

    There are some pretty cool open-source toolkits like http://restx.mulesoft.org/ that help developers publish REST APIs based on existing data or applications quickly and easily.

    On the business side, we've been doing a lot of thinking about DaaS pricing models and how premium data and services should be priced – http://blog.programmableweb.com/2010/08/26/data-a… . Love your insight about pricing models being dynamic once a business makes the jump to data on demand.

    Good post. Thanks, Brad

    -pete