Open source: Why it's time to be more open about how projects are run
Open Source
It used to be that key technology came from commercial companies like IBM and Microsoft and Sun. Even when Linux started to be a significant part of IT infrastructure, businesses got it from commercial companies like Red Hat, along with an enterprise-support licence. But the rise of open source means that some of the key pieces of technology that businesses and consumers alike rely on don't have a commercial business behind them.
That doesn't just mean the lack of a price tag or the ability to look at the code, which is by no means a guarantee of quality or security. It means that the organisations behind key technologies aren't businesses; they're more often communities. They don't always have the resources to maintain code that people rely on.
The Heartbleed vulnerability was caused by a bug that had been in OpenSSL since 2012; the small group of people that maintain OpenSSL also had to fit in contracting work to earn a living because the industry that used their code wasn't supporting them. As Jim Zemlin, executive director of the Linux Foundation joked at this year's Open Source Leadership Summit, "that was when we discovered the internet was secured by two guys named Steve".
SEE: How to find files in Linux with grep: 10 examples (free PDF)
Some projects have had industry involvement for years and the pattern of key developers on an open source project working for a company that sells a supported enterprise version or cloud service of that project is common. Many key open source projects are part of foundations that provide support, from the Apache Foundation to the Cloud Native Computing Foundation; others have their own foundation, like .NET.
But many projects have little formal support; including a long list of open source tools that a lot of other projects depend on, all the way down to the developer of a widely used package called left-pad deciding to pull all 250 of their packages from NPM after a dispute about the name of one package, breaking React, Babel and other package that relied on them.
The Core Infrastructure Initiative support from the Linux Foundation that was started in the wake of Heartbleed provides support for under-resourced projects that everyone depends on. Better security scanning can help with malicious code like the backdoored containers that were removed from Docker Hub recently.
But when there isn't a formal structure like a company or a foundation, there can be problems beyond code having bugs or not being securely hosted. The standards of behaviour in open source communities can vary widely, and that has an impact on who's involved and contributing to them.
Building a community
What does the leadership of a company or a community do when the behaviour of one contributor makes colleagues uncomfortable or unwilling to work with them? A business has a clear structure for dealing with this, from the rules in its employee handbook to its HR department to and a legal team to evaluate if the terms of employment contracts that allow them to dismiss people have been broken. A community might have a code of conduct and a committee or working group that considers complaints against that code of conduct, but codes of conduct -- and particularly the enforcement of them -- aren't uniform.
Even multiple resignations from a project over disagreements don't end the project; having a fork of a project doesn't make the code any less useful. But at the very least it's disruptive (leaving aside the contributions lost when people won't join a project whose ethical values don't fit theirs). In the longer term, as we rely more and more on tools that are created as open source, we need to be thinking about more robust processes and procedures and organizations to support those tools.
GitHub isn't the only home of open source, and it's not only used for open source, but the fact that it was worth an Instagram (or half a LinkedIn) to Microsoft says a lot about the prominence of open source among Microsoft's enterprise customers (as well as Microsoft's own involvement in open source). There was plenty of technical discussion at this year's Open Source Leadership Summit, but there was also a clear focus on the professionalism of open source in ways that appeal to enterprises; getting licencing right, getting company contributions back to open source projects right, and getting the business model of open source projects that have commercial aspects right.
SEE: 20 quick tips to make Linux networking easier (free PDF)
Kubernetes came up repeatedly at the summit as an example of an open source project that's putting professional, decent behaviour to contributors at the top of the agenda. Working out what values the project stands by has taken conscious effort as it shifted from being a Google project to a community one, Chen Goldberg, Google's engineering director for containers and Kubernetes said at the summit, but it's important: "People who want to join the community need to know what we work by."
"We grew so quickly that we didn't know what we needed," said Sarah Novotny, who leads Google's Kubernetes Community Program. What's emerged is a way of valuing contributions that aren't just code. Individuals in the Kubernetes community can distinguish themselves by contributions but "companies can distinguish themselves by chopping wood, carrying water and doing the unglamorous heavy lifting."
That's why Microsoft's Brendan Burns (cofounder of the Kubernetes project) was handing out awards to the Azure Kubernetes Service team earlier this year like the "on-call Hall of Fame" and the "chop wood and carry water" award (which he 3D-printed and spray-painted silver). "Chopping wood and carrying water is a metaphor for doing the hard background that isn't glamorous but keeps everything running. The award is to recognize the people who keep us going every day but who might not be building the flashy features."
IT teams will make decisions about what open source projects to use for technical reasons, but having good governance and a healthy community is what keeps a project thriving in the long term. As Chef's Nell Shamrell-Harrington put it at the summit, "technical and communications skills are intertwined and continuously needed in every project. The parts of open source that touch both technology and humanity are the hardest and most vital."