Yes, the post is a month late, and yes, I promised it eons ago, but better late than never as they say. Particularly in this case, because the issues at hand have not and will not be subsiding at any point in the near future.
The way it all happened was typical Mashup Camp serendipity. I was sitting in the opening session next to Kapow‘s Joe Keller, when it occurred to me that there was a chance that Alan Taylor – of Amazon Light fame – might be in attendance since the Boston venue (the Hotel@MIT) would be closer to home for him. Just as I was in the process of emailing him to find out, I heard a voice say, “Hi, I’m Alan Taylor and I’d like to talk about…”. Yeah, I’m a fan of Mashup Camp.
Anyhow, one of the reasons that I was hoping to speak to Alan – aside from the fact that he’s just a good guy and I hadn’t yet met him in person – was his experience and exposure to one of the risks of mashups: legal action. He has, in the past, received (and complied with) cease and desists for non-obvious (and in some cases, suspect) infringements. Given the increasing importance of mashups from an application development standpoint – there are a variety of would-be players in the market, as Anne covers – it would seem to me that we should be talking about issues around licensing and commercialization more. David Berlind, the co-founder of Mashup Camp, actually touched on the very same subject – assuming I’m recollecting his talk correctly – during his Zend Conference keynote, positing that mashups might benefit from a widely understood license much as open source has.
The logical decision, given the wonderfully low barrier to entry nature of Mashup Camp, was to propose a session and see if anyone else was as interested in the subject. Dave Nielsen, a natural for this conversation given that the ex-eBayer works for a firm that monetizes services, kindly agreed to help facilitate the discussion and we were off and running.
While I expected the subject would generate some interest, I was surprised – and quite pleased – at just how well attended it was. We had, at one point, standing room only in a room seating 50 or 60. Even better was the quality of the discussion. As my former (that better than old, sir? colleague Gordon documents in his session notes we had quite the wide ranging discussion, exploring elemental questions such as what, precisely, is “commercial” usage? Or how usage and billing of webservices compares to ASCAP practices. All interesting.
What I found most compelling, however, was the idea that that there might be an opportunity for some basic minimum standards for the terms of service under which many of the APIs are provided. When this subject was raised, by Brian Hamlin, I believe, it was initially scoffed at by one portion of the audience, who saw it as an attempt to dictate terms for large businesses that are, after all, providing these services largely at no charge. But that was not, in my opinion, the aim. It was rather to try and provide some guidance for service providers that frankly seem as confused on the economics as the developers themselves. Who charges, how much, for what?
What I’d enjoy personally enjoy seeing, to be housed with whomever seems the best fit, be that the Programmable Web, the Creative Commons – whoever, would be a Mashup Developers Bill of Rights. To forestall the inevitable criticism, no, the point of such a document would absolutely not be to tell properties such as Amazon, Craigslist, eBay, Google, Microsoft, or Yahoo how they should conduct their business. Not only would that be beyond quixotic in its inevitable futility, it would be ungracious in the extreme, considering that these businesses have to date been very liberal from a usage and consumption standpoint, at a non-incidental cost to their own businesses.
But it’s also true that some of the service provider behaviors and developer relationships could stand to be improved, and indeed, representatives from many of the above firms have admitted as much in the past. It’s difficult, as an example, for developers to build services without knowing when or how much they’ll be charged for usage of a given API. Or to comply with terms of service that change weekly, daily, and sometimes even hourly. Or to build applications on top of services that may be shut off with little or no warning. It would seem that some of these, at least, are addressable from the service provider’s perspective, at little or no cost but communication. 
It’s in both sides best interests, I’d argue, to try and settle on a Bill of Rights. The terms must be relatively broad, because overly detailed and prescriptive “rights” would be too brittle for the highly differentiated and ever evolving stable of services. But developers would be able to build with greater confidence, understanding ahead of time when or if they’ll need to make money; service providers, for their part, would remove potential barriers to entry while fostering more transparent relationships with an important audience.
I certainly am not the one to create the definitive list of rights, nor do I think there’s any single individual so qualified, but maybe by citing a bit of what I’d like to see agreed to we can at least begin the conversation.
The Mashup Developer’s Bill of Rights
- Developers have the right to 24 hours notice before service termination, except in cases where a.) they’ve obviously violated clear and understandable terms of service, b.) they are generating substantially anomalous and/or damaging traffic, c.) said service termination is caused by an unanticipated service issue on the provider’s side.
- Developers have the right to upfront and transparent pricing, so that they may determine ahead of time whether or not a service will be suitable for long term – and possibly commercial – usage. Pricing terms will clearly vary from service to service, depending on quality of content, size of content, time-sensitivity of content, and so on, but the model should be clear and understood upfront.
- Developers have the right to 48 hours notice for a material change in the terms of service (e.g. pricing), so as to give them adequate time to either continue with the service under the new terms or secure an adequate replacement. During the 48 hours, they are permitted to operate under the previous terms of service.
- Where possible, developers have the right to 48 hours notice for a material change in the quality of service, so as to give them adequate time to either continue using the service under the new conditions or secure an adequate replacement.
- Developers have the right to clear delineations of where services can and cannot be recombined. While it’s both natural and acceptable that service providers may not wish to be mashed up with competitive services, these concerns should be an explicit declaration as part of the initial terms and conditions agreement.
As should be obvious from the above, a lawyer, I’m most certainly not. But the Bill of Rights should not strive to be, IMO, legally binding in any sense of the word. It should rather be a codification of the respect both parties – developer and service provider – must have for one another. As developers increasingly consume and repurpose services and service providers increasingly depend on their developers for volume generation and ecosystem expansion, it would behoove both parties to have some Creative Commons-simple understandings on which to base their relationship. But that’s my takeaway: what do you guys think? Make sense? Dumb idea?