Open-source software has become as much of a fixture of the modern IT landscape as laptop computers.
Whether it’s Linux in the data center or Drupal powering a website, open source is everywhere. Even companies like Microsoft and Oracle, previously sworn enemies of open-source systems, have embraced open source as it has proliferated.
While the democratic ideals and distributed development model of open source are appealing to developers, some elements of that model are less attractive in production systems. The biggest drawback is that community control means distributed responsibility. Implementing pure open source can create problems and burdens that are less likely with systems have professional sales and service organizations behind them.
In short, with an open-source system, there is no throat to choke and IT professionals can be left with only community support when something goes awry.
That doesn’t mean that implementing open-source software is a bad idea. Doing so just requires taking a different approach to planning than you would with a proprietary software roll out. To help alleviate some of the problems, here are five things to remember when implementing open-source software.
Related Article: 7 Free Enterprise Intranet Solutions (That Aren't Really Free)
Not All Versions Are the Same
Because open-source projects are community-driven, a single open-source application can come in many forms, each one meeting the needs of a small niche of users — or even just a developer’s whimsy.
Of course, proprietary software may also come in different versions — Windows 10 and Windows 10 Pro, for example — but the differences between versions are generally limited. It’s too confusing, difficult and expensive for a vendor to maintain and develop many different versions of a single piece of software. Rarely is there a profitable market for many small variations of the base software.
That isn’t the case with open-source software. There are three main variants of open-source systems, forks, distributions and vendor distributions. Here’s a look at each one:
- Forks - Forked software is a variation that has its own development branch and, often, its own development community. Over time, these branches will diverge, and the variants may no longer resemble each other very closely. Two prominent examples of forked open-source software are the LibreOffice branch of OpenOffice and the MariaDB branch of MySQL. It’s important to know that even while the systems developed within these forks may appear outwardly the same as others with similar names, they may be quite different in their internal composition. Forks should be evaluated as if they were different pieces of software.
- Distributions - Open-source systems are often collections of pieces of software that, together, create the whole product. Different packages can be created to fit different needs. Linux is the most striking example of an open-source project with multiple distributions. Linux itself is the operating system kernel, but there are hundreds of distributions that are designed for specific needs.
- Vendor distributions - There are many software vendors, including Red Hat, Canonical (of Ubuntu fame) and Cloudera, and even giants like Google, Microsoft and Oracle, that sell enhanced distributions of open-source software. A vendor distribution may bundle proprietary extensions with base open-source software, and the vendor may offer support as part of the package. The additions are often designed to make the software enterprise-grade, and the vendor support offers the backup that enterprise IT operations need to run software in production.
The distinctions are important. Forks and distributions are designed to meet specific needs — environmental or philosophical — and vendor distributions are meant to deliver open-source systems in a way that enables IT to confidently deploy it in production throughout an organization.
Related Article: Github's Top Open Datasets For Machine Learning
Open Source Is Not Free
A common misconception is that open-source software is “free,” as in “no cost.” This is not true. Open-source systems are not controlled by any one company, and users don’t have to pay license fees for the core software. But that doesn’t mean that there aren’t costs associated with open source. There are costs — including acquisition costs and, of course, support and training costs. Without the user support programs that vendors of proprietary software offer, you may find that support and training costs are higher with open-source software than they are with commercial software.
Moreover, personnel costs may be higher when you use open-source software, because, without vendor support, you will need to build an internal support group.
It’s also important to note that pure open source — that is to say a non-vendor version of a software system — is unlikely to have been tested in a broad range of environments. The burden of testing the software will fall to the IT department that implements it.
The need for support is one of the biggest reasons why enterprise users often opt for vendor distributions of open-source software in their production systems.
Governance Models Vary
There are a number of governance models for open-source projects.
Learning Opportunities
Webinar
Mar
21
Ready to Level Up Your Learning? Discover Your Learning Maturity Score
Learn how to level up your learning program in this free, interactive workshop
Webinar
Mar
29
The CX Commute vs. the CX Joy Ride
Is your CX traffic holding up your customer's journey?
Webinar
Mar
29
Is Your Microsoft 365 Data Recoverable? How to Survive the IT Hotseat When Data is Lost
See why MIcrosoft recommends third party backup
Webinar
Mar
30
An Optimized Customer Contact Strategy Combines Transparency and Intelligence: The State of Outbound Communications
Learn from the Neustar-commissioned Forrester Consulting study on challenges and solutions for contact centers
Conference
May
10
CMSWire CONNECT Customer Experience Conference - Austin 2023
Don't miss the top customer experience and digital experience conference of the year — live in Austin, Texas May 10-12.
Conference
May
10
Reworked CONNECT Employee Experience & Digital Workplace Conference Austin 2023
North America's best employee experience and digital workplace conference of the year — live in Austin May 10-12, 2023.
In some cases, the software is controlled by a not-for-profit governing body, such as the Linux Foundation, the Apache Foundation or the Mozilla Foundation. These organizations maintain rules that govern how the software is developed, released and, most importantly, licensed. Not-for-profit foundations help to ensure that open source stays open.
Other projects have a BDL — a “benevolent dictator for life.” BDL-driven projects are similar to projects governed by not-for-profit groups, except that there is one person who basically controls the development process and can decide what goes into the software and what does not. Even when the community votes on features and releases, the BDL can overrule the decisions. The Linux Kernel has a BDL — Linus Torvalds, who recently handed over the reins of the Linux project to others temporarily. Projects controlled by a BDL often embody one person’s view of what is and isn’t important, and they may ignore the needs of the market. On the other hand, a BDL limits fragmentation and helps to ensure quality.
Finally, there is vendor-controlled governance. Under this model, a vendor controls the open-source project and licensing. Arguably, this is not truly open. Vendors can shut down such projects, leaving the software orphaned, or they can change the licensing terms just as they might with proprietary software.
With each model, software is released under different types of licenses, each of which comes with its own responsibilities and limitations.
You should know the governance model and the licensing terms of any open-source system you are thinking of using. If you don’t, you may end up deploying a system that is not sustainable over the long term.
The Community or BDL Sets the Road Map
When companies develop proprietary software, they often find that it is in their best interests to have a regular schedule of releases that add new features important to customers. That is not the case with open source.
Features of open-source systems are developed and controlled by a community or a BDL. This means that new features are not always released on a predictable schedule. Moreover, the new features that are introduced may not be features that specific groups of users need. Even when developers participate in the open-source community and create features that are important to their applications, the community or BDL may decide that those features are not important to the main branch of the software.
Most larger projects, such as Mozilla Firefox, try and keep a regular release schedule, but that isn’t always the case with open source.
Open-source software is an essential component of the IT landscape. The open-source model allows for the development of new and innovative software at a lower cost. There are a lot of niche applications that would not be possible without open-source support.
However, if you decide to implement open-source software in a production environment, remember that the rules are different than they are with proprietary software. A successful implementation depends on understanding and accounting for those differences.
Learn how you can join our contributor community.