I know, paying for software is so antiquated.
Let’s face it - a significant number of software engineers simply “google” for products that fit their problem, download them, incorporate them into their product and move on. And, surprisingly, a large number of Enterprise software developers do the same thing.
So, if the “free” community product fits the need what is wrong with that? First, nothing is wrong with using the “free” community open source software. In some cases, there is no commercial counterpart. However, using any software without understanding the longterm supportability is quite risky, particularly if you have a long time horizon and run mission-critical systems with the software. Enterprise organizations build systems that must be supported for years and, therefore, are particularly vulnerable to selecting components that may not be viable in the future. Additionally, outages in many Enterprise systems can result in material business losses and therefore product stability is critical.
This blog is intended to help you understand commercially supported open source software so you can build an Enterprise open source strategy that allows your organization to successfully deliver stability, security, and supportability to your customers over an extended time horizon. In some cases, the result of analysis is to continue using free, community software but in some cases it may prove more prudent and cost effective to purchase subscription support from an Enterprise open source vendor.
Note: We’ve even seem a few Enterprise customers buy a subscription for their open source software but only pay for a small number of installations to save money (which violates their contracts with the vendor). IANAL, but don’t do this :).
A solid open source strategy really requires a more complex and nuanced understanding of the difference between an open source product that is availabile in the community and an enterprise supported version of the product. I can’t tell you how many times I’ve worked with customers who didn’t even know that there was a commercially supported version available of a product they were already using.
First, let’s talk about how open source software is commercialized - most vendors actually have two versions of their open source software - Community and Enterprise.
Both versions - community and enterprise-supported - are open source, but they do have very different product lifecycles and expectations for support. Community projects are supported by the community and do not have SLAs regarding support or any guarantee that defects will be resolved. This is by design - not all community features make it to the supported product and the community product favors frequency of release and newness of features over stability. This process is instrumental in influencing what features should make it into the supported Enterprise product.
Don’t get me wrong - if your organization has the time, skills, and money to both deliver your product on the community bits of popular open source projects and troubleshoot issues in the community project/product then you should do it!
However, the reality of many customers, especially Enterprise customers, is that they want to find the most cost effective solution for running their systems but they really don’t want to invest in learning the product codebase, fixing defects, and validating the security/stability/performance. They would much rather spend their time delivering value to their customers - in the form of a stable system and updates to their own product. The mission of Enterprise open source vendors is to support these customers.
The best example of the difference between Community and Enterprise open source is Red Hat’s Fedora distribution and Red Hat Enterprise Linux (RHEL) distribution. Many users from across the world use Fedora on a daily basis - on their desktop and in their internal environments - for free. Of course, the vast majority of enterprise customers run their commercial systems on RHEL, not on Feodra. RHEL is a stable release with well-defined upgrade timelines, hardware/software certifications and support SLAs. In order to gain access to RHEL and receive support - the the organization must pay a subscription to Red Hat that is based on the number of cores used (physical or virtual). The subscription provides access to all supported versions of the software (backward and forward) available.
The benefits to this proces for the vendor is that they can have their software in the hands of users earlier through the community software process in order to vet features and to support community interests in newer technology. Once the community features are deemed ready for release in the Enterprise product, an Enterprise branch is prepared and certified on specific hardware and software platforms. Defects are resolved in the relevant projects that comprise the product and the vendor can then provide longterm support for the Enterprise product.
The advantage to the community is that they get feature-rich software that is “free” and ready to use. And the advantage to the subscriber? Well, they get Enterprise bits that are certified for their environment and assurance that if any defects are discovered, they will be resolved in a timely manner via the SLA described in the subscription terms. The subscriber also benefits from the predictable support timeline and can prepare their future upgrades and product development lifecycle with assurance that the underlying components will be supported for many years.
In the Red Hat middleware product stack, the JBoss Enterprise Application Platform has a similar lifecycle: Wildfly (formerly JBoss AS) is the community version and EAP is the Enteprise-supported version.
The following diagram depicts an example of the hardening process that the JBoss Application Server undergoes (now called Wildfly) to achieve Enterprise support (known as Enterprise Application Platform).
As you can see from the diagram, there are versions of the community product that never get commercialized (dead branches) and others that form the basis of the Enterprise grade product. For a large Enterprise customer, the stability of being on platform that is supported for years can be signficant. Being on a dead branch could have significant impacts to an upgrade cycle for many large-scale systems. In the case of EAP, customers know that they will be supported for 7 years after a product is released.
Since no blog is complete without a list - let’s articulate at 5 reasons why you would want to pay for your open source software.
If you are using open source products and are not paying for a commercial subscription - chances are your support costs are higher than if you purchased an Enterprise subscription. Now, this isn’t necessarily a bad thing - it is possible that your human capital costs are less than the subscription. Unlikely, but possible. It is also possible that the community version of the product is so stable and commoditized that it doesn’t need commercial support SLAs. For simple frameworks and products, this is entirely possible. Finally, if your organization is so far advanced of the existing version of the Enterprise supported product you may need to use the community version so you can build and deliver your solution exactly the way you need. For example, a number of silicon valley companies roll their own Linux kernel and this is great for the community!
But, many Enterprise customers find that their IT Operations and Development organizations are spending more time troubleshooting than creating new features - and that is a real problem. In a competitive market, every moment focused on something other than delivering a product to market is wasteful. They value stability over newer (sometimes unstable) features.
If your budget doesn’t allow for the acquisition of supported product, or you need to be on the bleeding edge - go with the community product! But don’t assume that a community open source product will have the same security, stability and performance characteristics as an Enterprise supported open source product. That, unfortunately, is just not possible as it doesn’t support the commercialization model.
There is no free lunch.
The Subscription model from open source vendors, like Red Hat, is based upon the notion that you are actually paying for support, not licenses, for the software. In order to provide support, an Enterprise version of the software provided that must be used (e.g. the community software is not available for commercial support). Eventually, any defects resolved make it back to the community, but there is a time lag and the versions of the community software and enterprise software are not the same.
Enterprise-grade support requires vendors to staff support centers around the world with individuals that are experts on the products. These support personnel have seen many issues that Enterprise IT staff encounter and have the ability to troubleshoot issues quickly and efficiently. In most cases, the resolution is a configuration change or modification of how the subscribers’ codebase interacts with the system. In other cases, the support personnel can have the Product Engineeering organization deliver a patch to resolve an issue. This support structure (often 12x5 or 24x7) can greatly reduce the time for root cause analysis (RCA) and result in a much quicker recovery time than going it alone.
The more complex the system, the greater the risk for failure under extreme load and for hitting edge cases that weren’t detected during standard Unit, Integration, and QA Testing in your environment. In these scenarios, having a lifeline to support can be invaluable. Of course, not all customers need Enterprise support but if you have mission critical applications - you probably want to have the bat phone to the experts…and the only way to get that is to buy a subscription.
An additional benefit of Enterprise supported open source over the community bits is that the Enterprise version of the software is going to have a predictable release cycle and known support structure. In the case of EAP, for example, Red Hat supports the software for 4 years after release (bug-fix-patch) and then the software goes into a Transition period for (1 year) and finally a 2 year Maintenance cycle. This process guarantees customers have a stable system for up to 7 years. Of course, after the initial 4 year period all most of the product development is being tested with the next version of the software but major defects are fixed and the Enterprise has plenty of time to plan upgrades to future versions of software and hardware.
On the community side, the product lifecycle is far less predictable and releases can be fast and furious. In order to ensure that your organization has the time to respond to market forces, it is often worth the investment to standardize on a supported product to ensure releases are both predictable and stable. Additionally, the support lifecycle guarantess provide the ability for you to plan your upgrade paths.
In the world of product development, open source or proprietary, products that sell get investment. Products that don’t generate revenue…well they may die a slow death or they may not be as feature rich as they could be. Of course, there are open source projects where there is a significant investment prior to large adoption of the commercial product - OpenStack is a good example. In any case, buying the Enterprise product allows for greater investment and allows the product to improve at an even greater rate and even potentially deliver niche customer features.
In general, if you like a product and want it to continue to serve your longterm needs the only way to ensure that is to become a subscriber. Nothing says commitment like a paying customer and it is a lot easier for a vendor to ignore you when you are not a paying customer. If you like the prodcut at Free you should love it as a Subscriber!
Proprietary software vendors sell you the current version of their software. Prices vary widely by customer and often the contracting process can be extremely challenging where some features trigger additional hidden expenses. I’ve worked with many customers who unknowingly walked into a new project and suddenly realized they owed 3x their current license fees as a result of crossing a line in the contract.
Proprietary vendors also can significantly increase prices for the next version of the software resulting in unpredictable costs.
While no product is immune to price increases, the subscription model ammortizes your cost over 1 year or 3 year subscription and essentially allows you a longer time horizon to be able to budget and plan for your software development process. You can lock in pricing for 1 or 3 years and never have to worry about hidden costs. This predictability simplifies the budgeting process so you can begin to budget things that matter - such as building your product!
Hopefully this blog allows you to understand the mechanics of open source software commercialization so that you can make informed choices regarding how your organization acquires software. While the title of the blog was intentionally a little amusing (ok, click-bait), it should be clear that there is value in paying for open source software that is critical to your business. In fact, this is what strenghtens the open source community to continue delivering best-in-class products for significantly less cost than proprietary counterparts.
If you have any questions, or would like to speak with us further - don’t hesitate to reach out - we’d love to talk to you about how we can help you develop a comprehensive, cost-effective open source software strategy.