Why does AWS contribute to open source? The Firecracker example

Open source has long lived by the credo that “Every good work of software starts by scratching a developer’s personal itch.” At AWS, however, we’re not content with simply writing good software: we write software to meet customer needs. Over 90% of what we build is driven by customer demand, and the rest comes from intuiting customer needs and innovating on their behalf. This holds true in open source, and means that we’re very deliberate in how and where we invest in open source, as the Firecracker example helps illustrate.

Why Firecracker?

AWS has driven the cloud market in response to customer desires to stop managing servers and instead buy infrastructure as a service. More recently, to further this customer value, we innovated the concept of serverless, freeing customers from having to provision their infrastructure while providing greater security. As Amazon CTO Werner Vogels recently wrote,

[W]e anticipate that there will soon be a whole generation of developers who have never touched a server and only write business logic. The reason is simple. Whether you’re building net new applications or migrating legacy, using serverless primitives for compute, data, and integration enables you to benefit from the most agility that the cloud has to offer.

Firecracker is one way to help enable this customer innovation. Prior to Firecracker, customers told us that existing container security boundaries didn’t offer sufficient isolation between their applications when all containers must use a shared operating system kernel. We set out to work on Firecracker to offer best-in-class security as well as improve the performance and resource efficiency of customers’ container applications.

Open sourcing Firecracker made strong customer sense for at least two reasons.

First, when innovating on behalf of our customers in the context of open-source technology like Linux, it’s much easier to do this if we, too, are open. The Linux kernel runs inside Firecracker. To ensure this continues to work well for customers, we needed Linux kernel developers to have full visibility into how Firecracker works, including the special virtual devices it provides, and its somewhat unique environment (e.g., no BIOS, no ACPI tables, special “keyboard” with only one button). Making Firecracker open source reduces friction when submitting patches, among other benefits. It’s good for community and good for customers.

Second, in our quest for increasing the velocity of innovation for our customers, we believed open source gave us a more efficient way to collaborate with our community and realize compounded product gains from customer contributions over time. No, I don’t believe open source always accomplishes this. But in the case of Firecracker, and the need to fill a big void in the container ecosystem, open source was deemed our best way to meet customer needs.

More to come

Open source has always been a critical part of AWS’ strategy. Indeed, as longtime open source advocate (and senior AWS engineer) Wilson stresses, AWS has long been “a natural place to build and run open source software.” This started with Amazon.com, AWS’ customer zero. As Wilson puts it, “You could say that the shape of the first services that AWS launched back in 2006 was deeply formed from Amazon’s own experience building with open source software. Which is why open source worked so well in the cloud: the cloud was built for running it!”

Say that again? “AWS has been a huge boost for free and open source software, making it possible for many companies and communities to exist that invest in open source.” I definitely saw this through a variety of open source companies for which I’ve worked since 2002, companies like MongoDB, Alfresco, and Nodeable that ran some or all of their business on AWS.

And going forward?

In serving AWS customers, open source will play an increasingly large role. As AWS open source chief Adrian Cockcroft suggests, “Customers use more open source and care more about contributions now than they did a few years ago, which is the underlying reason why AWS is building more open source based products and contributing more now.” No, we will not engage in open source to score brownie points with analysts or pundits. As Wilson summarizes, “[T]he foundation of the case to open source [Firecracker wa]s because it ultimately benefits our customers.”

That is the constituency we focus on serving. And that is why you can expect more, not less, open source from AWS. Not because it’s popular but because it increasingly helps AWS to serve our customers.

To learn more about Firecracker, please see the launch announcement, as well as the more recent Firecracker open source update. Interested? Please contributing by submitting a pull request on GitHub.