Like everything else in the world, military command and control has come to the Web.  But with that transition come as many challenges as opportunities, as demonstrated by an article by Brian Robinson at Beltway-based Federal Computer Week's FCW.com, titled DOD arms soldiers, allies with information.

The story focuses on the goals and conclusions of the latest in a series of multi-national testbeds (Multinational Experiment 4 (MNE4)) intended to augment international military collaboration on the battlefield.  Success in this type of military collaboration, as with other ventures that rely on the participation of multiple parties, involves a high dependency on standards.  One lesson of MNE4, as summarized by MNE4 Technical Lead Maj. Pete Carrabba is this:

Open standards are essential for us to develop our own standards and applications.  Proprietary products force us into long-term contracts and provide no flexibility for us to develop according to our needs.

Here’s an interesting bit of data from the wild:  8 out of 10 folks that own both an iPod and a wireless router would give up their cool music tool before they'd do without their boring, clunky router.  The same percentage of those sampled would also give up their home phone before they'd sacrifice their ability to surf the Web from their favorite couch.  The data can be found in a survey conducted by Kelson Research for the WiFi Alliance, the consortium that promotes IEEE WiFi 802.11 standards and, more importantly, certifies compliance with them.

Surprised?  Don't be, because the iPod/iTunes system comprises a closed, proprietary environment, while WiFi products are based on a continuously evolving family of open standards, and that makes a far bigger difference than you might think.  If this sounds like too simplistic an explanation, consider the following: 

Let's look at the numbers first (gross sales and rate of change).  What we see is that there are many, many more wireless-enabled devices in the field than there are iPods.  According to research analysts In-Stat, wireless chipset sales hit 140 million last year, and should reach 430 million per year in 2009, by which time there should already be over a billion chipsets still in active use.  40 million of the chipsets sold last year found their way into home and small office/home office (SOHO) routers, and another 45 million into laptops and other mobile PCs.  That leaves roughly 55 million more to be incorporated into phones and other mobile devices.  Moreover, that 140 million number was up 50% from the year before.

In contrast, UBS Investment Research expects iPod sales to come in about a million units under projection this year, with about 39.8 million new iPods being bought in 2006, and a flattening in iPod sales growth after rapid expansion in prior years. 

While comparing music players and Internet access numbers is not a totally fair comparison, the ability of WiFi to achieve such dramatically larger sales numbers is still instructive, since few new capabilities of any kind enjoy such explosive growth.  When they do, though, its often because they are based on open standards, and from two resulting, related effects:  the ability and likelihood of multiple vendors to build new products, because the standard upon which the new products are based is open, and the tempting size of the market demand that can rapidly evolve because of the rich selection of competing products.  The result is sometimes referred to as a "virtuous cycle" of incentives and rewards to both sides of the sales equation.

An hour or so ago Sun Microsystems made good on an earlier pledge to issue further "non-assertion covenants" (NACs) in support of open standards.  In doing so, Sun has taken an important step in helping propagate and popularize a useful new tool to facilitate the implementation of open standards.  The new NAC appears here, and relates to the OASIS Security Assertion Markup Language (SAML) V2.0 standard.  Simultaneously, Sun is announcing a separate NAC relating to two other specifications co-developed with Microsoft: Web Single Sign-on Metadata Exchange Protocol and Web Single Sign-on Interoperability Profile.

These new NACs are modeled on the earlier commitment delivered by Sun to OASIS in connection with ODF.  You can find a detailed analysis of what that NAC promised in this earlier blog post (Sun's Simon Phipps describes it here), which contrasted the Sun NAC to one issued shortly thereafter by Microsoft with respect to its XML Reference Schema (since submitted to Ecma, and now referred to as Open XML).  The Microsoft NAC is further examined here.

The reason all of this matters is that an NAC has a number of distinct advantages over a traditional open standards commitment, and offers a way to streamline both the standards development, as well as the standards implementation, processes.  Here's why.

It's now been more than a week since Microsoft announced that its licensing discussions with Adobe had fallen apart after four months of negotiations.  Microsoft's statement was sparse, although a few additional details could be picked up from  Brian Jones' blog.  A few day's later, Adobe's PR firm released a few comments in an email blast, indicating that Adobe might have no more to say on the matter.  All of which left many (including me) speculating on what may or may not have happened. 

 Adobe changed its mind (barely) on June 12, and posted a statement  in the pressroom section of its Website that added little additional detail to inform the public what in fact is going on.

While others have a variety of concerns relating to this chain of events, mine is very limited:  standards are created, and rely, primarily on a system of trust.  If someone violates that trust, it shakes the entire infrastructure to its core.  Did that happen here?  Nobody knows, except Microsoft and Adobe, and so far neither of them is talking.  Until one of them does, the incident casts a serious pall over the viability of the standard setting system.  Why? Because if Adobe is seen to have violated the rules with impunity and suffers no consequences, then what reason is there for anyone else to honor their commitments?

All of this could be cleared up quite easily, by either party making one of the following simple statements:

1.  Microsoft sought to license only those elements of the PDF specification that lie within the ISO/IEC specification with respect to which Adobe made its RAND declaration. 

2.  Microsoft sought to license more than those elements.

Item:

Having the latest computer technology is great. But what e-government users from the public sector as well as citizens really want is software interoperability. Unfortunately IT managers still only pay lip service to such interoperability, concludes a European project assessing today’s open-source movement.

So reads the lead paragraph of an article called FLOSSPOLS, launched to support Free/Libre/Open Source Software policy support in Europe.  The summary continues as follows:

“Open standards provide independence, not traditional vendor lock-in. They are good for users, purchasers and government from both the economic and competition standpoint,” says Rishab Ghosh, from the Merit/Infonomics research institute in The Netherlands.

Given how often the words "open source" and "open standards" are bandied about in the technical press, it surprises me how little many in the open source community seem to care about the second half of this pairing of related tools.  It's especially surprising since open standards don't need open source, but open source, like all other software does need open standards.  That's reason enough for the open source community to want to know more about them.

For a week now, the IT world has been scratching its collective head over the breakdown of PDF licensing negotiations between Microsoft and Adobe.  At issue is why Adobe has allowed OpenOffice.org and Apple to bundle native support for saving documents in PDF format without any economic hooks, but apparently is requiring Microsoft to charge its customers more for Vista if this new release includes the same capabilities - even though PDF is a standard that should be available to all on the same terms.

There are, I think, two logical explanations.  One is relatively straightforward, while the other represents a convoluted and little-discussed weakness in the traditional way of creating standards.  In this entry, I'll describe both possible explanations, but I'm betting that the convoluted alternative will prove to be the explanation for what is happening here.

Let's knock off the easy explanation first, which relates to exactly what it is that Microsoft would like to license from Adobe.  At one end of the spectrum, Microsoft may only be interested in licensing those Adobe patent claims that would be infringed if Microsoft were to write software to implement the PDF specifications that have been adopted as standards by ISO/IEC.  Next up the value chain would be wanting to license the actual code that Adobe itself uses in Acrobat to save documents in the PDF format (not too likely a scenario, given that Microsoft has written a few lines of code over the years).  And finally there would be a Microsoft request to license additional features that are included in Acrobat, but which are not described in the ISO/IEC standard.  Such "proprietary extensions," as I discussed in my last blog entry, can be quite desirable - as Microsoft is well aware.

In the first case, Adobe would have an obligation to license the patent claims to Microsoft on RAND terms (on which more below).  But in the latter two cases, Adobe would be fully justified in imposing whatever unique requirements it wished on the extra code and/or patents, as the case may be, since it is not bound by the specific undertakings it entered into with AIIM (the actual standards body that developed the PDF standard, and then submitted it to ISO/IEC) with respect to actual code or any additional functionalities.

So the first possibility is simply that Microsoft wants more than Adobe is required to give it under its standards-related undertakings.

I had the opportunity last week to not only share a stage with Microsoft's Jason Matusow in Geneva, but also to enjoy dinner with him and some time to chat before that as well.  Jason is a good guy, and I enjoyed the opportunity to kick things around face to face that we've sometimes taken different positions on in our blogs.  Obviously, we have different opinions on the ODF/Open XML debate, but fewer than you might expect (and perhaps fewer than he expected). 

While we were exchanging views on open standards and open source with others at the conference, though, things were apparently falling apart in the ongoing negotiations between Microsoft and Adobe.  Frankly, although there may be more to the story that I don't know, it seems to me as if Adobe is in the wrong on this one.  Adobe wanted its Adobe Acrobat product to become the dominant product in the marketplace for saving documents in a locked format - the de facto standard for creating such documents.  In order to achieve that goal, it allowed aspects of its product to become the basis for what became an ISO/IEC adopted standard, which would involve providing licenses in a non-discriminatory fashion to whoever wanted one.  Once that happened, Adobe is under an obligation to make such a license available to everyone on substantially equivalent terms - which in this case would presumably be free, given that Apple and OpenOffice.org are bundling "save to PDF" capabilities in their offerings. 

What more could there be to the story?  One possibility is that the ISO/IEC PDF standard (what the standards world calls a "de jure" standard, or a standard "as law," because it has been adopted by a formal standards body) sits inside a larger "de facto" standard created by Adobe that the market likes.  Since only the elements that are within the ISO/IEC standard are subject to obligatory license, Adobe would be free to charge whatever it wants, and to whom, for the additional de facto elements.  Such "proprietary extensions," added by the dominant market player, are one way that a company that offers royalty-free technology for inclusion into a standard makes money.  In effect, the technology included in the de jure standard that is available under a free license is used to bait the hook for the royalty-bearing license required to implement the full de facto standard.  If this is the rest of the story, there is some irony in the fact that Microsoft has frequently been criticized for adding proprietary extensions to products it has built to a standard, thereby sometimes making them non-interoperable with other products built to the same standard.

Interestingly enough, this latest speed bump for Vista highlights a point that Jason and I had crossed blog swords over not long ago, which is my view of the importance of standards as a means of achieving interoperability over other means of achieving the same end.  Back on May 8, I posted an entry where I objected to the promotion of the idea by Microsoft of other techniques as a surrogate for, as compared to a supplement to, standards as a means to achieve and guarantee interoperability.  My starting point was a quote in an eWeek article to the following effect:

"You can achieve interoperability in a number of ways," said [Microsoft's] Robertson. Among them: joint collaboration agreements, technology licensing and interoperability pacts.

I had heard the same basic statement from another Microsoft representative, which troubled me, because while these other means can result in interoperability, they don't guarantee equality of opportunity and access the way that a standard does that has been adopted by a standards organization with an effective IPR policy - as has just been amply demonstrated by Adobe's apparently discriminatory withholding of a free PDF output license from Microsoft.

Before there was Linux, before there was open source, there was (and still is) an operating system called Unix that was robust, stable and widely admired.  It was also available under license to anyone that wanted to use it, because it had been developed not by a computer company, but by personnel at AT&T's Bell Labs, which for a time was not very aware of its status as the incubator of a vital OS.

Mighty was the rise of that OS, and regrettably, so was the waning of its influence.  Happily, Unix was supplanted not only by Windows NT, but also by Linux, the open source offshoot of Unix.  But today, LInux is at risk of suffering a similar fate to that suffered by Unix.  That risk is the danger of splintering into multiple distributions, each of which is sufficiently dissimilar to the others that applications must be ported to each distribution - resulting in the "capture," or locking in, of end-users on "sub brands" of Linux.

The bad news is that the rapid proliferation of Linux distributions makes this a real possibility.  The good news is that it doesn't have to, because a layer of standards called the Linux Standard Base (LSB) has already been created, through an organization called the Free Standards Group (FSG), that allows ISVs to build to a single standard, and know that their applications will run across all compliant distributions.  And happily, all of the major distributions have agreed to comply with LSB 3.1, the most recent release.

I recently interviewed Jim Zemlin, the Executive Director of FSG, as well as Ian Murdock, the creator of Debian GNU/Linux, and the FSG's CTO and Chair of the LSB Working Group.  That interview appears in the May issue of the Consortium Standards Bulletin and covers a great deal of ground.  Some of the most interesting details, though, relate to how this open standards process interacts with, and serves, the open standards process that creates Linux itself.  Below, I've excerpted those parts of the interview, so that you can see how it's done.  [Disclosure:  I am on the Board of Directors of the FSG, and am also FSG's legal counsel.]

FSG — Linux Interface

1.  Which open source projects does FSG actively engage with?

Primarily the Linux distributions but also many of the constituent projects, particularly if those projects provide a platform that developers can target that could benefit from better integration with the broader Linux platform. Good examples here include the GNOME and KDE desktop environments. Each of these desktop environments is a platform in its own right, but a desktop isn't much use unless it is well integrated with the operating system underneath. Furthermore, ISVs targeting the Linux desktop ideally want to provide a single application that integrates well regardless of which environment happens to be in use.

[more] 

IT vendors these days are in love with the phrase "open source and open standards" (as in "you should buy our open source/open standards-based solutions"). 

If you haven't already noticed that fact, here's a little experiment to try that will make the point:  Google the phrase "open source" AND "open standards."  I just did, and got 4,700,000 hits, with 284 leading to recent news articles.  Odds are, though, that few of those hits would take me to a knowledgeable discussion of how open source and open standards can and should work together.

In fact, while open source and open standards each work well in isolation, those who create them haven't always played very well together when they find themselves in the same sandbox.  As those 4,700,000 hits suggest, however, there's a great need for both sides to learn how to optimize the relationship between open standards and open source.  And that's the theme of this issue of the CSB, revisiting a topic I last covered in detail in the March 2005 issue.  That issue was called What Does "Open" Mean? and my editorial then was titled A Call for Communication Between Communities. 

A year has now gone by, and I decided that it was high time to return to this topic, so I did, and made it the theme of the May issue of the Consortium Standards Bulletin, which was sent to subscribers last week.  Here's what it had to say.

With more than a million standards in place in the world today, it is axiomatic that we are all profoundly affected by their existence. Yet only a very small number of people are involved in the creation of these standards, relative to the billions that are impacted by their implementation. As a result, the ranks of the affected vastly outnumber those of the affecting. Most ITC standards are created by consortia that don't permit individual participation at all (there are significant exceptions, such as IEEE), and the rest are set by "accredited" standards developers that honor the goal of including all stakeholders, but have a hard time getting many of those affected (such as consumers) involved. The result is that standards creation is primarily a vendor-controlled process, and there are real consequences that flow from the fact that a single type of stakeholder - vendors - has most of the influence, as compared to end-users, consumers and others

As a result, I decided to use the April issue of the Consortium Standards Bulletin to examine the concept of the "stakeholder" — an identifiable class of people and/or entities that are affected by the implementation of standards — and whether these classes are adequately represented in the standards development process.