2nd April 2015

When Appium was founded, we decided to reuse the Selenium JSON-wire protocol for several reasons; the most important being that we didn’t want to lock people into our tool. By choosing an existing (pending) W3C standard, we were able to reuse the existing language bindings maintained primarily by the Selenium project. These bindings were already written which helped us support every language from day 1 and they already had thorough testing and CI, which greatly reduced the amount of testing we would need to do. This decision also allowed us to bring in other JSON-wire compatible projects, which we did when we introduced Selendroid integration for legacy Android device support.

On the flipside, I’ve also made decisions to ignore standards. This is because there are many problems with standards as well. Some are laughably absurd. (see ISO 29119 or JSONx by IBM) Frequently, the bodies behind these standards move very slowly; e.g. the WebDriver W3C spec has been in review for several years already. Forcing software companies to adopt standards needs to come from the customers and not from the standards bodies themselves. When bodies try to coerce software companies into their standard they face huge obstacles. Many companies see little benefit. Imagine you are Internet Explorer in 2000 and you control over 80 percent of the market. Why should you implement the W3C standards? You control most of the browser and thus that makes you the de-facto arbiter of the standard. It behooved a website operator to have their website implement Microsoft’s empirical definition of HTML4 and not the one from the W3C, so that more than 80% of their customers will have a good experience rather than the minority.

This all changes when customers understand what they are getting out of it. Companies are beholden to their customers. Customers need to understand the benefits and tradeoffs associated with standards and pressure the companies accordingly. As a software test manager, the benefits or adopting standards are plentiful. Standards reduce the amount of testing you are required to do on your product. You can scope your testing down to largely implementing the standard properly. When you are testing your standard, you also have other products which you can use as an oracle for your testing and you can reuse any testing infrastructure (test cases, unit tests, etc.) that the project makes available. As a software user, being locked into a single provider or implementation is highly undesirable as you are completely at their mercy. When using a standard, many parties are typically consulted before changes, giving you time to adapt to the change and multiple representatives to voice and debate the potential impact of the change.

There are many things I would love to see head towards standardisation and others I would not. (coughs:: ISO 29119) The trend towards using cloud providers to host websites is largely a move in the right direction. Why should every company need to have security and scalability experts on every kind of service on their website? Why not let your hosting provider provider handle that? The bad side to all of this that with all of these freebies like security and scalability, Amazon, Microsoft, Google, and friends are largely locking people into their APIs. Converting a website from Azure to Google App Engine approaches a complete rewrite. While, combining services from one provider to another can sometimes be possible (i.e. you can sync your Active Directory accounts over LDAP to Google App Engine), as a software company it would be an amazing benefit if to have the flexibility to pick and choose components from all providers. Having some kind of standard here would more aggressively encourage competition amongst providers to be the best at each type of service and consumers would win. In this case, customers wouldn’t need to weigh the pros and cons of the Azure suite versus Amazon or App Engine, but could vote with their wallets towards the best services from each. Customers could switch later down the line if they had problems?

I’m curious to hear what other people would and would not like to see standardised.



About Dan Cuellar
Dan Cuellar is the creator of the open source mobile automation framework Appium, and Head of Software Testing at FoodIt. Previously, he headed the test organisation at Zoosk in San Francisco, and worked as a software engineer on Microsoft Outlook for Mac, and other products in the Microsoft Office suite. He is an advocate of open source technologies and technical software testing. He earned a Bachelor’s degree in Computer Science, with a minor in Music Technology, from the world-renowned School of Computer Science at Carnegie Mellon University in Pittsburgh.

No Comments

Leave a comment