RSS, Echo, and Dave Winer

There's been a lot of back and forth about RSS and Echo and the role of Dave Winer recently. Robert's post in particular prompted this one.

Microsoft has engaged in things that were, let's say, less than honorable in the past. Surely they're not the only ones doing that. Everyone talks about how Microsoft's sole goal is "lock-in". Uhm, isn't that any technology companies goal? If I'm writing a Java Application Server, why do I want you to use another server? If I can add some value that is going to compel you to stay with my platform, all the better. I think one difference is, such activities are amplified with the weight of a Microsoft behind them.

I had a recent discussion where it was claimed that .NET is insecure because Microsoft has created insecure products in the past. Sure, if you know someone has a tendency you are going to assume that it might occur again. Might is the key word there. Track-records aside, the fact that a Microsoft product was insecure in the past doesn't necessarily mean that something created by Microsoft is insecure. This is a clear case of confusing sufficiency and necessity.

The same argument can be applied to the discussion of interoperability (ie the Interop == Works With Microsoft discussion).

I really think they're trying with .NET to play nice. These days, SOAP is about as standard as you can get for interop between platforms. They could have just done .NET remoting, but they decided to put an emphasis on WebServices (regardless of whether this was a marketing or technical decision).

Another example is the ECMA/ISO standardization. Again, I'm sure there were other motivations - government contracts, perhaps - but the point is, it's still a standard. That's more than can be said for the somewhat proprietary standard of Java (or RSS and OPML, for that matter).

I'm reading an interesting book now on the ethics and morals in the legal profession. In one of the chapters, it discusses the dilemnas that in-house counsel face as employess of their clients. Because they are both bound by attorney-client privelege and not necessarily covered by whistle-blower laws, it can sometimes be difficult to persuade the corporations not to do "bad" things. The best solution, the authors suggest, is a mix of positive and negative incentives - you'll be seen as a good community member and get good karma and, if that's not enough, you'll avoid fines and lawsuits too.

Perhaps this is what is motivating some of the recent moves at Microsoft, but the point is, it sure looks like they're trying. Any organization, let alone one the size of Microsoft, is going to be small slow to make such significant changes. They should be rewarded commended for making an effort instead of condemned for the state that they're in.

The RSS and OPML specs both have shortcomings that need to be addressed if they are going to move beyond de-facto standards and something more concrete that can have universal support across platforms and really add the value to corporations etc.

It's always easier in hindsight. Once you're solved the hard problems, it's quite easy to fix by looking back with an objective eye and the new knowledge learned. That's why refactoring works so well. I've re-written things from scratch in a week that have taken months in the first place.

Dave - you are quick to criticize Microsoft when they put their weight behind something because it is their technology and they want it to "win". Please don't do the same by being territorial and playing politics. Instead, get involved and apply the lessons you learned with RSS and OPML and MetaBlogAPI, so they don't make the same mistakes again and we can make progress.

(Updated some wording that wasn't quite right above)

Update: I also just wanted to clarify that I'm not necessarily promoting a fork in the community. In fact, quite the opposite. We should all work together for a better specification. Call it Echo, call it RSS 3.0, I don't care - just make it better :)

EngineeringWriting