What you don’t know about working with AWS

August 27, 2021 was my last day at Amazon Web Services (AWS). I spent two years there where he led the company's open source marketing and strategy team for most of the time. While it's intended to help the world better understand AWS's open source efforts, the reality is that most of the time is spent within AWS, where product teams understand the relevant open sources on which their services depend.

We've helped them understand why and how to contribute to the source upstream. The rest is spent outside the company, working with open source companies such as Confluent and Databricks to strengthen his AWS partnerships with these companies.  

Oh, and by the way, I helped put out the dumpster fire that occurred when AWS gave open source companies and communities the impression that they were doing something "bad". 

In my experience, much of the anger directed at AWS about open source misses the point. No, AWS remains one of the world's largest contributors to open source projects, but we're not perfect. (Whether you're measuring active contributor numbers or code, you can see the data yourself by running this code.)  

Rather, it is almost always a mistake to see AWS as a monolithic entity with a common open source approach. This is one of the main myths about AWS that is misleading, but there are others that I will attempt to address here. It's no secret that I write here, but Amazon seems to hide everything in plain sight.  

Two-pizza teams

Amazon founder and former CEO Jeff Bezos introduced the "two pizza rule" early in the company's history. "We're trying to put together teams that aren't big enough to fill you up on two pizzas." Teams tend to be relatively small and, just as importantly, almost entirely autonomous.  

What do you mean? While it may be true that service team X does not currently contribute to open source projects, that doesn't mean the same is true for other service teams (200+ teams). For example, the ElastiCache team employs him as one of Redis' five maintainers. Other teams have made significant contributions to Rust, Apache Lucene, Kubernetes, OpenTelemetry, etcd, Apache Iceberg, OpenJDK, GraphQL, and more.  

Are there service teams that haven't yet partnered with open source upstream? Of course, same with Microsoft, Google, Alibaba, and others. But I have seen this change while working at AWS. This is a really slow process, as Amazon rarely works top-down. If you want Amazon to contribute more, you need to focus on individual teams and, just as importantly, speak Amazonian.  

Yes, those LPs are real

“Speaking the Amazon Way” refers to the language and thought processes embedded in the company's 16 Leadership Principles (LP). Before I joined his AWS, I thought LP had to be kitsch slogans at best and chauvinism at worst, but with over a million Amazon employees talking and collaborating with each other. It turns out that it provides a common framework for They permeate virtually every discussion at AWS, including the famous “six-pager” used to express ideas and determine operational plans.  

When I first came to AWS, I avoided using LP in discussions. It didn't work. “You should contribute to Project X because it's the right thing to do!” Blank stares. "We need to give our engineers more time to contribute to Project Y so they can influence the direction of the project." I got nowhere.  

But then when I tried to frame my case in LP, things got much better. I find it difficult to be 'customer-obsessed' and 'frugal' to deliver innovation without earning 'trust' from the communities we rely on by building code. Our contributions also put us in a better position to 'deliver results' and support our clients, so we can 'claim the highest standards'. " 

Suddenly people understood what I meant. It wasn't tight before. Rather, I needed to speak the language that laid down the principles governing everything that happens on AWS (and Amazon, really). If you want to change the behavior in AWS, you should use LP to formulate the desired outcome. My team has grown accustomed to it and is paying off by being more and more involved in the projects that our service team depends on. 

The spirit is willing

During my time at AWS, I have never heard anyone underestimate the importance of open source. But on the contrary. I know it's fun to satirize AWS as a bunch of evil minions bent on open source strip mining, but I've never met anyone who fits that description. If you have a disagreement with the general manager of the services team or others about the relative importance of open source to their business, the disagreement was about which LP was most important in a particular situation. There was a tendency to be 

For example, "Customer Obsession" comes first for all Amazonians, but is read differently. While you may think that open source contributions are essential to customer obsession in the medium to long term, general managers of services teams should also consider the short term. This means you can create a private her branch of your code so your company can quickly fix bugs or deliver customer-requested features. And while all customers seem to love and want open source, it is also true that many value the operationalization of that code even more (as Tim Bray pointed out years ago). what you did). 

This means that ensuring a seamless customer experience in the short term can drain engineers who might otherwise contribute to the long-term success of a given project. has seen this change improve on AWS, but again, in a company with two pizza teams, there is no one-size-fits-all approach to open source. 

Also, LPs such as "own", "invent and simplify", "claim the highest standards", and "deliver results" are not the same as the desire to work well with commercial managers of open source projects. It can also mean seemingly incompatible. If a customer wants Apache Kafka to be easy to use, the short answer is to build a service that can be managed on their behalf, with as few moving parts and opportunities for error as possible. Another answer is to work with partners to ensure a seamless customer experience. AWS may have been easier to ship with the first option in the past, but I'm encouraged by all the success I've seen with his Confluent (for Kafka) and other open source companies.  

AWS still has a long way to go in this area and others, but we all do. One of the things I've loved most about his 20+ years about open source is how much we as an industry (and as individuals and companies) have to learn after years of trial and error. . No one has cracked the code of the perfect way to build and run an open source project or business. We are all still learning.  

So let's be patient with each other and try to understand why individuals or companies work the way I've tried here for AWS.