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?