Anil Dash is Wrong About Treehouse Clubs

In a post about how the Twitter API is becoming a de facto standard, Anil Dash derides the impulse of groups to work together to create web standards:

The natural inclination right now for geeks of a certain type is to start dreaming up new standards bodies, or how they can participate in the Open Web Foundation to make a Super Awesome Twitter API Evolution Committee. Here's my recommendation: Don't. Don't do any of that ----, and don't run off to make membership badges for the Treehouse Club quite yet. Instead, just iterate and ship. ...

The good news is, consensus around evolution of the Twitter API can happen simply by saying to each other, "If two application developers who share no common investors or board members can reach agreement around an extension to the API, and between them they have a significant enough number of users to be relevant, then we should all just adopt their work."

This is important because it reframes the conversation from being about technical merits, and all the boys who like to play with APIs always think they know what's "better". I'm sure if I wanted to waste an afternoon, I could tell you a dozen ways in which the Twitter API could be "improved". But guess what? That ---- does not matter. Adoption matters, and I'm heartened by the fact that people seem to be getting that.

As he suggested in our prior discussion of RSSCloud, which currently is being revised unilaterally by one person with no public process to ensure its soundness, Dash believes there's value in "simple, human-readable but potentially ambiguous specs."

I used to think that too, but after spending so many years involved with RSS, I have a better understanding of the costs that developers incur because of half-assed specs. During the 18 months in which the RSS Advisory Board drafted the RSS Best Practices Profile, we accumulated more information on how RSS has been implemented than anybody else on the planet. It's never a good thing for a specification to be "potentially ambiguous." If two developers disagree on what a spec means, their software will not interoperate. And once their software ships, they'll be mad as hell if the specification is revised to make their interpretation the incorrect one.

This leaves you with a situation where you know that a spec is confusing people, and you know that developers are implementing it in incompatible ways, but the most you can do is offer advice like this:

Support for the enclosure element in RSS software varies significantly because of disagreement over whether the specification permits more than one enclosure per item. Although the author intended to permit no more than one enclosure in each item, this limit is not explicit in the specification.

Blogware, Movable Type and WordPress enable publishers to include multiple enclosures in each item of their RSS documents. This works successfully in some aggregators, including BottomFeeder, FeederReader, NewsGator and Safari.

Other software does not support multiple enclosures, including Bloglines, FeedDemon, Google Reader and Microsoft Internet Explorer 7. The first enclosure is downloaded automatically, an aspect of enclosure support relied on in podcasting, and the additional enclosures are either ignored or must be requested manually.

For best support in the widest number of aggregators, an item SHOULD NOT contain more than one enclosure.

So when somebody asks me if an RSS item can contain more than one enclosure, I give that long-winded answer. When I'm asked the same question about Atom, the answer is this:

Yes.

Guess which one was created by a Treehouse Club?

Dash's vision of a Twitter API that evolves every time two developers agree on a new feature would rapidly devolve into an unworkable mess.

Twitter · Rss · Web Standards · 2009/12/18 · 13 COMMENTS · Link

Comments

All fair points, Rogers, and I appreciate you raising them. I do think ambiguities like the one you've highlighted would likely be worked out between two vendors pretty quickly these days (vs. just being decided by one vendor), but overall I have no objection to the existence and smart use of standards bodies.

What I was trying to emphasize is that waiting to have a bunch of folks get in a room first and try to imagine the future as a predicate to writing a spec, is that you end up with formats that document the thinking of a particular group at a particular moment, as opposed to common practice. Like, almost nobody supports adding tags to a blog post via Atom -- why is that? Because tags weren't considered an essential part of blog posts at the time.

At any rate, I'm very willing to be proven wrong, and have no question that some folks will move towards a standards body. But I think OAuth and OpenID and other successes show that a code-first cycle can still yield good defacto standards.

#1 · Anil · 2009/12/18

I think there's a place for de facto standards that emerge like the Twitter API, as long as people accept the authority of the originator and the originator is diligent about documenting it properly. But once authority becomes an issue, it's better to have a Treehouse Club.

I'm confused by your example about Atom and tags. If you're talking about the Atom Publishing Protocol, I'm under the impression that it can be used to publish or edit any component of a weblog post that's represented in the Atom syndication format. Since tags are in atom:category, they can be added using APP.

#2 · Rogers Cadenhead · 2009/12/18

Also, am I misreading what you mean by a Treehouse Club? Looking at the history of OAuth, it seems like that was the result of a club forming around an important need.

#3 · Rogers Cadenhead · 2009/12/18

Rogers, we know what you don't like, but what is your recommendation? Do you have a vision?

Should the WordPress guys wait to implement the Twitter API? If so, what would they be waiting for? Have you contacted Matt and raised your objections? What about the Tumblr guys? What about Twitter? Is it okay for them to implement and document an API without checking with you first?

Re rssCloud -- which you have objected to countless times but have never made a contribution to -- what's your vision for a Rogers Cadenhead-approved method of implementing RSS 2.0? Do we have to get your approval before writing code? Where is the cloud element mentioned in your profile? It looks like you only started caring about it once we started using it.

Just wondering how deeply you've thought this through and if your complaints are personal or about the method used. If the latter it seems you should apply your principles uniformly and not just criticize me but also Twitter, WordPress and Tumblr (to name just a few).

#4 · Dave Winer · 2009/12/19

I think my recommendation is pretty clear. As long as Twitter's authority over the Twitter API is unchallenged and it documents the specification properly, it's a decent foundation for other entities to build on. But if the ad hoc process Anil favors begins happening, and competing groups begin making changes to it, the best approach is to form a group that works in the open and can try to achieve consensus on the best path forward.

As for RSSCloud, I emailed Matt Mullenweg in September when WordPress implemented your proposed API and encouraged him to find a way for the process to be open, with authority resting in a group instead of just one person. I made the same request on my blog. That hasn't happened, so I've been working on PubSubHubbub instead.

PubSubHubbub is much better specified than RSSCloud and there are four project owners and 11 committers.

My advice to Mullenweg and the other developers implementing RSSCloud is that they will buy themselves much less aggravation in the long run if they employ the same model we do on the RSS Advisory Board: Form a group and do all your deliberations and voting in public.

And if they don't want to form a group, they should take it to the RSS board or another entity that can draft the spec and finalize the API.

#5 · Rogers Cadenhead · 2009/12/19

#6 · Dave Winer · 2009/12/19

I have nothing to do with the efforts to turn the Twitter API into an industry standard for microblogging, nor am I particularly engaged in the issue. My comments were about Anil Dash's conclusion that we don't need "Treehouse Clubs" to create standards and an API can just evolve when any two developers agree on a change.

My vision is for developers to favor well-specified standards created under an open and accountable process over poorly specified ones created by fiat.

People should place more value in rock-solid specifications that get things right the first time by involving other people in the decision-making required to draft them.

#7 · Rogers Cadenhead · 2009/12/19

Coool. Now you're acknowledging that things don't work the way you want them to. Maybe other people feel the same. Maybe even I do.

But the fact is, this is how progress is made in tech. Someone goes first, achieves some success, then others want to tap into the growth so they try to be compatible, then others climb on, and eventually you get a standard.

That's what's happening with Twitter now. If you think RSS is a problematic, you ain't seen nothing yet (see my post today's on scripting.com for an idea of just one problem, what the at-sign means on various platforms). But the Twitter API is a force of nature, and people are going to clone it, for better or worse.

RSS, compared to other standards, isn't that bad. And if you think it's my fault (which you say over and over) then you don't understand what was happening. Pretty sure you do understand, we talked about this stuff a lot at that restaurant in St Augustine Beach, if you recall.:-)

There was a lot of pushing and shoving and a lot of people trying to keep RSS from getting its shit together. But it eventually did, thanks to the publishing industry, not from the tech industry who you seem to think has all the answers.

If you want to help, then help. There's absolutely nothing in your way. Or you can keep trying to stop me -- but please notice that it isn't working. Maybe you should throw in the towel already. Just a thought.

#8 · Dave Winer · 2009/12/19

I think that what's happening with the Twitter API is interesting. If you, WordPress, Tumblr and other folks manage to pry microblogging out of a single company's control, that will be great.

RSS isn't that bad, but people should have their eyes open about the costs incurred by adopting a loosely worded specification that is politically untenable to change. I think the RSS Advisory Board has done as much as humanly possible to make RSS easier to adopt with the Best Practices Profile. You recommended that we write the profile as an alternative to revising the spec, but after we did that, you never publicly supported the effort. I think that's a missed opportunity. Every developer who implements the RSS specification would avoid a lot of aggravation by reading the profile.

I'm not trying to stop you. Your second version of RSSCloud was unstoppable from the moment WordPress adopted it. But I would like to see people learn the lessons of RSS.

#9 · Rogers Cadenhead · 2009/12/19

Wow - look how obsessed Winer is with Rogers! Look out, Rog - it's only a matter of time before he gets your haircut and starts dressing like you - SWF style.

#10 · cop · 2009/12/19

I've written clients and producers of RSS and I can confirm that its ambiguity was maddening at times. Thank goodness for FeedValidator.org or we would have never cleared things up.

#11 · Bill · 2009/12/19

Rogers, I had no idea you wanted my support.

I'm never bashful to ask for it.

Learned this from Bill Gates, who cornered me on the floor of Comdex in 1987 or 1988 asking when I was going to convert my software to run on Windows. I couldn't believe he cared, and truth be told he probably didn. But he didn't act like he didn't care.

The way you talk about me on your blogs, with such derision and contempt made me think, however foolishly, that you held my opinion in low regard. I guess I'd better recalc on that. :-)

#12 · Dave Winer · 2009/12/19

He only hit you 'cause he love you, Rogers. You know that, right?

#13 · Vance · 2009/12/20