Open Source, Open Standards

I’ve been told in the past that Open Source and Open Standards are practically the same thing, they go so well together. While they’re both good things, unfortunately, they’re not quite as naturally reinforcing as you’d like. There’s cost and style of participation, IPR concerns, and proliferation of standards (“The good thing about standards is, there’s so many to choose from” — ref).

Participation in Open Standards effectively can be expensive, even when the organization has no membership barriers. I’ve met Open Source developers who were already spending all their spare cycles contributing their coding skills and participating in their project’s mailing lists. Another mailing list to discuss standards? Not an option for many. Beyond the mailing list participation, physical presence is even more expensive, yet it’s hard to do without. I work with the AtomPub WG which has a high amount of Open Source participation, and that by itself has been great. The downside is that the WG never meets, and the email gets pretty nasty at times.

There’s a tension between big-process Open Standards groups like the IETF, and little-process informal groups. Take OpenID for example. It’s unclear who makes choices in OpenID and as long as that works, it works. I sure hope that the effectiveness period lasts as long as possible for OpenID, because when it stops it will be painful. In the long run OpenID will also have to strengthen its IPR rules or adopt somebody else’s. In the meantime, there’s no real protection if OpenID decides to adopt some technique which a company has already patented. Open Source licenses cover the code, but they do not cover the techniques and inventions that go into the protocol. Sadly, it’s the Open Source developers who are most likely to suffer from hidden patents, without recourse to big reciprocal license deals. Yet it’s my guess that Open Source developers are more attracted to OpenID’s process and style than to the IETF’s.

One might like to apply informal, familiar Open Source techniques to develop protocols — by this I mean adding features as you go, as they’re contributed, according to who participates, without following a requirements document or sticking to a staged development plan. But unfortunately, protocol design can really suffer under that practice, and it’s harder to fix later. I think it works much better for early software projects to learn and adapt as you go, refactoring to fit needs that have only just become obvious (been there, had fun doing that). Protocols don’t quite have the same adaptability — as soon as somebody has released software that implements the protocol, then you have to worry about backwards compatibility. You can’t refactor a protocol without serious, serious pain.

Apple has fallen for this “Open Source promotes Open Standards” trope, as Ben Laurie quoted recently:

The fastest way to get to open standards (our commitment) is through open source.

I’m happy that Apple contributes to Open Source. It’s not a replacement for Open Standards contributions, because of the IPR issues I mentioned above, and because Open Standards really suffer when there’s too many standards. When multiple “standards” exist for the same thing, interoperability can be non-existent and many software implementors just hold back and wait rather than risk picking the wrong one. With most people holding back and waiting sometimes it takes years for a winner (or more than one) to emerge. Contributing to Open Source alone, Apple risks adding to the proliferation of yet more protocols that do much of the same thing.

Also, Apple misses a great opportunity to help keep the official standards simple. When the big official standards bodies are full of people who do big commercial software, there’s a huge attraction to adding more features (standardizing every feature of every commercial software package) rather than focus on the basics of the most important use cases and interoperability for those. The big companies can even, at times, use this as a way to raise the barriers to entry to some class of software, making it so complicated to implement that the big incumbents get to lock in the market for much longer.