First, AWS wasn’t contributing enough code. Now that it is, only cash seems to matter.
Image: boygovideo, Getty Images/iStockphoto
AWS used to get criticized for “strip-mining” open source projects, turning them into profitable cloud services without contributing commensurate value back to the open source projects in question. With the launch of its Open Distro for Elasticsearch, AWS is getting criticized for (wait for it!) contributing commensurate value back to the open source project, Elasticsearch. To those that claim AWS isn’t giving “commensurate value,” well, that may not be for lack of trying.
AWS open source chief Adrian Cockcroft, for example, opened up on AWS’ efforts to contribute to Elasticsearch: “We proposed to give back jointly at a significant level and were turned down.” This is the bizarre new reality of open source and AWS: When it contributes nothing back, it is “strip-mining”—when it does it’s…kneecapping competitors? The truth is somewhere in the between these two extremes, and may well result in healthier open source projects.
SEE: Amazon Web Services: An insider’s guide (free PDF) (TechRepublic)
Getting better at sharing
Whatever one’s thoughts on AWS and its open source activities of the past, it’s hard to argue that AWS hasn’t been improving with time. Indeed, as Fil Maj captures in his analysis of corporate open source contributions on GitHub, Amazon now sits among the world’s most active companies on GitHub (Figure A).
Image: Fil Maj
Granted, if we measure Amazon’s contributors as a percentage of employees (0.07%) or engineers (0.45%), it pales in comparison to its peers (Microsoft, Google) or smaller competitors like Elastic NV. Even so, the fact that we see Amazon make the top 10 at all is progress, given that last year it didn’t. As Cockcroft has outlined in a blog post, “Over the years, customer usage and dependencies on open source technologies have been steadily increasing; this is why we’ve long been committed to open source, and our pace of contributions to open source projects—both our own and others’—continues to accelerate.”
SEE: Open source vs. proprietary software: A look at the pros and cons (Tech Pro Research)
Implicit and explicit in Cockcroft’s statement is the reality that AWS depends upon healthy open source communities. To those that think AWS takes without giving back, think for a millisecond about how short-sighted such an approach would be. AWS cannot afford to spend tens (hundreds?) of millions of dollars spinning up a new service only to see the underlying open source project die (and kill off the service along with it). “Oh, but AWS can just fork the project.” Sure, but that’s not what customers want.
The other thing customers demand, Cockcroft says, is continuity:
[C]ustomers must be able to trust that open source projects stay open. The maintainers of open source projects have the responsibility of keeping the source destination open to everyone and not changing the rules midstream. When important open source projects that AWS and our customers depend on begin restricting access, changing licensing terms, or intermingling open source and proprietary software, we will invest to sustain the open source project and community.
This is a somewhat self-serving dig against Elastic NV and other open source companies that fuel development through proprietary extensions. Those companies use proprietary code so that they can get paid (and, in turn, write more open source software). Speaking of Elasticsearch, in particular, Elastic NV’s Philipp Krenn has stressed, “[W]hat we have seen in terms of contributions from AWS in the past was minimal at best.”
But what if AWS is actively trying to change this? Some point out that Elasticsearch has been in desperate need of some baseline functionality (like security). But others, including some at Elastic NV, argue that it’s doubtful that AWS will be able to contribute as much to Elasticsearch code as Elastic NV has, given its focus on that project. It’s a valid concern.
What if code isn’t enough?
Code or cash?
Kyle Mitchell, for example, worries that a dose of code doesn’t compensate for a potential loss of focused investment in a project: “Money and code are highly interrelated. Software companies are engines that burn lots of money, turn out code, and exhaust drama. Elastic NV is a high-performance machine for turning out Elastic code.” Some have called it a fork, while others go so far as to call it a “hostile takeover.”
Even if we don’t accept this doomsday perspective, does AWS moving into the neighborhood of Elastic NV (or any company built up around one open source project) immediately handicap that company (and the project it supports)? That’s the real question at issue. Mitchell certainly believes so: “The more of the code they turn out that’s open source, and not on the market, the less well they can do in the market….[Hence] I expect Elastic NV will allocate more of its development time to closed functionality as a result of this. Overall loss.”
But need this be true?
After all, if we take the financial fortunes of any particular company out of the equation, isn’t open source better off with a community, rather than a company, behind it? Indeed, isn’t open source better when there are many conflicting companies trying to make a buck by giving code to the project? This is what makes Kubernetes, Linux, and other projects flourish. It’s not the absence of corporate self-interest that powers them, but it’s also not the corporate self-interest of one company. No, the best open source projects harness the power of a multitude of complementary and competitive self-interests.
It’s too early to proclaim doom or nirvana for Elasticsearch based on AWS’ increased contributions. It’s very possible that AWS’ increased involvement will spark community interest in contributing to Elasticsearch which, in turn, may hurt Elastic NV. Some suggest this is bad, as outlined above, but community-driven open source seems much healthier than company-driven open source.