[UOML] License for approval

[Brian Behlendorf]

On Sun, 25 May 2008, Wang Donglin wrote:
> Thanks for your kindly help. Your experience is a good education to us.
> Regarding requirement of standard compliance, It seems that strict
> requirement is necessary for interoperation(e.g. Java), or every one can add
> new feature for their own requirement, and that will kill interoperation
> standard. This requirement is the life of this kind of standard.

It's interesting you mention Java.  The history of the standardization of 
Java is too long to recount in an email post, though it might make for an 
interesting history book some day.  Without much substantiation, but with 
a point-of-view from the trenches of that battle, I'll make the following 
claim:  if Sun had focused less on fighting its own partners in the Java 
community and the broader Open Source community (the Apache, GNU, and 
other developers) over the idea of conformance, and spent more time and 
effort on creating high quality test suites, as well as 
pro-interoperability marketing devices (like certification marks, 
co-branding, etc), Java would have been much more widely and consistantly 
deployed, had been able to keep up with the exciting directions web 
development have gone in, and "write once run anywhere" might have 
actually had a shot at becoming true.  We had ten years of hundreds of 
really smart developers who could have contributed to establishing Java as 
the high quality and widespread standard it could have been... instead 
bashing their heads into their keyboards and arguing in endless political 
circles.  Only now, ten years late, is the Java Community Process working 
the way it always could have, where open source implementations are (for 
the most part) encouraged and allowed, and where standardization *follows* 
widespread innovation and implementation rather than trying to precede it.

The counter examples, of the most successfully implemented interoperable 
standards in existance, are the ones we take for granted: TCP/IP, DNS, 
SMTP, and HTTP.  None of them required conformance as a license to 
implement or redistribute; non-conformant implementations are eliminated 
from the market because they provide inferior service.

It will be interesting to watch how well Microsoft's implementation of ODF 
in Office 2009 works out - how interoperable it ends up being with 
OpenOffice's implementation, but more importantly, how quickly it's 
noticed and addressed when it's not.  My guess is that no matter how well 
intentioned the parties, and how stringent one's test suite is, even if 
that suite were tied to a license for redistribution, there would still be 
incompatibilities that lead to different user experiences.  Given the 
OpenOffice community's amazing ability to not just support the 
undocumented Microsoft formats, but bend over backwards to make them 
render well, I would have more confidence in a body of software licensed 
under an Open Source license to be able to deal successfully with these 
variances, rather than wait for a single commmercial vendor's 
closed-source code to be updated in a service pack.  In a well-run open 
source project, the motivations of developers and other participants are 
in favor of interoperability and standardization, and anyone can submit a 
fix for a bug that causes problems; in a poorly run project, or with 
closed-source code, the incentives are for deviation from standards as a 
means to differentiate from competitors.

 	Brian