Distinguishing between Open Standards and Open Source Software is essential, as they each are tailored towards different ends. The fundamental purpose of a standard is to promote interoperability. The philosophical objective of OSS is to ensure that software users may access, modify and redistribute source code; as the name itself suggests.

 

An Open Standard is a specification to enable interoperability or portability developed through a consensus process. Open Standards can be implemented by both Non-OSS and Open Source products. Essentially OSS is code, and Open Standards isn’t. The Open Standards process is neutral with regard to software development, welcoming all and favoring none in it’s quest for the best solution.

 

There are a couple of points to make in distinguishing between Open Standards and Open Source Software:

-         Software code is not an Open Standard.

§         There is no inherent connection between the model under which particular software is developed, licensed and distributed, and the fact that the software does or does not conform to a particular Open Standard. Claims that Open Source and Open Standards are the same are as mistaken as statements that claim the Internet and the World Wide Web are the same.

-         Developing software differs from developing Open Standards.

§          The fact that a technical specification is implemented in Open Source doesn’t establish consensus in the implementation and does not make the technology a standard.

-         Differences between de facto Product Standards and Open Standards.

§         In a somewhat different context, some software can be so widely adopted that it is considered a “Standard”. Irrespective of whether the software is distributed under OSS license or Non-OSS license like Java or Windows, market driven forces will encourage the creation of Open Standards to ensure that the ecosystem of complimentary products continue to effectively function.

-         Reference Implementations.

§         Typically an implementation of a consensus based Open Standard can be developed in many different ways and can be made under a variety of different software licenses. To facilitate the adoption of a standard, it is sometimes desirable to make a reference implementation available as a starting point or as a sample for those who either do not want to invest in the development of a unique or optimized implementation, or simply do not have the expertise to do so.

§         The notion that the availability of an OSS reference implementation will advance adoption of a standard over Non-OSS reference implementations has a few flaws. Generally, the reference implementation will be made available under very favorable, often royalty-free, license terms. However, this does not necessarily mean that the license will be an OSS license approved by OSI.  For example, the reference implementation may be available for evaluation, non-commercial use, or have restrictions on its modifications or limited distribution rights, all of which could be in opposition to the OSI criteria for Open Source Software licenses.  In fact in some cases, reference implementations released under an OSI approved OSS license may do little for adoption.  If the OSS license is one requiring that all modified and extended versions of the OSS program also be distributed as free software under the same OSS license, then some implementers may actually be discouraged from taking advantage of the free reference implementation, because they would be prohibited from commercially licensing a resultant software product (or combined hardware/software product) if that product includes this reference implementation.

§         Another concern may arise from the unknown origins of the code base. If the reference implementation was developed in a community project, or even under the auspices of the Standards Setting Organization, and if anyone can contribute code to the reference implementation they may not have had the rights to contribute, then the resulting reference implementation may not be deemed safe to use in commercial products.  Consequently, reference implementations developed under these open but uncontrolled processes may not encourage the adoption of the standard in commercial settings at all.

§         Typically those who commercially distribute products that might include a reference implementation may have to provide their customers’ assurances in the form of representations or warranties that the software does not infringe the copyrights of another, violate any contractual agreements, or disclose the trade secrets of others. More importantly, such commercial vendors may have to indemnify their customers if their customers are sued for using code that they did not have the right to use.

 

OSS proponents frequently assert that the universal accessibility of OSS code promotes interoperability. Although the same could be said about commercial software, the potential risk of code being altered in a non-conformant manner is probably significantly lower when source code is under some form of tight control, such as with a commercial entity whose paying customers demand conformance. The freedom to modify code also includes the ability to undermine its interoperability.

 

As architects and IT decision makers, recognizing these distinctions between Open Standards and Open Source Software is essential to meeting the needs of clients. Open Standards are a vital part of solutions built for organizations that seek to implement interoperable solutions from multiple vendors, regardless of the development model used in the implementation.