Philip Brittan's Blog

Open Source Archives

Open Standards Definitions

What do we mean by open standards anyhow?

My last entry evoked a certain amount of name-calling in the arena of open standards. Today I'd like to explore just what "Open Standards" might mean. This will seem very simplistic to many of you, but I hope it’s helpful to sort things out in a simplistic way.

I’d like to start with some definitions:

Open - Open for third parties to support and create products to (opposite is Closed)

Proprietary - Legally owned by a company, individual, or private group (opposite is Public Domain)

Community - Administered by a group, not just a single company (opposite is Sole-Stewardship)

One minor note that some people seem to miss is that open and proprietary are not opposites. A standard may be both open and proprietary at the same time. A "closed standard" is an oxymoron. You can have "closed systems" which do not allow third-party integration, but you cannot have a meaningful closed standard.

A standard that is not legally owned by any company or person is said to be in the public domain. Examples of this include: HTML, SNMP, etc.

A proprietary standard is owned by a single company and may be administered solely by that company, as Windows and Solaris APIs are, or it may be administered by a community, as Java is. Some communities are have their own bodies for collaboration (JCP), and some rely on standards bodies, such as the W3C, OASIS, ECMA, and so on, to handle community collaboration and be the official keepers of the spec.

An "open source" standard is one in which the source code as well as the APIs are included in the specification of the standard, meaning that third-parties can extend the product at the source code level, not solely by working through an API. Open source is considered by many to be the purest form of open standard. But again, that doesn't mean it can’t be proprietary. Linux, a favorite open source example, is not in the public domain. The Linux GPL license does not require a monetary fee, but it does make other requirements which it imposes with a copyright. For instance, all source code for modifications made to Linux must also be freely available. Linus Torvalds explicitly owns the registered trademark "Linux". FreeBSD, as a counter-example, is also free of charge and open source, but does not impose the requirement of sharing enhancements with anyone else.

Whether software costs money, and what it costs, are economic/strategic decisions made by the owners of the software / standard. 0 is a price, just like 5 or 745. 0 just carries more psychological weight than other numbers. The underlying license and source code for Linux are free, but distributions of Linux do not have to be free. Companies can charge whatever they want for them.

The relative advantages of these are not moral. They are rooted in various benefits they give to the owners and users of the standards. One of the benefits of using open community standards is vendor-independence: multiple vendors can create competing products that implement the same standard, thus giving customers more choices. Cost, ability to extend, and ability to debug are common reasons that customers choose open source software, but keep in mind that many “closed-source” solutions do provide source code to their paying customers for debugging purposes. One might say that a sole-stewardship standard carries the risk to users that the single company administering the standard can potentially change that standard to suit only its own needs, thus causing damage to third-party users of the standard. Conversely, since a community-administered standard must reflect the interests of a group of different constituencies, it is unlikely to change capriciously or quickly. This distinction is the heart of the Microsoft / Java war of words.

The flip side of that is, of course, that since community standards are slow to change, single-stewardship standards can be much more nimble and capture the changing realities of the marketplace in a more time-sensitive way. When a standard is too slow to change, then vendors supporting the standard are sorely tempted to add one-off extensions for functionality that is not yet standardized, which erodes the value of the standard.

Customers make choices about their adherence to standards based on what they need to achieve and the risks they perceive.

.NET on Linux

Could Microsoft co-opt Linux?

I have read a number of articles and blog entries speculating about whether or not .NET will catch hold on Linux and on what it would mean if it did. Much of the speculation centers around whether Microsoft will put out its own version of .NET for Linux, but there is also a lot of discussion of Mono, Ximian’s version of .NET on Linux, which has been released without Microsoft’s participation and is gaining some traction.

Some of the commentators are concerned about the power that .NET on Linux will give to Microsoft, many others think that it would be a victory over Microsoft. To explore this, I’ve been considering the following “thought experiment”. Imagine this timeline:

1. Microsoft releases .NET framework for client and server.
2. Microsoft gets excellent traction with .NET on the client-side (which I firmly believe they will, unless they are more seriously challenged there, as I outline in my Java vs. .NET blog series)
3. Microsoft strongly encourages the adoption of Windows Servers by marketing the synergies between the client and server pieces of .NET, and makes some headway there
4. IBM, Sun, Oracle, and other Java vendors push hard to drive Linux adoption in the marketplace, at which they also make good headway. .NET starts to get some adoption on Linux thanks to Ximian Mono.
5. Then, suddenly, in the face of "customer demand", Microsoft "capitulates" and releases a version of the .NET server framework for Linux. It is not free but inexpensive, and perhaps nets them an amount of money approaching a basic OEM Windows Server license.
6. Microsoft then drives adoption the .NET server framework on Linux using the strong synergy with the large and growing base of .NET client applications, taking share away from Java app servers. Mono is crushed by Microsoft in the process.
7. Microsoft releases the .NET client framework for Linux and a version of Microsoft Office that runs on it.
8. Microsoft ends up owning the developer APIs for Linux, client and server, which is perhaps more important than owning the operating system itself.
9. Since no company owns the Linux kernel or the lower-level Linux APIs on which this .NET for Linux will be built, there is no one to thwart Microsoft’s efforts to control how software is developed on Linux. If Microsoft succeeds in taking control of the developer APIs for Linux, it makes money from Linux’s popularity, and once again there is no one to challenge Microsoft desktops.

Interestingly, Microsoft is already offering a portion of .NET for Mac OS X and FreeBSD. These might well be experiments to test the waters or perhaps simply ways to keep the DOJ calm. What if Microsoft helps BSD compete more effectively against Linux?

This work is licensed under a Creative Commons License.