Twice in one day…
Scoble responds to lots of criciticism that he’s evangelizing a crappy format, and really misses the forest for the trees. Actually, he misses the trees too. Earlier today I recorded this podcast, which I wasn’t going to post, but if Scoble’s going to go on, I think it actually merits it.
Scoble writes:
See, as a user, I really don’t care about the spec. I can’t read them. I don’t appreciate them. And, all they seem to do is lead to religious arguments one way or another.
I’m a user. Shoot me.
But what Dave did was give me an application. It works. And, as a user, I wonder “if the format is so crappy, how did Dave get it to work in his own application?”
And, as a user, I wonder “why can’t the developers just get their OPML to work with Dave’s application?”
The reason that developer’s just can’t get their OPML to work with Dave’s application is because the specification sucks. There is simply no way for anyone to tell if the OPML file generated by their application is really compliant with what Dave’s editor implements, or only just happens to never tickle a bug or an ambinguity which wasn’t specified.
It’s really not that hard to write an application: the trick comes from interoperability. To be useful, these files must be able to be routinely exchanged between applications written by different people, and that simply isn’t feasible without a clear, complete specification of what the format actually entails.
Scoble concludes:
The crappy format is good enough until someone comes up with something better. And that’s what you’re all missing.
What Scoble is missing is that currently he’s in a position to help dictate what gets adopted and what users are going to be seeing for the next five, ten, or even more years, and if he had any concern for those users, he’d work to ensure that the technology underlying that growth is as robust and reasonable as possible. OPML doesn’t qualify. RSS doesn’t even qualify. Did we learn nothing from the whole HTML standards process?
Pingback: Burningbird
Pingback: Elliott Back
Pingback: 0xDECAFBAD
Pingback: tech.memeorandum @ 2:25 AM ET, October 1, 2005
OK, but all you have to do to give me what I want is copy TechCrunch. Nothing more, nothing less.
Editor’s note: Sigh.
That isn’t a specification, Robert.
In fact, you haven’t even said what it is about TechCrunch that you like, or how OPML figures into it. If I chose to “do what Tech Crunch does”, how could I possibly know if I captured the functionality that you need if you won’t say what that is?
Mark,
I like yor blog and I like your podcasts. Although I don’t agree always with you. But that’s the way it goes.
I listened to your podcast and I read your post with your thougts on the specs for RSS and OPML and thoughts about the way Dave Winer operates and the request from Robert Scoble. Sorry to say so but I don’t quite understand what your point is.
Do you mean that the format of the specs is ambiguous or do they leave too much room for different interpretations or … do you mean anything else?
And about Robert Scoble: he explained what he wants. Why should he have to explain why he wants to have what he asked for?
Please make your points and objections more clear (not for software architects, not for software designers, not for software developers and so on but) for users like me and many others.
That would be great!
Fred
Editor’s note: It’s not clear to me that you will understand if you haven’t before. Put simply, I believe that if you are engineering systems for users, you have a responsibility to ensure that the underlying technology is robust and reasonable. Why? Because you can’t make a silk purse out of a sow’s ear. Bad underlying design is reflected in bad applications.
In the case of OPML and RSS, it is particularly criticical because these formats are actually interchange formats: formats which different applications use to communicate with each other. The RSS and OPML specifications are ambiguous and ill defined: they rely on XML, but most feeds don’t actually take very many pains to ensure that they are well formed and can be parsed by standard XML tools. Neither really pays much attention to standard XML mechanisms like namespaces. There are ambiguities like the one I mentioned for enclosures. All of this results in poor interoperability.
It’s nice that Robert has an application that he likes, but to me, it’s largely irrelevent. The existance of his application is good for him, but it’s useless for me, because I’m not interested in a world which is only supported by a single Windows XP application. The lack of interoperability is bad for users, no matter what Robert says.
Robert, it’s all well and good that you do not understand the technology behind the magic curtain. You’re right, as a user you do not have to.
What you fail to grasp is that as a user, the best tools and apps are delivered to you when developers are looking at technology behind a transparent curtain, not an opaque one. This is why HTML works and has been so widely adopted so fast. There is even a standards body (W3C) to ensure that the curtain is transparent, the specs clearly stated, and the access of developers to the underlying technology unfettered by obtuse definitions and opaque curtains.
“Because it works, and it works the way I want,” is fine for the average user. But the informed consumer knows that the process of putting the app together is as important as the end result.
Think of it this way. You sit down for a meal. It is absolutely the very best food you have tasted in your life. You cannot imagine living a life where you never taste it again.
You go to the kitchen and ask the chef, “What *was* that! It was amazing! I’d love the recipe!”
His reply is, “I cannot remember exactly how I made it, and even if I did, there’s no way you could ever follow my recipe to make it again. You’ll just have to eat at this restaurant every single time you want to taste that food.”
Would that be acceptable? Would it fill you with confidence in that chef’s abilities? Or would you be somewhat disgusted and wonder why a cooking professional could not do something as easy as make his recipe understandable to others?
If your answer is the former, you will never really understand why open source is so attractive to smart people, why open, published standards are always more successful long-term than proprietary methods, and why Microsoft needs to become more transparent and more of a community player.
If your answer is the latter, it makes your defense of OPML thus far untenable.
Mark,
Thanks for putting your effort in clarifying your point(s)! I do understand what you mean.
About “RSS and OPML specifications are ambiguous and ill defined”: What puzzles me is the fact that the
discussion about this did not start earlier for instance immediately after Gnomedex 5.0 when RSS (and the OPML editor) were an issue. Do you have any idea why it took more than three months before the professionals started the thread?
Editor’s note: I have no idea. The notion that RSS was an ill-defined spec is immediately apparent to anyone who actually works to develop a library to parse it, and goes back years. The incompatibilities between versions 0.91, version 1 and version 2 are a hint as to the mess the whole thing is. Check out Mark Pilgrim’s writings on the subject: they go back years.