permalink

2

Open or De Facto Standards – the Battle of the Giants

On 24th August 2011 using twitter gave me more than just news and interesting articles for the first time. On August 24th I was witness to the battle of the giants when I watched a discussion between Sam Johnston (@samj) and Simon Wardly (@swardly) on APIs, the possibility to patent APIs and much deeper on weather standards and thus APIs needed to be open or proprietary de factor standards were all right.

To give you an impression on who I was listening to – besides that I personally think they both are two of the most important guys to follow on twitter on the topic of cloud computing – I give a brief overview. Simon used to be Cloud Computing strategist at Canonical (the guys who do Ubuntu) after being Chief Economic Office at Fotango and is now researcher at the Leading Edge Forum of CSC. Simon also gives one of the most compelling and best presentations on the topic of “what is Cloud Computing”, which you can find <HERE>. Sam Johnston – successful tech entrepreneur – was technical program manager at Google Switzerland and is now director for Cloud Computing at Equinix. Sam was part of the Open Cloud Initiative and is now pushing OpenStack.

I do not know how their discussion started, but I have made a screenshot of the discussion and put it in this post (which like any twitter discussion you will have to read bottom to top) but it turned out that two worlds collided on the topic of standards and how they should be created and maintained.

Simon made the argument that as long as the API is public anything that is practical and seems to be used by many people (the de facto approach) can legitimately be called a standard and that in case the company who´s proprietary implementation was used to implement the standard could always be circumvented by reengineering the functionality behind the API.

Sam on the other hand argued that standards, the API AND their implementation needed to be open and agreed upon between as many parties as possible to make the base for using and developing them as free as possible and especially to prevent any company who might have originally created the implementation behind an API to do anything “evil” in the future.

I find myself naturally siding with Simon on this argument because it has been a long crusade for me to convince people that the actual implementation is not worth talking about as long as you knew the API and could out whatever you like behind the API (or reengineer the original functionality). Also I believe that corporate interests are not necessarily evil and that the market is actually a fairly good regulator (especially the mrket that is created by engineers having their ideas and concepts compete against each other).

Thinking along these lines I found myself longing for that raised finger that Sam put up “what if someone abuses the power they get through owning an implementation of an API” because there obviously is a lot of power behind this and the most absurd example is the completely useless battle of egos between Adobe and Apple about Flash on the iPad. An open standard for what browsers had to support and how plugins have to work in order to make users want to use them would keep us all from having to stand in the middle of this stupid war.

My personal actions in coding and in designing architectures strongly reflect what Simon is saying. I do not believe in reinventing the wheel just because I like or do not like the original inventor, as long as I feel I could do so if that inventor and his terms turned nasty on my. But in many arguments I have sided with Sam´s open standard arguments.

And as I don´t much like it –especially in myself – when I seem to say one thing and behave differently I tried to look behind the scene, made some interesting observations and came to an important conclusion.

One of the more interesting observations was that Simon and Sam, two guys whom I have seen interact in person and on twitter for a long time, who are normally on a friendly basis and agree in most of their conclusions get religious and almost personal on this topic. This is a strong hint to me that this topic is loaded with emotion and there is always a question weather this helps or is a deterrent.

The second interesting observation was that fact that Sam and Simon were sometimes talking about different things. Where Simon was talking about the API, Sam was talking about an implementation or when Sam was talking about the ownership of an API Simon was talking about the legal strength of this ownership. Many interesting discussions can be spawned from this about software patents and the value of knowledge and intellectual property in general.

My conclusion is that there is no “right” way to go, because if there was only Simons argument it would be very simple for the owners and developers of de facto standards to abuse their position and even make strategies o explicitly do so. If there was only Sam´s world we would try to make an exact plan of the future and have a democratic decision on every variable name in the universe (sorry, I am just exaggerating to make a point) and that would slow us down immensely. Thus my conclusion is that we need this battle between open standards and proprietary de facto standards because they act as a catalyst for innovation and as an evolutionary safe guard against going down one direction too far. This is also why we need people who are very convinced of their position and less distant to make these points, because someone who does not come across as authentic (and you know what I mean when talking about authentic when you have seen Sam market Open Stack and condemn everyone creating proprietary software to the lowest realm of hell) would have no audience and all the safeguard and innovation power for long term development would be lost. On the other hand it is easy to argue why Simon´s part of the argument is emotional, simply because it is about profit. And arguing profit is always an emotional topic.

For me and my software development this means that we will go on supporting the open source community where we can – financially and with code contributions – but that we will not be religious about using none open standards. On the other hand my respect for guys like Sam Johnston has increased by actually thinking about this argument, because these guys (and there is one of them behind every open idea on the net) put themselves into the firing line of very powerful opponents, to keep the rest of us safe for the future, weather we completely buy into the open argument or not.

2 Comments

  1. Interesting post.

    Just to clarify my view – as it currently stands any company can reverse engineer an API for reasons of interoperability. Hence when trying to make a market of providers in the IaaS space with semantic interoperability between providers, I strongly support adoption where there is clearly a dominant API.

    It should be noted that such a market can have multiple open source and proprietary implementations around the API. However, running code through an open source effort is necessary to form a market place without a single (or consortium of) vendor(s) being able to force a tax on that market. In other words, providers need to have an operational means of implementing the service and compete in the market without a necessity to purchase software licenses (a tax on competition). They may choose to buy software to do so but a free market is one unencumbered by such forced taxation.

    This is why I do no support MSFT Azure’s effort, despite the provision of open standards because there exist no open source implementation.

    This is why I did not support Google’s AppEngine, despite the provision of an SDK as there existed no fully operational open source means of implementing the service.

    This is why I strongly support open source efforts which reverse engineer the dominant API for reasons of interoperability e.g. open stack, eucalyptus etc.

    It is also why I strongly support open source efforts which attempt to create the dominant standard in a fledgling market, such as CloudFoundry in the PaaS arena.

    Once the marketplace of alternative providers is large enough and it has the dominant ecosystem then the open source effort in effect becomes the defacto standard for implementation and the API in that market. If necessary, due to abuse of position by the original provider, then the API can be differentiated away from the original provider including providing an entirely new API where applicable.

    I don’t find attempts to differentiate on API in a utility world where one API is clearly dominant meaningful.

    I find re-inventing the wheel by creating an API by committee and attempting to get the market to adopt as a wasted effort when a market has in principle chosen.

    I do find the way to standardise is through creating the largest ecosystem and in such cases both reverse engineering the dominant API for reasons of interoperability combined with provision of open source running code is necessary.

    Co-opt rather than compete is the order of the day in this world.

Leave a Reply