Africa Studio - stock.adobe.com
Executive interview: Putting a value on open source
Spotify’s open source tech lead discusses why open source is failing those whose free time is dedicated to maintaining code
Per Ploug, open source tech lead at Spotify, has worked in open source for many years and, having watched its evolution, he believes that companies are now far more aware about “open source” actually means. “I think they’re clearer on the cost side and also on what it means to adopt open source in more strategic ways,” he says.
Open source avoids so-called “vendor lock-in”, where end user organisations are tied into complex commercial software contracts. The rate of their IT architecture decision change is often dictated by the supplier of this software. But, while open source does not have the same level of lock-in, the flexibility it offers can be a double-edged sword for a lot of companies. “I think open source gives you access to technology you wouldn’t have the capabilities of developing yourself,” he says.
This means organisations can take a leap into an area of technology where they may lack sufficient know-how. In doing so, the user of the open source software is tied to the technology innovations they deploy.
“When you make these bigger investment choices, I think everyone needs to understand whether what they are adopting is something that’s close to being a common standard in a given area, or whether they are basically creating a dependency on something which is losing market share and possibly also mind share.”
Choosing the latter will result in the organisation having to move away from this open source tool at some point, which can be very costly.
He says that if open source did not exist, the big technology firms would monopolise technology to serve particular niches of customers. Such technologies would likely be very expensive, which would make them only suitable for the bigger enterprises. “Smaller companies would not be able to afford these kinds of things,” says Ploug.
For instance, Spotify began using open source from the very start, and this has allowed it to grow. “When we were tiny, we used open source as a quick leap into markets, and I think we have developed a strategic approach to open source above everything else,” he says.
Making strategic open source choices
At Spotify, developers can pick and choose from a wide variety of libraries based on their own choices. But for bigger strategic investments, Ploug says Spotify will assess open source technology rigorously if it will become a standard that the business can depend on for a longer period of time, to ensure it is not prematurely forced to move away to a newer technology.
One example, which he says, with hindsight, is quite amusing, is: “On the day before Kubernetes was released, we open sourced our own container orchestration layer.”
A more positive project for Spotify is Backstage, which Ploug says it has made open source, as a way of creating a common standard. Backstage is an open source framework for building developer portals, created at Spotify, which it donated to the CNCF. It has now been adopted by hundreds of companies.
“We didn’t want to just wait and see and keep it internal,” he says. “We wanted to drive innovation in the space of developer portals.”
In doing so, Spotify Backstage has become the market leader. The company continues to invest internally but, by donating it to the CNCF, Ploug says Spotify also ensures it will “stay around”, which gives internal users the confidence to carry on using it.
Financial sustainability
Ploug believes the idea of having confidence that an open source product has longevity goes to the heart of the problem currently facing the open source community. “We have an enormous financial sustainability problem in open source,” he says. “I think a large number of open source maintainers are underpaid or underappreciated. They are also stressed about the rising demands on open source maintenance that we are seeing.”
Organisations using open source code need to understand the implications. “You don’t have a service level agreement with this provider,” says Ploug. “It’s not a vendor. You’re not paying the person who maintains the code. There’s no supplier relationship [contract].”
Read more executive interviews
- We speak to Expedia’s head of IT architecture about what a modern, scalable architecture for the cloud should look like.
- Audi is transforming IT in line with digitisation across the VW Group. We look at how Audi’s IT architecture is supporting developers.
The lack of a service level agreement has a material impact on the effectiveness of industry-wide initiatives to improve open source security.
“I think a lot of the problem comes from lack of maintenance,” he says. “This is because maintainers simply don’t have the time or they’re not paid for their work and are running these projects in evenings and weekends.”
As a result, Ploug does not believe the concept of a software security supply chain can work in open source. Since the maintainers are not being paid, they are not a supplier. “You don’t have a supply chain,” he says.
It’s still not a common practice for companies to support projects financially, and Ploug would like to see more organisations which use open source offering financial support for open source projects.
Widening the talent pool
Given that only certain people are able to give up their time to maintain open source projects, he worries that this limits the community to a very particular demographic.
“It’s a very specific kind of person who has a passion to spend evenings and weekends working on open source,” says Ploug. “That’s someone who has no household chores, no kids to maintain, no family life, no sick relatives.”
He says open source needs to become more of a level playing field that is able to attract a diverse community of contributors and maintainers. This is also linked to the financial problem, and the industry and policy makers’ ambitions to put in place software security supply chains.
If maintainers and open source contributors are paid and projects are sponsored, people are more likely to see their role in the open source community as a vocation. And the contract they have with users of the code they develop and maintain is financially binding, which gives those users a service level agreement and accountability.
Listen to the podcast here >>
