Crikey! Scoble’s Almost Right!

Robert Scoble takes James Robertson to task for criticizing OPML in response to Scoble’s feature request. Mostly I agree with Scoble, when a user asks for a feature you shouldn’t give them a rant about why the specific technology they’re talking about is crap, you should give them your considered, professional opinion and recommendation. Hopefully that means identifying their problems and providing a solution but it might mean just telling them that their proposed solution won’t work and you don’t have an alternative.

Scoble is wrong to criticize James when James is in fact doing Scoble a favor by not giving him the specific implementation he asked for. The excerpt that Scoble quoted from James’ entry is very misleading. He really should have quoted the entire paragraph:

Ye gods, it’s time someone came out and said something. OPML is a really, really crappy format. Really crappy. I had massive headaches implementing OPML support for import/export in BottomFeeder. Why? Because there’s no real specification. Like everything Dave Winer has ever been involved with, the specs are all in his head, and it’s up to the rest of us to figure out wtf he actually meant. Here’s the “spec” – and look at all the meaningless crap in it (windowRight? Why is there something specifying the number of pixels for the margin?).

See, the criticism wasn’t actually that the format was difficult to work with or not technically perfect, it was that OPML just isn’t defined well enough to achieve the interoperability goals that Scoble had in mind. It doesn’t solve his problem. That’s a key response Scoble missed in his list of answers you can give to clients (as if you could ever enumerate every possible response you should give to your clients): “the solution you’ve proposed doesn’t actually solve your problem”. You may or may not provide a better solution, just having the knowledge that the current solution is wrong is very valuable.

Speaking of which, why are people so insistent on having the attitude that you can’t criticize something unless you can do better? Knowing that something won’t work is more valuable than coming up with the idea that doesn’t work – they’ve already done more than the person that came up with the original idea just by showing why it won’t work. Besides which, there’s a different set of skills required to do something than there is to evaluate it. How many wine drinkers know how to make a better wine than the one their drinking? How many have actually done it? Would you suggest they just drink whatever wine is put in front of them because they can’t do better themselves?

So to answer Scoble’s final question:

I see the feature I want. I see that someone has done it by hand to get what they want. I want even more. Are you gonna give it to me? Fine. If not, then can you stay out of the argument please?

I certainly hope not and Scoble, you’re very much out of line to expect him to butt out. Not only is he right to point out a serious flaw in OPML (a loose specification is one of the biggest flaws a file format can have, particularly when it’s intended to be used for interoperability) but he’s perfectly entitled to post to his blog about it in response to more and more users calling for OPML as the be all and end all solution. Maybe if he’d started his entry with “Dear Scoble,” or had given some indication that he was actually talking to Scoble instead of just reacting to something Scoble said you might criticise him for being rude to a potential user but as it is he’s just putting himself out there in the blogosphere with his opinion and being open. Isn’t that what blogging is all about? Isn’t that what you keep promoting?

Maybe Scoble’s just having a bad day. I’m probably being way too harsh – I’ve check the “Rant” box to serve as a warning… To end on a more positive note: Scoble, that is a pretty good list of requirements you’ve listed this time round. Hopefully someone will take that, decide what the best technology is and make it work for you. I’d also hope that Dave Winer picks up on the criticism and clarifies the spec so that implementations have something concrete and air-tight to implement and test against.