MashupCamp--a new kind of get-together - | CNET News.com

Nice summary of MashupCamp by CNET's Daniel Terdiman over on news.com. I like this quote:

"The amazing thing about these camps, using open space methodology, is they shouldn't work," said Ross Mayfield, CEO of Socialtext, which makes social software for collaboration. "Like a wiki, it turns out that some very simple and open rules have shockingly positive results--because people, on the whole, are good. Open events like these have become almost commonplace in the Valley. In fact, I'd say they are a key driver for the current wave of innovation. One part wiki, one part space and two parts people, add water, and voila!"

This gets at what I appreciate most about the emerging Web 2.0 & mashup culture: you hear "client SDKs talking to APIs", but what's really happening is "developers talking to platform providers, other developers, users, and anyone else, all eye to eye." This is the most openly social, collaborative, and peer-to-peer development that I have seen in 25 years of coding, and I sure hope it sticks. Coding can be really fun. If it were not for these emerging social changes in software development, I don't think I would care nearly as much for the Web 2.0 world.

MashupCamp: costs of API support

In yesterday's "Why Mashups Fail" session facilitated by Anil Dash, there was a brief discussion of the cost to the platform providers of hosting open APIs. David Berlind chimed in that one of the major web platform providers has bean counters who claim a $0.07 per call cost, to a chorus of "this is a an API bubble" and "this is not sustainable".

It sounds bad, but maybe we need to look more closely at how we characterize the costs of open API support. First, these APIs are targeted at open ended use by developers and early adopters. They are essentially a playground for unconstrained (well, less constrained) innovation and creation, well suited to allowing good ideas to see the light of day. They are also good for allowing bad ideas to fail, and fail quickly, which is a good thing since early failure leads to faster learning. When the good idea matures to where it is deemed worthy enough to bring to the mainstream masses, I fully expect the platform provider to do what it takes beyond the existing developer API implementation to support it in a cost effective manner (i.e., one that scales to the many millions of mainstream users). I would not predict the mainstream application per-call costs from those of the developer API.

Second point is that through their open APIs and platforms, the big providers are subsidizing innovation and creativity outside of their companies at much lower cost to themselves, and with lower risk, than they could do it internally. The cost of the developer APIs may be better seen as leveraged R&D than simple operations, in which case maybe it should be valued differently.