Why Amazon's customer obsession should make it more open source friendly

It's increasingly clear AWS is customer-obsessed. Find out why this same customer focus should change how Amazon Web Services interacts with open source projects.

Image: Ben Fox Rubin/CNET

The scariest thing about AWS for its competitors is that the cloud leader is telling the truth. What truth? That AWS isn't fixated on competitors, but rather with meeting customer needs. As AWS chief Andy Jassy said at AWS re:Invent last week, speaking of the company's new on-premises tech Outposts: "I don't see Outposts as a shot across the bow of anyone. If you look at what we are doing, it's very much informed by customers."

Customers. That word comes out of Jassy's mouth a lot, used to justify building all sorts of things, like Outposts, that the company once eschewed. It's what makes AWS so hard to predict, as I've written, but in my talks with AWS, its customers, and its partners at re:Invent, it's clear that "customer obsession" is truly what makes AWS tick. That obsession should lead AWS to get even more serious about the open source projects it increasingly turns into services.

SEE: Vendor comparison: Microsoft Azure, Amazon AWS, and Google Cloud (Tech Pro Research)

A cliche by any other name...

Every company claims to be customer-centric. Only Apple founder Steve Jobs could brazenly say, "People don't know what they want until you show it to them. That's why I never rely on market research." His was the gift of intuition. Most companies simply can't pull this off.

While AWS certainly follows the other part of that Jobs quote ("Our job is to figure out what [customers are] going to want before they do"), in multiple conversations around re:Invent, it was surprising how often the customer was invoked as the source of this or that product direction. From the mainstage on Wednesday morning Jassy identified a variety of ways that AWS engages with its customers to determine what to build, including deep engagement between AWS product teams and existing and future customers. When I asked its customers and partners whether this rang true with them, I invariably heard a resounding "yes."

More interesting was AWS' stance toward would-be competitors.

Take Instaclustr, for example. The company runs managed services for Apache Cassandra, Apache Kafka, Elasticsearch, and other open source technologies, helping companies to run at massive scale. For two of those services, AWS is a director competitor, even though Instaclustr runs these services on AWS. This seems like a recipe for conflict, but when I spoke with Instaclustr CEO Peter Nichol, he told me that of the various cloud providers, AWS is actually the easiest and best to work with. In part this is because AWS' processes and services are so much more feature-rich and established, but it's also because AWS is focused on customers' needs. As Nichol expressed it, AWS sales reps won't push Instaclustr customers away from the company's managed Cassandra service to AWS' DynamoDB. The focus is on what the customer needs, not what the vendor needs.

SEE: Amazon Web Services: An insider's guide (free PDF) (TechRepublic)

In other cases the customer may not know exactly what she needs. In a conversation with Herain Oberoi, AWS general manager of database, analytics, and blockchain marketing, he talked about how the company came up with the its Managed Blockchain and QLDB products. In announcing the new services, Jassy had stressed that AWS spent a great deal of time trying to find the signal in all the blockchain noise, noting, "We don't build things for optics." Just because there was hype about blockchain didn't mean there was real customer demand.

Because "AWS development teams are very close to customers," as Oberoi informed me, they were able to probe customer demand ("We want blockchain") to decipher what that demand actually meant in practice. For some, it meant blockchain, but more easily managed. Enter Managed Blockchain. But for others, what they really wanted was "a way to have a transparent and verifiable way to manage transactions." They didn't need blockchain--they needed something more like QLDB, an internal database that AWS determined to externalize for customer needs.

For Capital One vice president of cloud strategy Bernard Golden, one major takeaway from re:Invent is just how much this customer obsession is pulling AWS into solving enterprise needs. Not that this always makes AWS friends.

Not making friends

Given that most of today's most popular enterprise data infrastructure is open source, it makes sense that AWS would start investing in making things like Kafka easier for enterprise consumption. In the rush to meet enterprise demands, AWS should spend more time ensuring the health of the open source communities from which it draws code.

No, I'm not suggesting that AWS should be doling out cash to the open source companies that have emerged to provide enterprise support for things like Kafka and MySQL. It's not AWS' fault that these companies are often hoping to monetize modern open source projects using antiquated software revenue models. Nor is it AWS' job to prop them up with cash. Any open source project that is overly dependent on a single company rather than a varied community shouldn't expect AWS or anyone else to bail them out of their poor open source practices.

SEE: At AWS re:Invent, Amazon gets its gun: 'Everything the tech sector does, we can do better (ZDNet)

Rather, AWS should be thinking seriously about how to replenish communities. Long term, this is in AWS' self interest. A Kafka service today, for example, is only as interesting as the underlying project's evolution. If that evolution is stunted because of a lack of community investment, AWS will fail to meet customer needs. And so AWS needs to go from the industry's most prolific harvester of open source code and become the industry's most careful nurturer of open source communities. (No, this will not satisfy the single-vendor projects that don't really want code, as they hope to be the single dominant source of code for their projects. But those projects have problems AWS needn't bother trying to resolve.)

Why should AWS care? Hortonworks' Steve Loughran has highlighted some solid reasons. for the health of the project, he reasons, it "miss[es] out on any fixes [AWS] teams find, any features, and [AWS doesn't] help with the test phase of any release to show that it works on AWS infrastructure, OS images, etc." And what about AWS and its customers? "They lose the ability to patch their own artifacts, to add features to [products like] EMR, even to easily debug why something is failing." As such, customers end up being the guinea pigs for whether AWS services are keeping pace with the industry.

SEE: AWS re:Invent 2018: A guide for tech and business pros (free PDF) (TechRepublic)

This isn't a great customer experience.

Fortunately, there are signs this is beginning. AWS hired Adrian Cockcroft to help the company get serious about open source, and it's starting to show fruit in things like Firecracker. Firecracker is a great example of AWS open sourcing technology that will take the industry forward in virtualization, but even more may be needed in terms of AWS contributing code to the projects it's turning into services for customers. Again, this is the best way for AWS to truly deliver on its customer-centric obsession.

Also see