We used to be able to count on a steady blaze of open source dumpster fires raging in the corner of downtown Seattle where Amazon Web Services (AWS) is headquartered.
But not recently. There’s been a curious lack of drama for the company once castigated for “strip mining” open source.
Though such accusations tended to be not a little self-serving, there was fire to accompany the smoke: It was true that different teams within AWS were not as thoughtful as they should have been about contributing back to the communities upon which they depended for code, even as it was also true that those communities sometimes didn’t want any contributions back — except cash.
Fast forward to 2022 and there hasn’t been an open source controversy at AWS in recent memory. Why? Though I’d agree with Duckbill Chief Economist and man-about-AWS-town Corey Quinn’s assessment that AWS still has progress to make with open source, there’s also a fair amount of unseen progress that is shaping AWS into a more productive member of a variety of open source communities.
The glass half empty
First, a disclaimer. I used to manage AWS’ open source strategy and marketing (OSSM) team, which initially meant trying to highlight AWS’ few open source successes to cast the company in a positive light for developers. We soon recognised that the best way to create a positive open source reputation for the company was to enable service (product) teams to more actively contribute.
And they have.
Quinn isn’t wrong when he argues that “compared to many of its large tech company peers, Amazon has historically struggled with its relationship to open source.”
He’s also not wrong to suggest that AWS has relatively few community-driven projects and that the company is somewhat missing in action when it comes to big industry projects like Kubernetes (not coincidentally created by Google, which has several such large, industry-moving projects to its name).
But he’s arguably wrong, at least directionally, in criticising AWS for trying “to shape a narrative where they’re contributing to the open source ecosystem at a level that’s on par with its big tech company peers.”
I say “directionally wrong” because this feels like precisely where AWS is headed. I saw clear signs of it before I left, and I see even more now, which is one reason there haven’t been any dumpster fires smouldering in Seattle lately.
The glass half full
Take the acceptance of a non-AWS maintainer for its open source fork of Elasticsearch, OpenSearch. It’s very easy to dismiss this as table stakes and significantly less than what one has come to expect from, say, Google (though possibly on par with Microsoft, which tends to have a lot of employees active in open source but doesn’t have many industry-shaping projects of its own — that is almost uniquely a Google thing).
But for those of us who lived through some internal battles related to OpenSearch and third-party commit rights/maintainership, it’s a really big deal. I can comment on those fights because they played out in public.
Unconvinced? From conversations I’ve had with AWS folks, however small the success people outside the company may see in OpenSearch, inside the company it has freed up teams to think very differently about how they may launch open source projects or contribute to existing ones.
This too may seem small, but former AWS developer Dave Cuthbert puts it in perspective: “In my early years there (say, 2005-2010), contributing upstream [to open source projects] was an internal battle. Getting signoff took >12 months, and then you had to do it stealthily (from a private account). It took a concerted internal effort to change minds.”
It has taken years—more than a decade, really—to help teams see the Amazon Leadership Principles as enabling them to contribute more to open source (to better obsess over customers, deliver results, hire and develop the best, insist on the highest standards, demonstrate frugality, and show broad responsibility to the communities upon which they depend).
Previously, many teams thought these same LPs militated against open source contributions because how could they take ownership to deliver results, etc. if they were dependent on an outside community?
But it is happening. Sure, AWS teams or employees continue to make mistakes in how they engage with these communities and yes, more is needed. But that’s confusing the destination with the direction, and from my vantage point, the direction is good.
Given a relative lack of recent dumpster fires when they used to feel like an inferno, I’d argue that I’m not alone in feeling that AWS is making progress. This is the company that fought with Elastic, but it has been an increasingly solid partner to open technology companies such as Grafana Labs, Confluent, and my own employer, MongoDB (lots and lots of skirmishing years ago has become lots of partnering today).
Today AWS is the company that has one of five maintainers for Redis, that has been active in OpenTelemetry and related projects, and more.
Analyst Sarbjeet Johal is almost certainly correct to suggest that AWS has done this out of necessity, not some 501(c)3 charitable impulse. But if I were to reframe that a bit, I’d say that AWS increasingly comprehends “customer obsession” as necessitating more open source involvement, not less.
Quinn isn’t wrong that the company continues to punch below its weight relative to, say, Google, in its open source involvement. But directionally, it feels AWS is heading down the right road.