Open source software development establishes an environment in which authors can create and release source code...
for collaborative study, adaptation and redistribution.
Any enterprise, team or individual can create and release code under an open source license. Open source components go far beyond mundane UI and utilitarian functions. Contributions are available in fields as diverse as desktop publishing, AI, mathematics, imaging, data storage and networking, gaming, education, programming and security. A community like GitHub, for instance, hosts over 100 million repositories created by over 31 million contributors.
With this embarrassment of riches at their fingertips, teams must make decisions about using open source code in proprietary software projects in ways that don't undermine their business goals, security or effective development practices.
Advantages of open source software
Developers can easily obtain, modify and integrate countless open source code packages into diverse software projects. Using open source code to enable basic features and processes in a proprietary software project can shave time off of development cycles and free code creators to focus on core and business-enabling functionality.
While open source elements confer tangible benefits for software development projects, they can impose challenges and limitations on a proprietary application, especially if the project is intended for commercial use. Organizations should evaluate the management and integration of software components from other creators, their project priorities, liabilities, licensing and security before selecting open source code for a project.
1. Open source software integration and management
Many open source components have a bevy of alternatives and variations. For example, developers can select from dozens -- and sometimes hundreds -- of open source UI engine options. You must evaluate and vet each option to ensure that it will work with your project's overarching design. Some open source code requires integration with other components, and you should test each integration point to ensure software quality.
In addition, open source software gets updated to fix bugs, enhance performance and add features, which means the proprietary project's components must be reevaluated and vetted when changes occur to the open source project.
Open source code integration into proprietary software can create a nightmare for project managers. When a distributed software project relies on hundreds of open source components, the time and effort it takes to simply keep track of each component, its compatibilities and its updates can affect the project's development cycle.
2. Open source code liabilities
The evaluation and vetting process for open source code should include a review of the component under consideration's roadmap and coding.
A software team may want open source code that meets their pressing needs for certain functionalities -- but considering only what they need today could bite them later. Read up on the code's future outlook, including potential major modifications. If the component has not been updated in a while -- some call these projects abandonware -- or won't fundamentally support capabilities that your project is expected to require in the future, consider using in-house work or other open source options.
Open source code offers no guarantees for quality or performance. And unlike commercial software, the code typically lacks a warranty to offer recourse for failure or poor execution. Businesses take on full liability for their projects' performance, even if the fault of poor performance or an error lies squarely with an open source code element. When using open source code in proprietary software projects, carefully consider the warranties and limitations of liability delineated in its license.
3. Licensing and intellectual property
Generally, open source software licenses do not significantly restrict a business's ability to acquire and use them. So, a proprietary and commercial software product can rely on open source components.
However, businesses must know if and how a license can cause problems. The GNU GPL requires users to release any derivative works under the same GNU GPL license. If a business obtains and modifies open source code under GNU GPL, it must copyleft the modified code -- meaning release it to open source, as well.
In some cases, the whole software project is considered a derivative work of the open source code it uses, and all of the proprietary project's source code is subject to open source distribution under the license terms. For this reason, business decision-makers might prevent developers from using open source code for a project, even if it fits the group's requirements and criteria for functionality.
Nearly all applications -- 96% of those examined -- contain some open source components, according to a 2018 survey by application security testing vendor Synopsys. The report found that the average application uses over 250 open source components in its build.
4. Business priorities
Don't just gauge an open source component's suitability for a project in terms of the time and money that it saves. Evaluate if the component does or does not help fulfill your business goals.
To gain a competitive advantage, businesses rely on software feature innovation and efficient performance. Developers should always look for opportunities to innovate -- whether that means they cut project time by slotting in open source code or that they custom-build components that meet the exact needs of an application.
For example, developers of a visualization and rendering tool project could adopt Blender open source 3D modeling software for core functionality, but there's nothing stopping their primary competitors from doing the same thing. Hence, the resulting tools would lack differentiation to win over prospective customers.
5. Open source software security
A deep, active open source ecosystem is a breeding ground for both vulnerable and malicious code. The open source marketplace is the ultimate example of caveat emptor, which in Latin means "let the buyer beware."
Open source software security relies on community feedback -- which is more effective the more popular a project is -- as well as routine vulnerability scanning. When using open source code in proprietary software, businesses must bear the risks and enact security vetting beyond community input to ensure the software meets their corporate standards. For example, developers and testers should examine open source code for embedded spyware and other malware, as well as for vulnerabilities that can leave the proprietary software project open to being exploited by malicious parties.
Organizations that rely on open source code in software projects should use vulnerability testing tools to ferret out susceptibility to problems like buffer overflows, address resolution protocol spoofing, distributed denial-of-service attacks and cache poisoning. Vulnerability testing can be incorporated into a software delivery pipeline.
You should evaluate these five key areas for each project and for every piece of open source code. Open source code components are all governed by specific license terms, are built with varying degrees of performance and are subject to myriad potential quality issues.
The common factor across all the cases of using open source code in proprietary software projects is that the responsibility falls on the business, not the code creator. Devise policies for how to intelligently use open source software and how to validate, manage and optimize the code.