The Case for Open Source

9 min read Original article ↗

Keegan Justis

Open-source software has a mixed reputation among information technology professionals. While developers appreciate the productivity gains from using free and open software packages in their codebases, several security concerns, copyright risks, and operational bottlenecks create an environment where senior leadership often prefers commercial or proprietary software solutions. However, while this viewpoint was prevalent in the 1990s and early 2000s, the situation in 2024 is different. The risks associated with open source can be managed, and the cost savings and productivity increases from open source cannot be ignored.

Software engineers usually don’t need to be persuaded to use open-source software. In 2024, every competent software developer has downloaded at least one package from the internet as a dependency in their codebase. The only engineers without open-source software are those working on old legacy systems (Fortran, COBOL, or other antiquated languages) and a few engineers in the military/defense/intelligence industry.

Security Concerns

A common concern about open-source software is that, because the code is free, security vulnerabilities could be exposed to the internet. An open-source contributor could naively or intentionally introduce malware into a project. These are real concerns, but the risks can be mitigated with the correct tools and security posture. Open-source projects often have security CVEs that are patched by volunteers before commercial software vendors can patch their software. Additionally, some of the largest open-source contributors are employed full-time by companies like Google, Intel, and Meta to support and patch open-source software. There is significant commercial backing for various open-source tools, and an active open-source project is likely more secure than an unsupported commercial software offering.

Supply chain security remains a concern, but there are many software tools available to manage dependencies and address security vulnerabilities and CVEs in your software. With the rise of large language models (LLMs), detecting security vulnerabilities and malware will only become easier over time.

Copyright Risks

Open source licenses are legal frameworks that govern how software can be used, modified, and distributed. These licenses promote collaboration and sharing, allowing developers to contribute to and improve upon existing codebases. However, they come with various terms and conditions that can pose certain risks to for-profit companies. Here’s an overview of some common open source license models and the associated risks:

Common Open Source License Models

  1. Permissive Licenses (e.g., MIT, Apache 2.0, BSD)
  • Characteristics: These licenses are very flexible and impose minimal restrictions. They allow software to be used, modified, and distributed with few conditions, often requiring only attribution to the original authors.

Risks:

  • Intellectual Property (IP) Risks: Companies must ensure proper attribution and compliance to avoid legal issues.
  • Integration Risks: While permissive, using such software still requires diligent tracking and compliance management.

2. Copyleft Licenses (e.g., GPL, AGPL)

  • Characteristics: These licenses require that any derivative work be distributed under the same license terms, ensuring that the source code remains open and free.

Risks:

  • License Compatibility: Copyleft licenses can be incompatible with proprietary licenses, making it difficult to combine open source and proprietary code.
  • Distribution Obligations: If a company modifies and distributes the software, it must release the modified source code, potentially exposing proprietary enhancements.
  • Viral Nature: The obligation to open-source derivative works can extend to software that merely interacts with copyleft-licensed code, creating a risk of unintentional license violations.

3. Lesser General Public License (LGPL)

  • Characteristics: A more permissive version of the GPL, the LGPL allows linking to open source libraries without requiring the linked proprietary code to be open-sourced.

Risks:

  • Dynamic vs. Static Linking: Companies must ensure they understand the difference between dynamic and static linking, as static linking may trigger copyleft obligations.
  • Compliance: Proper documentation and tracking are necessary to ensure compliance with LGPL requirements.

4. Public Domain Dedication (e.g., CC0)

  • Characteristics: Software is dedicated to the public domain, with no restrictions on use, modification, or distribution.

Risks:

  • No Warranty: Public domain software comes with no warranty, which can be a risk for companies relying on it for critical operations.
  • IP Ownership Uncertainty: There can be uncertainty about the actual status of the code’s public domain dedication, potentially leading to IP disputes.

Risks to For-Profit Companies

  1. Legal Risks: Non-compliance with open source licenses can lead to legal action, including injunctions, fines, and the forced release of proprietary source code.
  2. Intellectual Property Risks: Using open source software without proper IP management can lead to inadvertent IP violations and potential litigation.
  3. Competitive Risks: Obligations to release derivative works can undermine competitive advantages by exposing proprietary enhancements to competitors.

Mitigation Strategies

You can mitigate the risk of different licensing issues by using automated tools to check licenses, establishing policies for adding open-source tools, and, in rare cases, consulting a legal professional when there is ambiguity. By understanding these open-source license models and implementing effective risk management strategies, for-profit companies can leverage the benefits of open-source software while mitigating potential risks.

Operational

A common argument against open source software for enterprises is that commercial software should be more stable, have more funding, and offer better support. The belief is that if an SLA is important, it’s better to pay for a more reliable product. This viewpoint often comes from decision-makers with a Windows system administrator background, and it’s likely that Microsoft has advocated this perspective in the past.

For example, in the 1990s, Elon Musk wanted his employees at PayPal to use Windows Server instead of Linux. The concern was that the lack of enterprise support, confusing documentation, and overall experience with Linux would result in outages, reducing productivity and site reliability.

Given these concerns, some may question whether an operational information technology professional should choose an open-source product if they are worried about uptime and meeting tight SLAs.

Press enter or click to view image in full size

The world has changed significantly since the 1990s. The number of software engineers has rapidly increased, sites like StackOverflow provide developers with forums to troubleshoot code, and large language models can now read, write, and debug production code. The tradeoff between reliability and cost is no longer mutually exclusive. There is a wide range of highly reliable and well-tested open-source packages and platforms. Conversely, there are also unreliable commercial software vendors with poor to nonexistent support.

Consider a Linux server compared to a Windows server for hosting a static website. For a seasoned IT administrator, a Linux server should be easier to debug and use than a Windows server, provided the administrator is comfortable with a CLI interface. There is an abundance of free training and a wealth of support information available online, resources that were not as accessible in 1999.

Several freemium open-source companies offer paid support plans for their free or open-source products. If your SLA is 99.999, it makes little difference whether you use proprietary software or an open-source tool. What matters is the quality of the tool itself, not the company that supports it. While you can sue a commercial company for breaching an SLA, they will have corporate lawyers defending them, and it’s unlikely you will be awarded damages equivalent to the impact of the downtime on your business.

If support is essential and you require a strict SLA for operations, consider choosing a third-party vendor for support. This could be a software vendor with a reputation for good support or a third-party consulting firm that supports the product.

It ultimately comes down to the talent of your information technology staff. If your staff are experts in a specific commercial vendor’s products and aren’t quick to learn new technologies, there is a business case for using commercial tools. Conversely, if your staff is highly competent, can quickly acquire new skills, or has experience with a specific open-source project, it may make sense to use an open-source solution.

Productivity

Choosing an open-source tool involves weighing the tradeoff between total cost of ownership and productivity gains. While the software itself may be free, if the cost of support consumes significant time from your engineers, it may not be the best fit for your company. Additionally, if the open-source software is difficult for your end users to navigate, causing them to spend more time on simple tasks, this decrease in productivity must be considered in the overall business decision to purchase commercial software.

Commercial software can sometimes be more user-friendly, and this ease of use may influence the decision. Ultimately, choose the tool that makes your team most productive and aligns with the price you are willing to pay.

Vendor Lock-in

A real risk of commercial software is the potential for vendor lock-in. If the vendor changes its pricing model, terms of use, or product support, you may find yourself in a difficult position. Your reliance on the existing tool may force you to choose a new solution if, for example, the software is no longer supported due to reaching the end of its lifecycle, such as an older version of Windows, or if a Software as a Service (SaaS) offering becomes unavailable because the web application goes offline.

In contrast, with open-source software, even if a project loses momentum and no longer receives contributions, you still have access to the source code. While you may not receive new security updates, you can continue to use and deploy the software for as long as you need. Additionally, you have the option to contribute to the source code yourself, adding new features or capabilities as required.

In conclusion, the business case for open-source software is compelling due to its potential for significant cost savings, flexibility, and community-driven improvements. By leveraging open-source tools, companies can avoid vendor lock-in, customize software to meet specific needs, and benefit from the collective innovation of a global developer community. While the freedom software philosophy emphasizes the ethical aspects of software use, the primary focus for businesses should be on the practical advantages: reduced total cost of ownership, increased control over software, and the ability to maintain and enhance the software independently. The freedom to modify and distribute open-source software ultimately translates into tangible business benefits, making it a smart choice for many enterprises.