Sauce Labs coding lead: how open source contribution should work

Sauce Labs’ head of open source Isaac Murchie talks to Computer Weekly Open Source Insider to deconstruct open source and ask what happens next in terms of what matters, examine who is (and isn’t) contributing and question which myths we should dispel with.

Sauce Labs is known for its Continuous Testing (CT) technology and the company is a devoted adherent to open source — it provides a continuous testing cloud that allows developers to verify that their web and mobile native apps work correctly across a variety of devices using the open source testing protocols Selenium and Appium.  

Computer Weekly OSI: What concerns you most in open source today?

Murchie: The biggest issue that the open source community should keep an eye on in the years ahead is the tendency of companies to use open source systems but not contribute to them. At Sauce Labs, we know that the open source ecosystem can only survive if people give back. If maintenance and development is ignored, software systems will falter and fade.

Computer Weekly OSI: Why are some individuals failing to contribute to open source?

Murchie: There are legitimate reasons, such as they might work leveraging existing closed-source technology, or it being key to a company’s market distinction. But for the most part it seems to be a misguided idea of controlling and securing the code. In this mindset, any work that has been done is proprietary and potentially makes money, so it should not be disclosed to ‘competitors’.

While this is bad for the ecosystem outside the company, as the work has to get repeated, it is also bad internally, since it makes upgrading difficult. If work has been done to patch and fix a particular version, as things change in the open source system the code that is fixed internally can diverge… and the company becomes locked into the particular version they got working. If the changes were contributed back to the project then any subsequent work would have been done with that code in it.

Computer Weekly OSI: How can firms support and encourage their developers to contribute to open source?

Murchie: By allowing them the time, or financially, to allow projects to pay developers, or to pay for services needed to maintain good software (continuous integration services, for instance). It can also mean legal support, to allow employees to navigate the contributor licensing agreements that many projects have. It can also be moral support, acknowledging that the work is significant and valued.

Computer Weekly OSI: Which open source myths do you want to dispel?

Murchie: I would say that the largest myth is that contributing back to the community gives up some purported competitive advantage. On the lower end of the scale this is ridiculous. If a company’s competitive advantage lies in the fact that they have fixed a bug in an open source system they use, then their advantage is tenuous at best. The excuse is just covering over an unwillingness to go through the corporate legal hoops to get permission, at that point, and, as I said before, will bite back when the underlying system is changed.

In larger scale work, the competitive advantage argument may make more sense. However, if used as a blanket excuse to not allow any open source work it covers work that could easily, and fruitfully, be contributed back to the public. In particular, work that is used by customers and users will often be helped by their having access to the code. Not only do they tend to fix problems, but studies have shown that the code becomes more secure. In addition, we have found that users will, given the code, make use of it in novel and exciting ways, actually helping them use our system.

Computer Weekly OSI: How much of the success in open source do you think hinges on contributors/maintainers upkeeping existing projects vs. companies releasing proprietary code or new projects to open source?

Murchie: I think both are necessary. Old projects are inevitably the building blocks of new ones… and as such need to be maintained. This becomes more true the more ‘basic’ the projects are… libraries and frameworks are the ones that get depended on, while application software tends to change as user needs change. That is not to say that newer ways of doing something, no matter how basic, should not supplant an old way, as technologies and approaches evolve. New projects, on the other hand, drive the adoption and utility of open source in general.

Open source democracy

As an end note here, Sauce Labs says it’s also about culture and the firm insists that contributions comes all the way from Charles Ramsay, the CEO, down.

Murchie has said that this also highlights that open source is not just about lines of code. Every expertise that is useful within a company is also useful in the open source community.

Sauce Labs’ Murchie: Let’s all tune in, contribute and play nice now please.