I believe that 2008 and beyond will be huge for mashups and APIs. We are going to move beyond the world of “Look, I took some data and put it together with a Google Map and Calendar” and have full featured read/write in browser APIs thanks in part to the slew of cross domain friendly features that are coming from browsers, Gears, and developer hacks.
I have talked about the blog.gears example, that shows how you can use Blogger as a back-end for a blog system. It seems quite obvious to me that if you are building a Web application that isn’t the Next Blog Thing, why would you want to spend any time building a blog system to get that functionality in the product. You have a couple of choices beyond writing it yourself. You could grab an open source blogging engine (there are many great ones), you could use a service and have blog.* CNAME over, or if you want tight integration you could do what blog.gears does, and use a JavaScript API to access blogger as the store and have it hidden from the user.
I got to thinking, how will the fact that it is easier to integrate with sites through richer APIs affect M & A?
An example that got me thinking about this is Dopplr and TripIt. Dopplr is a phenomenal service that seems to nail usability and the art of doing one thing, and doing it really well. It is clean. It has subtle touches that I love (the personal colors in the header icon and favicon even).
Them came along TripIt. The killer feature that it has is the ability to email your itineraries that you got from online sites and airlines to the system, and it groks a bunch of the formats and can thus suck them in automatically. Once you hit Apple-F, you are done, and you see the new information appear in your TripIt iCal.
Compare this to Dopplr. For a long time you would manually input your travel information in some shape or form. At the London Future of Web Apps I met Matt Biddulph, who not only was a fantastic, nice, fun guy, who gave the best talk at the event, but also was able to flip a bit which enabled Dopplr to read one of my Google Calendars. This feature is now in the wild for all. That was a great improvement, as I could setup a “Travel” calendar that Dopplr reads from.
I still had to keep that calendar going through. When TripIt came out, I heard cries of Dopplr fans that they should buy TripIt, or merge, or just copy the functionality. That isn’t the way with 2008. Instead, Matt was able to integrate with TripIt in a very simple way.
TripIt produces an iCal calendar from it’s data, and you can simply tie Dopplr to that calendar… and ta da!
I have been in quite a few meetings recently where the topic of buy has changed to be integrate through APIs. This enables each piece to grow, and to have people work on one small thing and make it the best it can be.
Of course, there is a time and a place for buyouts and mergers, but I wonder if they will be a little less frequent now. Then the game changes to being the platform, and being able to monetise it (a.k.a. make money to feed your family!)
Fixing calendars
As an aside, I still find a lot of pain with calendar systems. The main problem that I have is that I want events to cross various calendars, but collapse them in my view. For example, if I am going on a trip, I want my wife to see it, as well as my work colleagues. I don’t want to have to duplicate the entry in multiple calendars and then see the same darn thing repeatedly.
