Kolkhoz to jungle

In a recent post on his blog, Mark responded to the critics who think that making WSDM 1.0 an OASIS standard was premature. Go read his entry for the point by point refutation of the arguments against WSDM standardization (which, based on this entry, doesn’t seem to quite convince Savas). The key point I take away from Mark’s reply is that it is ok for people to say that they think a condition for being a standard it to be entirely based on approved standards, but this is not the only view of the world. As Mark pointed out, it’s doubtful that the OASIS organization would have just “forgotten” to mention this in its bylaws and process if that was its intent. Those of us who welcome WSDM as a standard take the view that this requirement is too strong and the real requirements are that the spec is implementable in an interoperable way, that it is royalties free and that it addresses an industry need.

I respect the opinion of those who would have rather waited for WSRF, WSN and WS-Addressing to be standards for WSDM to ship as a standard. The thing is, if this is very important to them they do not have to implement WSDM right now. They can wait. And the fact that WSDM 1.0 was released ahead of WSRF, WSN and WS-Addressing doesn’t mean that the version of WSDM that the “wait and see” crowd wants to see won’t arrive. In fact, the WSDM TC is committed to updating the specs when these dependencies reach standard status. It will just be called WSDM 1.1 or WSDM 1.5 or WSDM 2.0 or WSDM IsOracleHappyNow Edition (yes I should be in marketing). People who don’t have an urgent need for a Web services-based management infrastructure can very reasonably decide to wait until then. The fact is, many people have this need now and they need the best standard they can get. DMTF is not waiting to provide Web services access to CIM-modeled resources. GGF is not waiting to manage Grid resources. Devices vendors are not waiting to Web services-enable their products. The JCP is not waiting to provide a Web services interface to JMX for app management (see JSR 262). And those are only broad industry segments, not specific customers who want to build an adaptive infrastructure. These are the people that WSDM 1.0 is trying to help. If you don’t have the need then yes you might rather wait for a better later solution. But let’s respect those who have the need. We worked hard in WSDM to come up with the best compromise for the present time.

Which takes me back to the title of this entry. The Kolkhoz approach to standard is what I see as the claim that the entire stack accross all standards organization has to be completly clean at any point in time. Nice but really hard to do in the environment we live in. And with a high risk to result in proprietary solutions taking over long before anything useful comes out as a standard. On the other side of the spectrum, there is the jungle approach, where de-facto standards rule or where specifications are written by a group of people who are only looking for rubber-stamps from standard organizations. What we are trying to do with WSDM is find the right balance between kolkhoz and jungle. This is why for example we make use of specs that are not yet standards but being standardized but we stay away from specs that are not even in the standard process even though sometimes it might be technically tempting to use them (think policy and metadata). To the jungle people, we are too slow and too committee-driven which they love to sneer at. To the kolkhoz people we are barbarians who trample the rules and processes and they love to stone us for it. We don’t try to be heroes to either, we try to be heroes to the customers.