Public discourse under way over definition of "open"

I've been taking some time to digest the open vs. closed discussion (the context being Microsoft's new XML document format for Word, Excel and PowerPoint) that's taking place in various corners of the blogosphere.  IBM's Bob Sutor, whose blog is entitled Open standards, open source, open minds, open opportunities, has been picking up on most of the discussion, pointing to and discussing various posts from folks like fellow IBMer and Web Services Interoperability Group chairman Tom Glover, Sun's Simon Phipps, and MWD's Neil Ward-Dutton who in turn point to others such as Redmonk's Stephen O'Grady.  I was moved by some of what I read, particularly when Ward-Dutton said "One person's (or community's) comfortable constraints can be anathema to another. That's why we will continue to have such healthy debate."  I also think a list at the end of one of Sutor's entries -- the one where he gets prescriptive about what to demand from your solution providers and CIOs -- is worth pinning on every cubicle wall and bulletin board, including IBM CEO Sam Palmisano's (after being edited to more broadly include all important standards).  There are plenty of other parts of IBM where what Sutor preaches should be practiced (as a solution provider).

In response to Glover's blog called Being open on open,  I commented with my own thoughts on open -- mainly that open is a state and that, as Sutor implied in one of his blogs, there are varying degrees of that state and that while specifications can be open and source code can be open, they're not the same thing (not a point that's being debated).  The box for editing comments on IBM blogs is small and difficult to work with if you're trying to edit a long post at midnight.   Below is a very slightly copy-edited version of what I posted.  

At the end of my comment on IBM's blog, I identified myself as the 2003 winner of the American National Standards Institute's (ANS) President's Award for Journalism.  I've never hauled out such a credential before in any of my columns or blogs.  But in the course of championing the benefits of standards on behalf of IT buyers and ZDNet's audience, asking vendors to step up to the plate by delivering compliant solutions, and pointing out where political friction -- the manifestation of the aforementioned anathema, if you will -- between solution providers over issues of openness can be disruptive to standards and hurtful to end users, my views have at times been dismissed by certain vendors.  But not by ANSI who recognized the need for advocacy in markets where the aftermath of such wars can take a devastating toll on consumers (which includes enterprise IT buyers), often  unbeknownst to them in a "what they don't know won't hurt them way."  If you want to charge me with trying to make sure "they" do know, or at least drawing attention to certain controversies in such ways that cause buyers to ask a few more questions before they take out their wallets (healthy for any market), then yes, I'm guilty. 

Here's what I wrote to IBM's Tom Glover:

Tom,

The aged, old debate:  What is open? 

I've written about this on ZDNet more times than I can count and I never get tired of discussing it because I think it is so critical for IT buyers to understand not just what open means, but why it's important.  A comment on Bob Sutor's blog (see The start of an "openness index" for specifications and standards) rightly paraphrased your entry as identifying various open "things" -- saying that there are many orthogonal aspects to the 0-to-1 spectrum of openness that Bob thinks might be helpful.  Given those things.. source, standard, process, and so on, the suggestion is that the word "open" and what comes after it (source, standard, etc.) can be treated separately. You say open is not a relative discussion while also saying that you're more in synch with Bob's views.  Bob clearly suggests that openness is relative when he says "but if something is a .15 and we are comparing it with something that is a .85, we at least have some sense of the latter being more open." I'd fall into the middle by disagreeing that open is a thing.  An open standard is a thing.  An open source implementation is a thing.  And while open may not be a relative discussion, the state of openness of one thing to the next is, as Bob says, definitely relative.  And that is what open is: a state.  You say that something is either open or it's not.
Bob says it's more like a range.  I'd go back to the "discussion" in "relative discussion" and say open is:
(1) the degree to which the discourse (or discussion) over the final result is public and,  
(2) the degree to which that final result is then open to unencumbered use.
The phrase "open standard" is a bit of a misnomer. What open standards are, at least at their inception, are open specifications.  Through some public discourse, there is agreement over what the final specification looks like, and then that specification is generally open for unencumbered deployment. "Standard" implies that it's the standard way to achieve the goal that the specification achieves. But it really isn't that until the majority of the world is using it. The W3C doesn't call HTML a standard.  It calls it a recommendation.  The IEEE has the 1754-1994 standard for a 32-bit microprocessor, aka SPARC. But is it a standard or just an open specification?  To me, it's actually a black-eye for open standards.
For something to be open source, the final code-base is open to public discourse (and how open that discourse is really varies from one project to next) while also being open for usage, mostly in an unencumbered way (although, as I've written, some open source licenses -- for example IBM's Common Public License -- could be legally interpreted as permissive of encumbrances (I'm not saying that this was the intention, but the weakness is well known in the open source community).  I agree with Bob then that the state of openness is relative.  The openness of the discourse various from one open thing to
another, be it a specification, source, or whatever.  
The Java Community Process allows for a certain amount of "public" discourse to arrive at a final specification (actually, a whole series of them). Whether that discourse is as open as the discourse in the W3C, the IEEE, or the ISO is certainly debatable. But, it by no means closed. Certainly not as closed as the discourse that preceded the inception of Microsoft's XML document format, is it? The openness for usage of the final results also varies from one open thing to another.  Clearly, for example, code that's available under one of the academic open source licenses such as the MIT or BSD licenses is far more open than code that's licensed under the MPL (Mozilla), EPL(Eclipse), CPL (Common) or the CDDL licenses.

Java is certainly open for implementation by anybody. ObjectWeb offered J2EE capabilities in JOnAS for a long time.  But, if you want to say it's not as open as HTML is because ObjectWeb wasn't open to use the J2EE trademark until the JOnAS was certifiably compliant (whereas there are no such restrictions on saying that your web page is HTML compliant), I'm not going to argue.  But with something as complicated and expensive as J2EE, buyers probably deserve some assurance as to degree of compliance.
Speaking of compliance, while I don't think you intended it this way, you appear to dismiss Jonathan Schwartz's discussion of compliance.  Compliance is what turns a specification into a standard.  What killed SPARC is that no one complied with it.  Compliance is absolutely critical for an open specification to make the transition to standard, as Bob rightly implies near the end of his missive on open document formats (see Open Document Formats: "Open" must be more than a marketing term).  Said Bob, "Insist today that the 
provider of your office applications (word processor, spreadsheet, presentation software) tells you that they will support the OASIS Open Document format." (By the way, I think Bob's checklist/prescription for IT buyers when it comes to what they should be demanding from their solution providers is marvelous).
This brings me to my final topic...... the reason any one would say such a thing (I'm not going to presume Bob's reasonings or anything else regarding Bob. He already refuses to speak with me).  Why should IT buyers insist that their vendors comply with open specifications? Interoperability is obviously a key benefit.  But more importantly, when IT pros establish strategies that adhere to open standards (open specs that have made the transition), they put themselves in control of their IT, instead of vendors.  As I've written before, if the proprietary nature of Microsoft Office's document formats and macro languages taught us anything, it's that we turned control of a certain part of our IT over to Microsoft.  Once we invested so heavily in those proprietary items (to the point of no return), we put Microsoft in control of the security, performance, and cost of our IT.  When Microsoft changed the licensing scheme to Office, what choice did we have but to go along? Well, if the OASIS Open Document Format existed at the time and Microsoft complied with it, we would have had a choice.  A choice to go to OpenOffice, StarOffice, Wordperfect, LotusWorkplace, or any other software that supported it.  If one of those offered better performance, lower total cost of ownership, or a more secure platform, then, through compliance, our ability to switch means that we're in control of those aspects of our IT, rather than the vendor.