mashups

Mashups are built on trust, but I am paranoid, so what to do?

Standard

By their very nature Mashups are built on trust..

  • You have to trust the API providers to keep that API up and running. Anyone that has done Twitter mashups know how much keeping an API up and running is worth.
  • You have to trust the API providers to keep the API (somewhat) stable and to not remove features that you are depending on, or add features you really dont want. An example of this is all the mashups built on Google Maps, and we all know that there are way too many of those. Have the developers of those mashups really thought about what happens when Google puts ads on the Maps (and they will, they have already started in parts of the US)? I dont think so, the developers just trust Google to keep on going. If you have a commercial site using Google Maps you probably do not want ads for your competitors on those maps.
  • If your mashup becomes a success you have to trust the API providers you are depending on not to change their terms of service so that your mashup suddenly becomes an illegal use of the API. Also, you have to trust the API provider not to use the fact that you are depending on their API for your business against you in a business negotiation.
  • If you use web scraping you have to trust the site you scrape not to change to often (or at least trust your own ability to roll with the punches and update your scraping so it works with the new version of the site as well) etc. That is a lot of trust, and when mashups move from toys into real applications this becomes an issue.

All these things makes me a bit nervous, as I am a bit paranoid (note: this has not been clinically proven, I still think that THEY are out to get me). So how to mix a healthy bit of paranoia into my mashup building and get something good out of it all? What I do is that I always try to be aware of that I might have to switch API provider. Are you building a Twitter mashup? Why not also take a look at Jaiku’s API, or Pownce’s API (or Plurk or FriendFeed etc etc). You dont have to build your mashup so you can switch API provider in a matter of minutes, just be aware what else is out there so that you see the commonalities and don’t use to many features unique to one provider. This is the approach I am currently using when I am building mashups, at least I know that if shit hits the fan I can always go with somebody else. It will hurt a bit and take some effot, but I am not dead in the water. For the Google Maps example this would mean looking at Yahoo Maps and see what features the Yahoo Maps API have in common with the Google Maps API, and just use those common features. This can also come in handy if you hit the maximum number of requests on Google Maps, then it would be nice switch to Yahoo Maps automatically.

The risk with all this is of course to spend to much time preparing for something that won’t happen. It is the same situation as developers spending so much time making their code perfectly scalable and optimized that they acctually never ship anything in time. So dont go too far, but be aware of the situation. Trust is nice, but trusting several API providers to always do a good job and to not be evil in order for you to survive is quite risky.

Mashups mainstream by 2013 according to Forrester

Standard

According to a new report from Forrester Research Enterprise Mashups will reach their tipping point during 2009-2010 and then become part of the general IT landscape by 2013. This means that the old IT gigants like IBM, Oracle and Microsoft will dominate the mashup market and mashup platforms will be part of their offerings. I guess this means that Microsoft Popfly will merge into Sharepoint and IBM Mashup Hub will merge with WebSphere.

Forrester divides mashups into three types:

  • Presentation layer mashups – merge content from seperate sources into one view, the simplest type of mashups.
  • Data mashups – more complex data driven mashups that get data from several sources and present them in one view
  • Process mashups – mixes business processes and users with data from several data sources.

Presentation mashups and data mashups sound very much similar to me, but then again I dont get payed by Forrester… But Forrester has a lot of influence over this so unless Gartner comes up with another definition this is the ones we have to live with.

I am glad to see that Forrester also realized that enterprise mashups will be huge. It is kind of a self realizing profecy – there will be a lot of men in ties reading this report so it is going to help Enterprise Mashups grow. It is really the next wave in enterprise software. And if you are reading my humble blog you are already years ahead of the mashup wave 🙂

For more info about this report see Forrester: Enterprise Mashups to Hit $700 Million by 2013 on ReadWriteWeb.

How to market your APIs and your Mashups

Standard

Last week I was at Mashup Camp 6 in Mountain View, my 4th one so far. One of the discussions at the Camp was about how to market your mashups, and that got me thinking more about the subject. Here’s my rant about how to market your API or your mashup that resulted from my latte induced and lack-of-sleep fuled thinking. Since there are, by definition, several components to a mashups there are also several levels of marketing. The first one is where the API provider needs to market the API to developers to they start to use it. The second one is where the mashup developer needs to market their mashup to the end user.

The API Provider
You have this great service that lifts humanity to a new level, makes the sun shine brighter, makes TV sucks less and give the gift of limitless bandwidth to the people (or at least it is really cool). You have even added this great API, now what? How do you get developers to start using the API and spread the word of your great service to everyone and their grandmother?

Well, let’s back up a bit. First of all, do you really have a great service? If you do, then do you really have a great API? Without a product people want to use there is no need to go through the hassle of promoting it. Make sure that the API actually is usefull for developers, that it will enable them to do cool and usefull stuff easier than if they would just hack it all together from scratch. Also make sure that there are plenty of documentation, examples, code snippets etc for the developers to get their hands on to minimize the barrier to entry. Hack together some mashups yourself with your API included in the mix, to give people and idea of what can be done. The key to get an API used by developers is to get the developers excited about the possibilities and get them talking. So give them something to be excited about and something to talk about.

Once all that hard work is done then you can promote your API via directories such as programmableweb and webmashup so that developers can find you. If you have made your own example mashups, then go through the steps below to market that, that is a good way of getting some recognition.

Last, but not at all least, show some love for the developers that has taken their time and built something using your API. Have an example gallery where they can list their creations. Blog about them. Talk about them at conferences. “Link love shall be bestowed upon those who link love showeth”.

The Mashup Developer
For the developer of the mashup there is Google AdSense money on the line, or maybe just recognition from peers. Most mashups result in web pages anyway, so make sure to do all the SEO stuff – have good page titles, have a good copy, have validating HTML, have a sitemap available etc. If there is money down the line for you then also throw some money at advertising (Google & Facebook makes this a walk in the park). All this is standard, but as there are differences between mashups and a regular web page you should also use that to your advantage.

What APIs do you use? What tools have you used to piece things together? Explain how you made your mashup, what the moving parts are. If you used Yahoo! Pipes, then link to the pipes used and explain how they were done. If you used Google Maps (and if you are a mashup newbie then I guarantee that you have, just admit it… “my name is Andreas, and I am a Google Maps addict”) then explain how. If you used openkapow robots, then explain how you developed them. Since API providers are suckers for traffic, just as everyone else, it is not unlikely that they would be interested in adding your mashup (assuming it kicks-ass, which of course it does) to their example gallery. All this creates more link love, more Google baits and really increases the chances of your mashup being found and appreciated by fellow developers. Another plus is that all this also increases the chances to be blogged about, do not forget that bloggers are suckers both for traffic and content.

There’s both money and recognition in entering your mashup in a contest, see programmableweb for a good list of what you can enter right now. You might not have to redo the mashup from the ground up, just add another API to the already great mashup you have made and you could already be a winner. If you go to Mashup Camp you could enter the traditional Speed Geeking (like speed dating for mashups basically) and go home with a shiny new Macbook.

Of course also list your mashups in directories such as programmableweb and webmashup , but by now you should know that already 🙂

Thanks for everyone that discussed this with me at Mashup Camp! For the notes from this session check out the Mashup Camp wiki.

32% knows what Mashups are, only 1% have implemented Mashups

Standard

Every year Web Service Awards asks hundreds of Swedes online randomly about their knowledge about different trends on the internet. In the report coming out in February they have asked people about Mashups for the first time. 32% of the peopled responding have heard of Mashups, compared to 93% for blogging and 81% for RSS. Of the people that knows something about Mashups the level of knowledge is divided like this:

  • 7 % had very good knowledge of Mashups
  • 13% had good knowledge of Mashups
  • 12% had some knowledge of Mashups

Even people that knew nothing about Mashups apparently follows what happens, since 41% are following Mashups. On the other end of the spectrum only 1% of the people responding had acctually implemented and evaluated Mashups (they didn’t ask me, so I have no part of that lonely percentage). I am looking forward to seeing next years Web Service Award numbers, hopefully Mashups have become more mainstream by then.
Richard Gatarski on weconverse.com has a more detailed report on the different questions and answers in the poll.

Mashups at Web Service Awards 2008

Standard

Yesterday I had a presentation about Mashups at the annual Web Service Awards in Stockholm. Since there was a lot of webmasters and people working with big corporate web sites I focused of my presentation on what mashups can do for web site owners. Basically the two things I wanted to the listeners to get out of my presentation were:

  • Do not be shocked when somebody mashes up your site, it will happen if it hasn’t already. It is a great possibility for marketing your services and not a threat!
  • Use mashups to quickly create unique and usefull user experiences to enrich your web sites.

Here is my presentation (in Swedish only):

The presentation went very well and I got a great response to it. It seems like I did at least tickle the interest of the audience and at least some of them will play with mashups and hopefully all of them will see mashups as an opportunity and not something weird and dangerous. I think that Sweden is getting ready to embrase the Mashup wave.

You can find all the presentations from the Web Service Awards here, I especially recommend the usability presentation from Johnny Mellgren at Vinnovera.

Thank you to Richard Gatarski for inviting me to do the presentation and thanks to all of the people I queued with for the food yesterday 🙂