AWS’ open source director on how to win and maintain trust

With AWS handing its OpenSearch fork of Elasticsearch to The Linux Foundation, the company’s director of open source reflects on shifting sands in the ecosystem

David Nally Aws

Until recently, the open source community and big tech were mostly at odds. Today, this couldn’t be further from the truth: the biggest tech firms now make, maintain and fund much of the open-source ecosystem. Nevertheless, conflicts do still occur.

One such conflict found a resolution at the Open Source Summit in Vienna this September. Cloud giant Amazon Web Services handed its Opensearch “fork” of back-end analytics engine Elasticsearch to the Linux Foundation, the non-profit that promotes and governs open source projects.

In software, a fork is where an existing project diverges from its original codebase and thus its governance changes. Handing over Opensearch meant that a project which had been largely controlled by AWS – even though it was open source – was now vendor-neutral.

A fork in the road

This matters, particularly in the highly intricate world of open source software partnerships. In the case of Elasticsearch, disagreements bubbled to the surface in 2021 when the original founders of the codebase, Elastic, shifted the software’s license from Apache 2.0 to something called Server Side Public License – meaning the project was no longer truly open source. This shift was a result of Elastic’s mounting irritation over a perceived capture and subsequent monetising of Elasticsearch by AWS for its Amazon Elasticsearch Service, supposedly without giving much back to the codebase or maintenance.

Whatever the motivations for the move, AWS felt strongly enough to take action. “Having that codebase be open source was important to us and to our customers so we took the extraordinary step of creating the fork,” says David Nalley, director of open source strategy at AWS. 

The fork was a success, quickly shooting into the top 50 database engines where it now sits in 33rd place. “We’ve been acting, in the intervening three years, as the steward for the project,” Nalley says.

However, many still have reservations about any single firm having such strong ties to particular projects. Nalley heard from AWS customers that having one vendor so close to Opensearch had impacted the health of the project, hence the decision to transfer the project to the Linux Foundation. 

“Customers and partners wanted vendor-neutral, independent governance,” Nalley says. 

“We’re hearing from a lot of customers who perceive extra risk when a single vendor dominates or controls an open source project. A number of our customers said to us: we’ve got patches for Opensearch, but our company has a policy against contributing that code unless it’s at a vendor-neutral place.”

Stick a fork in it

This AWS example is one of many. Open source software forks, following changes to licensing, are increasingly receiving backing from hyperscalers and major tech companies.

Amazon, Oracle and Microsoft have all decided to back Valkey, the open source alternative to data store Redis. Valkey is now also hosted by the Linux Foundation and is, by some accounts, already outpacing the original codebase.

It’s a similar story for OpenTofu – forked from HashiCorp’s infrastructure-as-code tool, Terraform – which, following a change in licensing, saw major commercial entities start to back the open source alternative, leading to a very public spat.

Detractors suggest these open source forks are a consolidation of big tech’s power on the open source ecosystem or, more simply, are economically driven decisions to avoid paying licences.

But, says Nalley, this model (where a fork is hosted by a foundation, such as the Linux Foundation) can help organisations reduce their risk profiles when consuming open source projects, especially around single-vendor control. “I think this is going to increasingly become a factor for companies who are consuming open source software,” says Nalley. “It’s one of many things we assess when we’re going to take a dependency on an open source project.

“Folks have been saying there’s decreased trust when a single vendor can arbitrarily make decisions about the future of an open source project,” Nalley adds, “whether that’s the technical direction or the licensing or whether to continue working in the project at all. I think that will drive a lot of attention to open source foundations. Whether it will mean a lot more software moves to foundations, I don’t know.”

Winning and maintaining trust in open source

A quick peek at the Open Source Contributor Index, which ranks commercial entities by their total contributions to open source projects, reveals a lot of activity from huge players such as AWS, Google, Microsoft, Intel, Huawei, IBM and Nvidia. This, of course, is nothing new. Many of these organisations have a long history of involvement with open source.

But if customers are demanding the kind of vendor-neutral governance that foundation models can provide, how can businesses win and maintain the trust of the broader open source community – a community that, even with the significant contributions of big tech to it, maintains a healthy scepticism towards corporations on its peripheries?

There are no shortcuts, says Nalley: “A lot of it comes down to proving over time that you’re making the investments necessary to help sustain open source.”

“The Cloud Native Computing Foundation talks a lot about ‘chopping wood and carrying water’,” Nalley adds, referring to the Zen Buddhist proverb about everyday tasks remaining the same whether you have found enlightenment or not. In this case, the wood and water in question are release management, writing code and fixing bugs. He points to projects such as open source relational database PostgreSQL as evidence of this, where AWS is the top reviewer of code.

If businesses wish to really demonstrate their commitment to open source, suggests Nalley, perhaps they should contribute to ecosystems where they don’t currently have any products.

For AWS, one such project is the emergent programming language Rust, with its own dedicated team solely working on the project.

“We’re doing that because, just like everyone else, we need a more performant, more stable Rust programming language,” he says, “and a set of tools like the compiler and standard library that are easily consumable and will work for folks.”

Demonstrating commitment through contributions and maintenance, especially with no obvious dog in the fight, can be valuable for companies seeking to win and maintain that trust.

But trust is “somewhat transitive,” warns Nalley, “meaning you can earn it in one place and maybe you have enough reputation that it carries over in other places. But a lot of the time you’ve got to put in that work everywhere.”