The Open Source Buyer’s Guide

It’s safe to say that open source software (OSS) is not a fad. In fact, it’s safe to assume that every large organization in the world is running at least some open source software (from Linux at the OS level up to React at the UI level)—and nearly every individual in the world is consuming the fruits of open source every time they access Facebook, Twitter, Google, Amazon, Netflix, or any other popular web or mobile application. 

From operating systems to web servers, databases, programming languages, containers/container orchestration, search engines, you name it—if there’s a need for it, there’s an open source project dedicated to it. For some things, OSS is the de facto option, if not the only realistic one. And then there’s the talent issue: Companies that use OSS and contribute to open source projects have an easier time finding, hiring, and retaining qualified engineers.

However, with this popularity comes a new set of concerns for enterprise IT executives and other decision-makers. Two big ones are:

1. When and which open source project(s)/technologies to choose.

2. Whether to use community-supported upstream code (aka do-it-yourself open source) or commercial open source products and/or support. 

Both of these concerns fall into the category of problems that are good to have—multiple viable options are hallmarks of a thriving space—but can also complicate the process of selecting the right technology.

This guide will help you ask the right questions when choosing open source projects and/or commercial offerings. While there might not be right and wrong answers per se, an organization’s or team’s specific circumstances can certainly affect the success of particular choices.

Choosing the right project for the job

While choice is a good problem to have, sometimes it looks more like an actual problem. Too many choices can lead to exceedingly long bake-offs and feature comparisons between seemingly similar options. Or to developers choosing hot new technologies that interest them right now but might create problems—like snowflake architectures—later on. We don’t need to look any further than the database market and its panoply of OSS options to see what an abundance of choice looks like. 

When it comes to the right open source tool for the job, four criteria can go a long way toward helping you make the right choice:

1. Internal considerations

2. Community dynamics

3. Project governance

4. Vendor options

Let’s walk through them.

Internal considerations

A good starting point for choosing OSS is to do an internal audit of what your organization or team is already using. If you’re using a technology that’s under consideration for your new project, it might make sense to stick with it. There’s presumably some in-house expertise around running it in production, and its use might have already been cleared by the legal department. In cases where all else is equal between two options, or where you only need some basic functionality, the prospect of avoiding these headaches might be the tie-breaking factor.

Auditing current OSS usage could also help identify potential compatibility issues with the options under consideration. If, for example, other critical services are using Apache Kafka, selecting an alternative messaging system could introduce undue complexity should they need to share data.

Of course, no discussion of technology choice would be complete without considering the requirements of the application in question. There might be technical or regulatory requirements that eliminate certain options from the start. Or perhaps an application is too important to risk by selecting a promising but still young open source project; it requires a project with demonstrated longevity. On the other hand, it might be worth experimenting with greenfield applications that are designed for modularity but aren’t (yet) mission-critical. 

Community dynamics

Indeed, it’s often the community behind any given open source project that determines its sustainability and pace of innovation. However, assessing the state of an open source community involves more than just looking at how many contributors or commits it has—and certainly more than merely counting GitHub stars.

Here’s a list of questions that will help you assess the overall health of any open source project:

• How old is the project? The longer a project has been around, theoretically, the more stable you can expect its output and processes to be.

• Do releases come out at a predicted pace? Or are they random, seemingly triggered by a sudden surge of maintainer interest? And how quickly does the project release patches for security vulnerabilities? Predictability can be a major benefit in enterprise environments.

• Do pull requests and issues languish? If a project’s maintainers don’t actively engage with users suggesting improvements, it could be a sign that they’re not fully committed to the project’s success. Or perhaps that they’re simply committed to their own agenda.

• Does the project enjoy robust documentation, are commits commented, and is the changelog up to date? Clear documentation and explanations of what’s new in a given release are critical to usability, and are a sign that the project’s leadership is serious about growing the user base.

• Who is the contributor base? How many people does it comprise (and what is the project’s “bus factor”)? Do they all work for the same company? How long have they been involved? All of these questions are designed to assess the risk of a project going dormant should its primary contributors and/or maintainers decide to leave. Looking at contributors’ employers can also be telling. A massive-scale database project backed mostly by Facebook or Google engineers, for example, might not prioritize the needs of users in more regulated, smaller-scale, or otherwise “mainstream” industries.

• What are its contribution guidelines? Is there a clearly documented contribution process and information about who makes decisions and how code is accepted? At some point, you'll probably want to reduce your technical debt by contributing your changes back upstream, and it can help to understand whether and/or how your changes are likely to be accepted.

• What’s the project’s history when it comes to accepting contributions from newcomers? Is it known for treating community members with respect? OSS projects, like other communities, can can be full of politics, infighting, and occasional discrimination, so it’s important to choose one to which employees will feel comfortable contributing. The project's code of conduct and/or its contribution guidelines can be great places to start—and if the project doesn't have one, ask why or suggest they adopt one.

These questions can also go a long way toward answering what might be the single most important question in OSS: How much work is your organization or team willing to put into supporting the project? Because if the technology fit is spot-on but the community dynamics are lagging, your team might need to take on a leadership role to get things in order, get your contributions accepted and/or issues addressed, and keep the project thriving for the foreseeable future.

Project governance

Some open source projects with active communities are managed by neutral foundations (often non-profit) with no commercial interest in them. These can be general-purpose foundations that host dozens or hundreds of projects (e.g., the Apache Software Foundation and the Linux Foundation) or project-specific foundations (e.g., the .NET Foundation and the Python Software Foundation). Generally speaking, these organizations provide neutral governance structures, mandate certain standard OSS licenses, and encourage contribution processes designed to nurture healthy communities. 

An important distinguishing feature of the best open source foundations is neutral governance structures, which provide a level playing field where contributors from any organization can come together as equals to collaborate.

For projects governed by a foundation like those described, the community-centric questions outlined above should serve as a great starting point. After all, although open source foundations—and the projects they host—can vary in significant ways, they typically share at least a desire to grow the community of users and contributors in the name of advancing the project(s) while providing opportunities for contributors from a wide variety of organizations. 

That said, much OSS today comes from software vendors or other commercial entities (e.g., Facebook with React or Netflix with Chaos Monkey) that maintain control over the code. These types of projects often still solicit and accept community contributions (or at least bug reports)—but they are different from community-led projects. The controlling organization truly controls the project and can represent a single point of failure (or success). There is also the risk that the controlling company may take the project in a direction that diverges from what the community and the users expect or need from it. (Although popular technologies are sometimes forked or otherwise rescued after their controlling companies fail, change course, or otherwise lose interest in maintaining them.)

There are some additional questions worth asking—including of the managing organization—before choosing an open source technology that’s controlled by a single organization:

• What is the organization’s reputation and/or experience in managing OSS projects? Some organizations are great stewards of OSS, while others have a reputation for killing projects or throwing them over the wall and forgetting about them. 

• What is the organization’s financial health? This is especially important for companies where the OSS is the business, but also for larger companies managing multiple open source projects that require ongoing funding to maintain.

• What type of license does the project use? Over the past few years, several prominent open source vendors have amended their licenses to prevent certain types of competitive threats (mostly from cloud providers). These changes might trigger issues with your legal department, even if they don’t limit how you plan to use the software.

Vendor activity and options

Although OSS is technically free in many cases, the myth that it doesn’t cost anything to run OSS has been firmly dispelled. Installation, management, integration with other systems, the building of required functionality, and any number of other tasks all require engineering work. In essence, then, using upstream OSS shifts the burden from capex to opex, which—depending on the project and the scale and complexity of the system—is not always a feasible tradeoff for companies not named Google or Netflix.

Thus, most successful open source projects have at least one vendor, if not a marketplace of vendors, selling commercial distributions and/or support (mostly to enterprise customers). Those vendors can be broken down into four general types:

• Established/large software vendors. These vendors typically have a track record of delivering enterprise-grade software and support, although you’ll want to vet them carefully with regard to OSS. Inquire as to how active they are within the community and how many commitors are on staff, how closely their distributions track community releases in terms of cadence and code parity, and what “enterprise” features they have incorporated.

• Late-stage startups/pre-IPO software vendors. These vendors were early to commercializing the project and can be a safe bet, although their expertise is often limited to the technology at hand. In certain cases, they will employ at least one of the creators of the project (possibly as a founder) or will own the project outright. Although operating profits might be a ways off, vendors of this type tend to be well-funded via venture capital.

• Early-stage startups. For relatively new open source projects, the vendor community might consist only of early-stage startups trying to bring attention to themselves and a new technology. The companies’ founders are almost certainly the projects’ creators or key contributors. These vendors can struggle to support enterprise customers for any number of reasons—mostly relating to size and inexperience—and are often less financially stable than larger vendors, but can be worth working with for lower-risk applications.

• Cloud providers. Cloud providers are rarely the only option for commercial access to OSS software. Rather, they tend to enter markets with existing successful vendors, relying on ease of adoption (via a managed service) to attract users. Their offerings generally try to compete with vendors specializing in a particular open source technology on price and accessibility, rather than on features.

Having more options isn’t necessarily better, but—especially for a community- or foundation-managed (i.e., not vendor-led) project—an abundance of choice does suggest a healthy and widely used project. Choice also helps mitigate vendor lock-in, assuming the vendors in question aren’t deviating too far from a project’s upstream codebase. Most commercial products will include some unique features, dependencies, and integrations, but ideally a customer can swap these with other options should it decide to use another distribution.

To build, or to buy, that is the question

Once you’ve done your due diligence and chosen an open source technology, the next decision is whether to use a free, community-supported version or a commercial distribution (or pay for enterprise support). It’s not a choice between free and expensive, but rather a choice between how and where you want to spend your time and money—on managing software or building applications. 

“At the end of the day, most businesses are not in the business of maintaining or developing software, and therefore they need help with that …You're going to have to pay for software to be developed, and software to be supported and serviced over time, one way or another."

—Stephen O’Grady, RedMonk (on “Cloud Native in 15 Minutes”)

The nice thing about OSS is that these choices aren’t mutually exclusive. The same team could reasonably opt for different approaches at different levels of its technology stack, or even for different components of the same application. With that in mind, here are some factors to consider as you weigh the options:

• How important is the application? The relative importance factor might sway your decision in either direction, depending on what kind of team you have in place and the technology in question. It’s really a matter of how reliable or secure (or whatever else) the application needs to be, and whether you trust your team or a vendor to deliver on those requirements.

• What does your IT staff look like? Although OSS usability has improved drastically over the past decade, installing, supporting, troubleshooting, and integrating it with existing systems can still be a major undertaking—especially for an infrastructure-level technology such as Kubernetes. Doing so might take a team of skilled engineers dedicated to that task for as long as the system is in place.

• How unique is your use case? Adopting and highly customizing—or even building your own—OSS can make a lot of sense if you’re dealing with significant edge cases (e.g., around scale, custom integrations, or reliability) à la Google, Netflix, or Facebook. Otherwise, the community-driven development of open source projects combined with vendors’ knowledge of customer requirements means a commercial version will probably cover your needs.

• How much technical debt can you tolerate? Open source deployments that drift away from community source code can lead to heavy technical debt when it’s time to re-architect an application or system. Becoming an active contributor and getting your improvements merged into the community codebase or choosing a commercial distribution that includes required features and tracks with community releases, can help reduce this debt.

• How much are you willing to change? While free OSS can add flexibility to your application development and operations efforts, it comes with some unwritten best practices that can be difficult to sustain while focusing on improving applications from a business perspective. They include keeping up with CVEs, patches, and long-term support windows, as well as active community engagement (including employing project committers) to influence a project’s direction—table stakes for software vendors.

• What’s normal in your industry? Consider what’s standard operating procedure in your industry, and how adhering to it with regard to OSS will affect your business. In some industries, investing too heavily in commercial distributions while everyone else is going the DIY route might make hiring more difficult. In others, however, spending time and money reinventing the wheel while your competitors are moving along with app modernization might pose its own issues.

At the end of the day, the decision to use open source software is a decision to improve your organization. From the bottom of the stack to the top, OSS can increase flexibility, reduce lock-in, and power both innovation and digital differentiation. You just need to ensure you’re spending your time and money in the right places.

Read more

What Enterprises Need to Consider When Adopting Open Source

How to Engage With Open Source: A Strategic Approach

Open Source @ VMware

What to Expect From an Open Source Project

The Upside-Down Economics of Building Your Own Platform

The Total Economic Impact of VMware Tanzu Application Service