open social at mashup camp

Originally uploaded by sogrady

With the exception of one Mountain View iteration and the Dublin experience, I’ve been to every Mashup Camp iteration to date. And while it’s clearly evolved, it hasn’t evolved out of being one of the more interesting conferences I attend. Particularly because it’s a lens into a developer ecosystem of interest; one that didn’t disappoint this trip.

A few observations from the show.

Adobe

While Adobe has fortunately toned down some of their “the web is broken” rhetoric of late, adopting the far more flattering “complementary technology” position, every now and then one of the Flash et al crowd will get a bit greedy and assert the ascendancy of Flash, Flex and related technologies over the non-Adobe alternatives.

Conferences like Mashup Camp are a good reality check on that claim. With the exception of Ribbit’s session (check them out: it’s a bit like CallWave or Grand Central but with an API) and a planned Adobe session that didn’t materialize, I didn’t see a ton of any of the Adobe technologies at the show. It’s just a datapoint, but it’s a telling one given the focus of this developer audience.

Corporate

A few people at Mashup Camp noted that unlike the first few events, corporations were a more frequent and notable presence at this particular show. This is a concern for many, because as I’ve observed on many occasions, most conferences have a predictable trajectory to them. Early in the lifecycle, the corporate interests are few, the energy is genuine, and the content is high signal. If or when momentum and mindshare increase, corporate interest and dollars follow, and the event’s nature is fundamentally altered, typically irrevocably. It’s not inevitably for the worse, but it’s often perceived that way by the initial crowd who doesn’t recognize what their show has become. LinuxWorld is a good example of this phenomenon, in my opinion.

Fortunately, no one seemed at all inclined to argue that Mashup Camp had jumped that particular shark. Quite the contrary, if anything. Some of the corporate demonstrations were compelling, after all (Steve’s not least among them), and more importantly the unconference nature of the show mitigates any would-be corporate controlling interests. When the content is proposed and decided on by users, at the show, it’s difficult for sponsors to bend the agenda to their respective or collective wills.

Which is a good thing, as far as I’m concerned.

JavaScript

As discussed above, Adobe was not frequently encountered amongst the demonstrated technologies. But neither, really, were most languages. While my census of the employed technologies was not as comprehensive as in years past, I encountered a healthy mix of Java, PHP, Python, Ruby and the other usual suspects.

There was one common denominator, however: JavaScript. Nearly everyone was using it in some capacity, and one or two applications were nearly 100% JavaScript.

To anyone who follows the web development space, the preponderance of the J in Ajax will be about as surprising as the sun rising in the east tomorrow morning, but it’s interesting to see the traction sustained.

Macs

Macs weren’t quite as common as JavaScript, but it was close. Again, this is less than shocking news, but if anything the pace of Mac adoption amongst developer communities is accelerating. How long will it be before developers begin filling empty cups in front of me with spare change, assuming that my lack of a Mac is caused by an inability to afford one?

One other tangentially related item; of the Windows machines present, I only saw one running Vista. Every other non-Mac was running XP. And no, for the record, I didn’t see any other Linux besides my own instance. I was one lone voice in the wilderness.

Mobile

If it wasn’t #1 on the list of the most interesting trends at the show, it was 1A, but mobile was big. One initial tally had a quarter of the projects demoed during the speed geeking incorporating mobile elements, but after day 2 I’d put that number higher, closer to half. Even projects that seemed primarily web based seemed to have mobile components to them, as with the MyVox demo which allowed voicemails to be mapped.

Part of this, or perhaps most of this, is due to the iPhone, which maybe 1 in 3 of the demo-ing constituency owned. iPhoneLocator (only for jailbroken iPhones until the iPhone 2.0 arrives in June) being exhibit A of this, and iMovieMash.com being exhibit B.

For the Google folks in the audience, Android also was represented, with Metosphere based on the platform (in case you’re curious, the developer was not in love with it).

This trend, I think, is only likely to accelerate in future camps; the mobile cat appears to be out of the bag, permanently. And all I can say is: it’s about time. This should lead to far more useful handsets – particularly here in the US – where we’ve been shackled to devices carrying only the paltry applications the carriers tried to cobble together in a desperate and predictably futile effort to up their ARPU.

Multi-Dimensional

Not in the Hugh Everett “Many Worlds” sense, but rather in that mashups are now beginning to layer data along multiple dimensions. Rather than just dropping pictures along a map, for example, the WHAT HAD HAPPENED guys showed off the ability to place Flickr shots along a timeline. As both the data availability and the ease of integration increases, we’ll be seeing more BI cube like parsing of mashed up data, because mo’ context equals mo’ better. In a data sense, anyway.

Spatial

Once more, mapping mashups dominated the application scene. Like the multi-dimensional comment above, however, it was interesting to see the boundaries pushed. No longer are developers merely content to use maps as static objects to be integrated with other static objects, like real estate listings or the like. Instead, the spatial implications of maps are beginning to manifest themselves in an application sense. Maps are becoming more dynamic, as location information via handsets or other GPS devices is incorporated along with routing and other fancy location based services.

Should be fun to watch.

Adrian Demoing Chicagocrime.org

Originally uploaded by sogrady

Like Rafe, I just wanted to thank Adrian Holovaty for the soon-to-be-decommissioned Chicagocrime.org.

While I fully understand and appreciate the reasoning for its planned retirement, it’s a bittersweet moment for me. Chicagocrime.org has been a staple of my discussions around Web 2.0 and mashups since the day it launched, as it – along with Paul Rademacher’s HousingMaps – communicated the concepts far more effectively than mere words ever could have. Meeting Adrian in person first at OSCON and subsequently getting the chance to speak with him at various Mashup Camps was an honor.

Like many, I certainly look forward to seeing where Adrian and company are going to take EveryBlock – and have already brought it to the attention of various NYC dwelling friends, but I’ll always have a special place in my heart for Chicagocrime.org. And I don’t even live in Chicago.

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. [1]

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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?

For more on the session, take a look at Gordon or John’s pieces.

[1] You might recall that I’ve made a similar argument in the past, which drew substantial pushback from Microsoft’s Dare Obasanjo, which I, in turn, responded to here.