What is enterprise open source?

We already know what open source is, right? There’s a great deal written about open source from just about every angle, even a handy definition of what constitutes open source, but what about enterprise open source? While not necessarily exhaustive, here’s what we’re talking about when we say “enterprise open source.”

First and foremost, it is open source. A product isn’t “enterprise open source” simply because it integrates a single permissively licensed open source library or “works with” or “runs on” open source.

Tested and “hardened” for enterprise use

Anybody can download and install an open source project or compile it and ship it as-is from the upstream repository. That doesn’t really add any value to the project, though, and can carry risk.

To be what we’d call enterprise open source, a product requires testing, performance tuning, and be proactively examined for security flaws. It needs to have a security team that stands behind it, and processes for responding to new security vulnerabilities and notifying users about security issues and how to remediate them.

If you’re on your own when it comes to quality and security issues, it’s not enterprise open source.

Enterprise Features

The needs of larger companies and organizations, which we’re going to just put into the “enterprise” category for convenience sake, vary quite a bit from smaller organizations and home users.

For example, a smaller business or home user probably doesn’t care about things like single sign-on (SSO) and integration with SSO platforms and directory management, or calendaring platforms, and the like. OK, I know some fairly techy people who’ve over-engineered their home setup - but for the most part, you don’t run into these requirements until an organization is large enough to justify their setup.

Smaller shops also don’t usually need to deal with the same level of auditing requirements, or federating services across multiple data centers and/or public clouds. Enterprise customers need to worry about much larger capacity data storage requirements, as well as more complexity and a need for disaster recovery that goes well beyond small and mid-sized businesses needs.

Or if you look at something like Java, there’s Java as a core language, and then there’s Enterprise Java, which includes APIs and application servers to make developing “enterprise scale” software simpler and more maintainable over the long term. When you need to take thousands of concurrent users into account, for example, you’re thinking of enterprise software - and enterprise open source. That’s on the feature side, but let’s also talk about the long term that I just referenced.

Predictable and long lifecycle

Enterprise IT environments require a lot of investment and planning, and it can be an exciting area to work in if you like learning new things and working with technology. But the point of that technology is to support other people doing their jobs. People who, by and large, do not like having to suddenly re-learn how to use a system or having an application go sideways because an update renders it (or its underlying components) unusable.

Most of the applications that we depend on for work are a complex stack that rests on robust hardware, a stable operating system, one or more programming languages, a handful of libraries or frameworks perhaps, a database as well as in-house code, configurations, and user data.

If a piece of that stack is updated so that it’s incompatible with the layer above or below, it can compromise the entire application. Try to throw an operating system on a newer, untested, layer of hardware and you might find that networking fails because it lacks drivers. Or maybe it has trouble with storage or a graphics card.

Or what if the OS updates and brings in an updated OpenSSL library or version of Python that isn’t compatible with your application?

Enterprise open source has a predictable lifecycle that’s stated up front, with information about components that may move at different speeds. Moreover, the product has a lifespan that’s suitable for business to deploy important applications. In the case of the operating system, for example, a major version of Red Hat Enterprise Linux has a lifecycle of 10 years.

An enterprise software vendor like Red Hat may also take on the heavy lifting of supporting components well after the upstream project has moved on to newer versions. This is necessary to let customers use software on a timeframe that makes sense to enterprise-sized organizations.

The upstream may have ceased backporting security fixes to a version for years while we continue to do that work so our users don’t have to refactor apps or perform major upgrades on mission-critical software.

Certifications

Along with a lifecycle that aligns with enterprise requirements, enterprise open source is also characterized by certifications.

You want to pick hardware that works with the operating system and applications that you are deploying. That’s why we work with a number of hardware partners to certify RHEL on those platforms and to enable features like GPU passthrough for Red Hat OpenShift and Red Hat OpenStack Platform.

And for products like Red Hat Enterprise Linux and Red Hat OpenStack Platform. You can choose these platforms to run workloads important to your business, including those offered by ISVs. Or maybe you are an ISV and want to tell your customers that your products will run as expected on RHEL or Red Hat OpenStack Platform.

Part of the beauty of open source is having choice. You have access to the source code and can combine projects any way you see fit, so long as you can get them to work together. But greater choice and variety are frustrating to operations teams that have to support systems in production, and anathema to infosec teams who need to know what’s running in their environment and when security vulnerabilities might affect them.

That’s why we have certification programs, to work with ISVs to certify their products so that their customers can deploy with confidence on our platforms. By definition, enterprise open source narrows choices somewhat, but it also focuses on supportable configurations that offer the features important to mission-critical applications.

Service Level Agreements and support

Of course, a certification by itself is not terribly useful without someone to stand behind it and support it when something breaks.

Enterprise open source means having vendors that offer support and Service Level Agreements (SLAs) that spell out what is supported and how quickly you should receive a response and remediation for the issue.

Support goes beyond that, of course. It also encompasses a lot of work and material to help customers succeed in deploying and managing software. Documentation, knowledgebase articles and forums, and some environments may also need assistance from a Technical Account Manager (TAM) who focuses on that account to be able to identify potential problems before they occur.

TAMs are highly technical, product specialists who help our customers plan deployments, patching plans, and more.

Training

Since we’re on the topic, training and product/topic certifications are another hallmark of how we define enterprise open source. In the early days of Linux, organizations had a heck of a time filtering out qualified system administrators from applicants who considered themselves Linux experts after a successful install of Slackware.

Training and certification programs are not trivial to put together or maintain. It also requires a level of maturity for a technology to be suitable for training and certification, not to mention suitable for mission-critical workloads and long term support.

Integration

Another characteristic of enterprise open source is integration. As one of my colleagues would say, upstream communities are great at generating the “pieces parts” of solutions. When you want an innovative web server, the open source community has several on offer. When you want a robust database or framework, no problem. Messaging bus, data streaming platform, distributed storage, and so forth - open source projects abound that offer these solutions.

But you want them all to work together? For day two operations and beyond? For years? Well. That’s when you move into enterprise open source territory.

Projects vs. Products

Another way of identifying enterprise open source is asking whether you’re looking at a project or a product.

Open source projects are offered in various levels of polish to their user and contributor community. Some, like Fedora, are offered with more polish for a large community of users and can work right out of the box. Others are a bit more on the DIY side and might require you to compile them or gather a number of other components to get going.

Projects generally don’t have staff or employees; they have contributors who may be working on the technology full time and paid by a vendor (like Red Hat) to focus on the project. Or contributions may come from folks who work with the technology as part of their day job and they want to maintain and enhance it for future use.

Few projects have folks paid to look after release management, documentation, or other areas that you’d expect for a product. Those that do often have them, like Fedora, are because a vendor has decided to support the project in the interest of a product. Projects, at least what we consider to be healthy ones, have governance that isn’t fully controlled by a single entity.

People outside the sponsoring company can get involved and affect change and direction of the project, at least within the parameters of the project’s mission. (No matter how passionate or committed, you’re probably not going to persuade the Fedora Project to abandon x86-64 and focus on TRS-80s and retro computing.)

Products generally have the characteristics I’ve already set out - predictable lifecycle, support, certifications, training, an ISV ecosystem perhaps, and are controlled by a single entity responding to what the market wants and is willing to pay for. Features and roadmaps are planned in response to what customers need and are asking for, not merely what people are willing to show up and work on in a project.

Works together

Open source projects and enterprise open source products are not the same thing, but they’re not at odds, either. The work that goes into enterprise open source products, when things are working well, feeds back into open source projects to help benefit anyone using that project - not just the paid users and vendors.

Ideally, enterprise open source combines the best of two worlds -- the advantages of open source with the stability, performance, support and ecosystem that is offered by enterprise software.