The Open Source Market’s in Flux. How Can IT Managers Cope?
PARIS — When the Cloud Native Computing Foundation announced new corporate support for FluxCD at KubeCon + CloudNativeCon Europe last month, it seemed to illustrate just what the cloud native community could achieve when it put its mind to it.
Just over a month after Weaveworks, the firm where FluxCD was developed and its main sponsor, announced it was ceasing commercial operations, major users of the GitOps tool affirmed their support and pledged continuing contributions, with key maintainers finding new berths, including ControlPlane.
But, happy ending notwithstanding, CNCF’s efforts also highlighted the potential risks users face when open source projects are hit by the unexpected. And the last year has seen lots of the unexpected.
Enthusiastic backers of open source, such as Weaveworks, have suffered a harsher business climate. Others have seen investors switch their attention to, well, AI. And ostensibly open source companies have changed licenses, as in the case of Redis, Buoyant, or HashiCorp.
Any or all of these scenarios can throw a question mark over the future of a project. So, how does an open source program office head or engineering manager navigate this? And what can the open source community do to help users and maintainers?
Open source program managers in end-user organizations have traditionally focused on issues such as licensing, compliance, and security, Chris Aniszczyk, COO at the CNCF, told The New Stack.
But, he said, it’s increasingly clear that this isn’t enough to gauge the sustainability of projects or the risk they represent. And it says nothing about the possibility of the rug being pulled from a project, whether because a project has become unsustainable or because a commercial organization decides to change the license.
He cited a recent conversation with the head of open source at a bank, who said that “single vendor open source now is basically a risk factor.” That doesn’t mean such projects should be avoided completely, but a lack of diversity amongst maintainers will be another flag that open leaders and developers will consider.
How the CNCF Preserves User Choice
In the same vein, the governance of a project becomes important. If a project is hosted by a foundation, Aniszczyk argued, the maintainer base is usually more diverse, and the license rests with the foundation.
“None of the essentially rug-pulling type thing is possible in foundation land,” he said. Foundations act as a referee, he added, ensuring a level playing field.
It’s significant, Aniszczyk noted, that CNCF supports multiple projects in the same area, which helps preserve user choice.
While the CNCF moved swiftly on resolving the Flux situation, Aniszczyk said the organization didn’t have a formal process for managing such situations.
However, there is a CNCF process to archive a project that has become unhealthy, he said. He cited the example of RKT. The container runtime engine had been donated to the CNCF by CoreOS back in 2017. But following CoreOS’s acquisition by Red Hat in 2017, it seemed the project was being deprioritized by its new owner.
“What eventually was noticed by the community was RKT was not doing releases and responding to security issues,” Aniszczyk said. “Huge red flag.”
The CNCF opened a “public issue” and worked with the RKT team, he said. The technical oversight committee “came to a conclusion that this project is really unhealthy, and there’s no way to really fix it, no one wanted to really step in to do it. And so, we archived it, and it was our first archived project.”
In the case of Cortex, Aniszczyk said, the outcome was very different. Grafana decided to switch resources, leaving the project, a time-series database monitoring tool, exposed. Again, a public issue was opened, but in this case “AWS and Red Hat stepped up and kept the project going.”
As for FluxCD, he said, there was already “some diversity in the project.”
Weaveworks CEO Alexis Richardson came to the CNCF to explain his company’s business situation, but also to ensure “that Flux remains vibrant and healthy,” he told The New Stack a few weeks before KubeCon. He also sought to discover if the broader CNCF ecosystem wanted to employ the project’s maintainers.
“GitLab also made a public statement that Flux was super important, they were gonna have maintainers there,” Richardson said. “So the vacuum kind of got filled very, very quickly.”
Is it time for a more formal approach to handling these situations? The CNCF has made refinements to its process, Aniszczyk said: “Our technical board will open up a health check and invite commentary from the community.”
Then, “we’ll surface it to our board and basically say, ‘Hey, anyone want to chip in?’”
There are limits to this approach, he added. “I can’t go like, ‘Hey Oracle, you need to go hire 10 maintainers.’”
It would be hard to predict whether a company was going to shut down at the end of the year, he said. But it could create tools that flag projects with fewer or a decreasing number of maintainers.
The CNCF and The Linux Foundation are building internal tools internally to make these metrics “a little bit more available,” he added.
What’s Your Risk Management Strategy?
Turnover of maintainers can be a good thing in itself. This is something users should watch out for, Richardson suggested, but not necessarily because it’s a bad sign.
“One thing that’s a sign of a healthy project and open source is you can see the processes, the way that it works, the way the users use it to represent a certain kind of mature practice,” he said. “Which means that people can come in and people can go without the whole thing falling apart.”
The fact is, for some project founders, the fun can go out of projects over time, Richardson said. “What the CNCF cannot do on its own is act as a sort of guarantor that a project remains useful forever, or that individual humans will work on a project forever because naturally things do change.”
When it comes to best practices for ensuring projects remain sustainable and stable, he said, “I think if it’s in a foundation, it’s better than not being in a foundation.”
For one thing, this means a commercial organization can’t do a license bait-and-switch. Moreover, he said, a foundation like the CNCF will have rules, and practices governance and security best practices, which “means that the software is probably a lot safer than betting on commercial projects.”
But it’s also worthwhile examining the business models of major backers of a project, Richardson said. Being over-reliant on a small number of large customers could represent a “concentration risk,” which in turn might make venture capital investors nervous and likely to pull the plug.
“If you wanted to have a second best-practice rule,” he said, “It is, can you prove that you’ve got customers coming from free to your paid products, or from your main open source projects that you’re supporting onto your paid?”
He also suggests considering who will support the product in three years if it requires a patch. “Because you don’t want it to be a nutcase,” he said, meaning a person who is drawn only to shiny, new things. “Because I can promise you that person, in three years, will be doing another project.”
“If you’re an IT risk manager and you’re thinking about procurement issues, you should be saying, ‘What’s my risk management strategy? I have all my eggs in one basket.’ If I do that, that may be OK. But that means it might require me to, let’s say, have more active risk management.”
Ultimately, risk management will be a challenge for any engineering leader. “Commercial companies and software fail all the time,” Richardson noted. But The New Stack doesn’t publish articles about them, “because it’s just the normal course of business.”
As for Flux, Richardson said, “The great thing here is that Flux is now in use by so many companies and embedded in so many big vendors … It’s not going to go away at all. And so it’s going to be absolutely fine.”
