Every so often, the open source community gets into an argument about what the software we create should really be called. Recently, for example, I’ve been seeing people using the term “Enterprise Open Source.” In response, I want to make two observations—one that questions the utility of that particular term and a second that suggests these debates over wording distract us from something far more important.
On its face, “Enterprise Open Source” sounds like a useful modification of “open source.” It appears to acknowledge that almost all enterprise software now includes significant open source elements and that open source solutions now dominate a number of crucial areas of enterprise technology (the rise of containers being a good example).
But the term also conflates two things that we should be careful to recognize as very distinct. On the one hand, there is software generated and curated by a broad community of developers, many of them professional developers working for enterprise-oriented suppliers. On the other, there’s the software that is used to run an enterprise.
When the two are used interchangeably, it’s possible to make claims about “Enterprise Open Source” that sound impressive but tell us very little. Figures suggesting massive adoption of “Enterprise Open Source,” for example, aren’t helpful if they don’t map to a clear definition of what that means.
Does running “Enterprise Open Source” mean taking a Git clone from upstream, then simply compiling it to run your own applications? It can’t, because no one actually does that. Does it mean that every single part of your software stack is open source? That’s pretty rare, so your numbers would be pretty low. Or will having some open source components in your software, which just about every enterprise now has, be enough for it to count? In that case, your numbers will be correspondingly high.
Unsurprisingly, we’re seeing instances where multiple definitions of “Enterprise Open Source” are used within the same article. While that might serve the particular ends of the authors, it further complicates the situation and makes it harder to give actionable information to the people who really need it.
So, do we just need a better—and better defined—new term? For me, the answer is a clear “no.”
We have a far more important task at hand, one that gets to the heart of why VMware actively participates in the open source community and why we have open source components in all of our products.
Open source software is important because it helps everyone in our industry accelerate innovation. It lets us help our customers innovate, harness rapidly developing technologies and build consensus around, and quasi-standards for, APIs that can benefit every player in their specific ecosystems.
Rather than getting hung up on dogmas or definitions, we simply aim to develop combinations of open source and commercial software that will make our customers as productive and successful as possible at enterprise scale.
The message we hear from our customers is very clear. They want to use the APIs and the technologies that are being created in open source communities. But that’s because these technologies will help them succeed at scale, not (typically) because they are developed in a particular fashion.
To put it another way, our customers care about business outcomes, not the labels we put upon the software that gets them there. And VMware is committed to helping each of them find the most reliable, scalable solution that fits their needs.
Our message in return to our customers is equally clear: we are deeply engaged in open source and we will work with you to create the solutions that you need. Don’t get distracted or let yourself be confused. Instead, keep working with your partners to understand what you need to do for your business to thrive, then focus 100% on putting that in place.
For more on VMware’s investment in and pursuit of open source, read Darren Hart’s blog “Why We Do Open Source” and “We Before Me” by Malini Bhandaru.
