Consider this a cry for anti-agile, anti-hyped solutions for delivering the open social web.
I read posts like Erick Schonfeld’s “OpenSocial Still “Not Open for Business”” and I have two reactions: first, TechCrunch loves to predict the demise or tardiness of stuff but isn’t very good at playing soothsayer generally and second: there’s really no way Google could have gotten the launch of OpenSocial right. And not like my encouragement will make much difference in this case, but I’m with Google this time: just keep trucking, we’ll get there eventually.
On the first point, I’d like to jog your memory back to when TechCrunch declared Ning RIP and that Mozilla’s Coop was bad news for Flock. Let’s just say that both companies are both alive and kicking and looking better than ever. I don’t really care to pick on TechCrunch, only point out that it often doesn’t really serve much purpose to try to predict the demise of anyone before they’re really gone or to lament the latency of some brand new technology that holds great promise but has been released early.
On my second reaction, well, I have some sympathies for Google for releasing OpenSocial prematurely, before it was fully baked or before they had parity with the Facebook platform. We suffered a similar coal-raking when Flock 0.2 launched. It was literally a bunch of extensions and a theme baked on to the husk of Firefox and when people asked “hey, where’s the beef?!”, well, we had to tell them it was in the future. You can imagine how well that went over.
The point is, we kept at it. And after I left, Flock kept at it. And so just over two years after we’d released 0.2, Flock 1.0 came out, and the reviews, well, were pretty good.
Had we not released Flock 0.2 when we did and gone underground, there’s a chance we would have had more time to prove out the concepts internally before taking them to a wider and less-forgiving audience and would have avoided the excessive media buzz we unnecessarily spun up and that blew up in our face. I learned from that experience that enthusiasm isn’t enough to convince other people to be patient and to believe that you’re going to deliver. I also learned the hard way how long good technology development actually takes and that typically whatever you come out with first is going to have to be radically changed throughout the testing and iterations of any design process.
To look at what Google’s attempting to do, I can see the same kind of awe shucks, we’re changing the world kind of technical development going on. But unlike Flock’s early days, there wasn’t the same political and economic exposure that I’m amazed to see Google taking on. It’s one thing for Facebook, with its youth and bravado, to force its partners to toe whatever line it sets, and to have them build to their specifications. After all, if they don’t, their apps won’t work.
Google’s doing something slightly different and more dangerous, in that, not only are they basically building a cross-platform operating system that runs on the web itself, but they’re also having to balance the needs and passing fancies of multiple business partners involved in actually implementing the specifications to greater or lesser degrees, with varying amounts of attention and wherewithal.
Worst of all, between Facebook and Google’s platforms, we’re quickly heading down a path that leads us to a kind of stratefied Internet Explorification of the web that we haven’t seen since Firefox 1.0 came on the scene. Already we’re seeing inconsistencies between the existing OpenSocial containers and it’s only going to get worse the more adopters try to work to the unfinished specs. As for Facebook apps, well, for every Facebook app built to run inside of Facebook, that’s one less app that, today, can’t run on the Open Web and then God kills another kitten.
So the moral here is that slow and steady isn’t as sexy for the media or VCs but it typically wins races in terms of technology adoption and deployment. So I guess I can’t fault Google for releasing a little too early, but it’ll be interesting to see if it actually helps them get to a stable OpenSocial sooner. Whether it matters when they get there is a matter of debate of course, but in the meantime, hell, there’s plenty for us to do to improve the web as it is today and to solve some tricky problems that neither OpenSocial or Facebook have begun to consider. So, I’m with Doc. And I’m in it for the long haul. I’ll keep my eyes open on OpenSocial and frankly hope that it succeeds, but in the end, I’m interested developing on the best citizen-centric technology that’s going to shape the next evolution of the web.
So long as it’s open, it’s free, non-proprietary, and inclusive, well, even if it’s slow going getting it done, at least we’re not treading back in time.
Factory Joe 
Although I’m passionate about the subject and feel compelled to comment, I’m can’t find anything else to say but “couldn’t have said it better myself”. Please stop being so articulate, you leave me nothing to add! 😉
Good stuff, Chris. Reminds me of a general thought I’ve had before: the Web / tech / geek / social-media world could use more patient thinkers in the mold of Warren Buffett. Yeah, we love the fast pace, but we should also be thinking about building for years and decades, not (only) for 10 days / weeks / months of blogospheric reaction. The juncture may be in the minds of smart tech VCs, who understand both “Internet time” and Buffett-like patience plenty well.
Keep up the good work.
not that I’m disagreeing with the bulk of what you’re saying here (in fact, I’m all for anti-hype)… I’m not sure why this is an anti-agile cry though? What did agile do wrong in all of this? Unless you’re equating premature release with agile, which shouldn’t be the case unless agile is poorly implemented (which, unfortunately, it frequently is).
@Leisa: Perhaps I shouldn’t have used the word “agile” necessarily, but my point was really about those folks who misappropriate the “idea” of agile and simply think that because “agile” is in vogue that it means that products somehow take less time to bake.
This isn’t true and for some reason I think it sets unreasonable expectations. It isn’t that projects take less time because agile methods are employed, it simply means that a different, less water-fall-like method is used to arrive at better results. Being agile really doesn’t always result in shorter product development or production release cycles. At least given what I’ve seen (though I was involved with software development 30 years ago either so everything is relative!).