Take the First Steps to Embrace Open-Source Software

Begin to understand what is required to embrace open-source software in your organization.

Analyst Perspective

With great empowerment comes great responsibilities.

Open-source software promotes enticing technology and functional opportunities to any organization looking to modernize without the headaches of traditional licensing. Many organizations see the value of open source in its ability to foster innovation, be flexible to various use cases and system configurations, and give complete control to the teams who are using and managing it.

However, open source is not free. While the software is freely and easily accessible, its use and sharing are bound by its licenses, and its implementation requires technical expertise and infrastructure investments. Your organization must be motivated and capable of taking on the various services traditionally provided and managed by the vendor.

Andrew Kum-Seun
Research Director,
Application Delivery and Application Management
Info-Tech Research Group

Executive Summary

Insight Summary

Overarching Info-Tech Insight

Open source is as much about an investment in people as it is about technology. It empowers applications teams to take greater control over their technology and customize it as they see fit. However, teams need the time and funding to conduct the necessary training, management, and ongoing community engagement that open-source software and its licenses require.

• Position open source in the same light as commercial software.
  The continuous improvement and evolution of popular open-source software and communities have established a trusting and reliable reputation in the industry. Open-source software quality and community support can rival similar vendor capabilities given the community’s maturity and contributions in the technology.
• Consider open source another form of outsource development.
  Open source is externally developed software where the code is accessible and customizable. Code quality may not align to your organization’s standards, which can require extensive testing and optimization. A thorough analysis of change logs, code repositories, contributors, and the community is recommended – much to the same degree as one would do with prospective outsourcing partners.
• Treat open source as any internally developed solution.
  Configurations, integrations, customizations, and orchestrations of open-source software are often done at the code level. While some community support is provided, most of the heavy lifting is done by the applications team. Teams must be properly resourced, upskilled, and equipped to meet this requirement. Otherwise, third-party partners are needed.

What is open source?

According to Synopsys, “Open source software (OSS) is software that is distributed with its source code, making it available for use, modification, and distribution with its original rights. … Programmers who have access to source code can change a program by adding to it, changing it, or fixing parts of it that aren’t working properly. OSS typically includes a license that allows programmers to modify the software to best fit their needs and control how the software can be distributed.”

What are the popular use cases?

1. Programming languages and frameworks
2. Databases and data technologies
3. Operating systems
4. Git public repos
5. Frameworks and tools for AI/ML/DL
6. CI/CD tooling
7. Cloud-related tools
8. Security tools
9. Container technology
10. Networking

Source: OpenLogic, 2022

Common Attributes of All Open-Source Software

• Publicly shared repository that anyone can access to use the solution and contribute changes to the design and functionality of the project.
• A community that is an open forum to share ideas and solution enhancements, discuss project direction and vision, and seek support from peers.
• Project governance that sets out guidelines, rules, and requirements to participate and contribute to the project.
• Distribution license that defines the terms of how a solution can be used, assessed, modified, and distributed.

Take the first steps to embrace open-source software

Begin to understand what is required to embrace open-source software in your organization.

State the Value of Open Source: Discuss current business and IT priorities, use cases, and value opportunities to determine what to expect from open-source versus commercial software.

Select Your Open-Source Software: Clarify the driving factors in your evaluation of open-source and commercial software using your existing IT procurement practices as a starting point.

Prepare for Open Source: Clarify the roles, processes, and tools needed for the implementation, use, and maintenance of open-source software.

Step 1.1: State the Value of Open Source

Activities

1.1.1 Outline the value you expect to gain from open-source software

This step involves the following participants:

• Applications team
• Product owner

Outcomes of this step:

• Value proposition for open source
• Potential open-source use cases

Use a canvas to frame your open-source evaluation

This canvas is intended to provide a single pane of glass to start collecting your thoughts and framing your future conversations on open-source software selection and adoption.

Record the results in the “Open-Source Canvas” tab in the Open-Source Readiness Assessment.

Open source presents unique software and tooling opportunities

Innovation

Many leading-edge and bleeding-edge technologies are collaborated and innovated in open-source projects, especially in areas that are beyond the vision and scope of vendor products and priorities.

Niche Solutions

Open-source projects are focused. They are designed and built to solve specific business and technology problems.

Flexible & Customizable

All aspects of the open-source software are customizable, including source code and integrations. They can be used to extend, complement, or replace internally developed code. Licenses define how open-source code should be and must be used, productized, and modified.

Brand & Recognition

Open-source communities encourage contribution and collaboration among their members to add functionality and improve quality and adoption.

Cost

Open-source software is accessible to everyone, free of charge. Communities do not need be consulted prior to acquisition, but the software’s use, configurations, and modifications may be restricted by its license.

However, myths continue to challenge adoption

• Open source is less secure or poorer quality than proprietary solutions.
• Open source is free from risk of intellectual property (IP) infringement.
• Open source is cheaper than proprietary solutions.

What are the top perceived barriers to using enterprise open source?

• Concerns about the level of support
• Compatibility concerns
• Concerns about inherent security of the code
• Lack of internal skills to manage and support it

Source: Red Hat, 2022

Myth 1: Open source is less secure or poorer quality than proprietary solutions

Myth 2: Open source is free from risk of IP infringement

Myth 3: Open source is cheaper than proprietary

IT leaders are changing their stance on open source

IT leaders are overcoming their reservations about open source

Seventy-seven percent of IT leaders have a more positive perception of enterprise open source than they did a year ago (Red Hat, 2022).

They are building strategies to increase its use and value

Thirty-six percent of organizations have an open-source strategy (OpenLogic, 2022).

Seventy-seven percent of organizations indicated that they have increased their use of open-source software over the last year (OpenLogic, 2022).

1.1.1 Outline the value you expect to gain from open-source software

Output: Value proposition for open source, Potential open-source use cases
Participants: Applications team, Product owner

30 minutes

Define the value you expect to gain from open source by answering the following questions:

1. What is the name of the initiative under consideration?
2. What business and IT problem do you want to solve?
3. Who are your stakeholders?
4. What business and IT objectives define the success of this initiative?
5. What business capabilities, processes, and application systems are within the scope of this initiative?
6. What is the rationale for the decision to use open-source or commercial/proprietary software? What makes open source a better option than commercial/proprietary software for this initiative?

Record the results in the “Open-Source Canvas” tab in the Open-Source Readiness Assessment.

Step 1.2: Define Your Selection Criteria

Activities

1.2.1 Define your proposed selection criteria

This step involves the following participants:

• Applications team
• Product owner

Outcomes of this step:

• Prioritized list of factors to be used in open-source and commercial software selection

Accommodate open source in your vendor procurement practices

Apply the same disciplined approach to open-source selection as you would to proprietary software.

See our Drive Successful Sourcing Outcomes With a Robust RFP Process for more information.

Key questions to ask:

• Does the open-source software do what you need it to do?
• Does it meet, or can it be configured to meet, your key nonfunctional requirements?
• Are there resources available to implement and support open source?
• Is the open-source project actively used, developed, and supported?
• Does the project have a future?
• What is the quality of the user and developer documentation and the state of the code repository?
• What is the right version to use?
• Is the open-source license a fit for your purpose and goal?

Understand the differences between open- and closed-source software

Source: Synopsys

Choose the license that fits your needs

Deciding between open- and closed-source licensing for your products is not just about code.

When deciding how to license your products or components, don’t start with debating open- versus closed-source code. Instead, start by asking simple questions around your overall goals:

1. Are you looking to directly monetize the release of this product?
2. Are you concerned about IP/trademark/patent protection?
3. Are you concerned about being viral and being in as many places as possible?
4. Do you want to give back to the community and serve your user base in different ways?

There are many different licensing models to consider, and each confers different rights and obligations upon the licensee. See to the right for different licensing models.

Learn more about open-source licenses in the appendix and our Deciding Between Open Source and Closed Source Licensing for Your Products Is Not Just About Code note.

Summary of licensing models

Recognize the hidden costs of open source

With open source, you are taking on accountability for the various services and support costs that are traditionally included in commercial licenses.

“When you are comparing cars you like, you should go beyond sticker price. You should research the ongoing costs of driving and maintaining each model, so that you get a true understanding of affordability. A realistic estimate of a vehicle’s total cost of ownership is crucial in helping you choose a car that fits your budget. The same applies to purchasing a software product, regardless of whether it is an open-source software product or a proprietary one.”

– Donal O’Connell in “The total cost of ownership of open source software,” Intellectual Property Expert Group

Keep an eye out for red flags

Not all open-source projects are built and managed the same. Some can present a bigger risk than others.

• Prohibitive or unclear licensing requirements.
• Poor software and code governance, including contribution requirements, documentation, and version history.
• Open-source software is not widely adopted or validated.
• Open-source community has few active contributors or low-value participation.
• Major project contributors, backers, and leaders have questionable histories and governance practices.
• The project’s direction, vision, and roadmap conflicts with your priorities and principles.
• There are costs to download and support the software.

1.2.1 Define your proposed selection criteria

Output: Prioritized list of factors to be used in open-source and commercial software selection
Participants: Applications team, Product owner

30 minutes

Define the value you expect to gain from open source by answering the following questions:

1. Review the goals and objectives of your initiative and the benefits you want to gain from open source.
2. Using your current vendor procurement practices as a starting point, list and prioritize the criteria that will aid you in software selection, including open-source software.
3. Verify and validate if these decision factors can be used as scoring criteria in a software evaluation involving both open-source and proprietary/commercial solutions.

Record the results in the “Open-Source Canvas” tab in the Open-Source Readiness Assessment.

Check the alignment of your priorities with those of the community

What are the goals and vision of the open-source project and community?

The fit of an open-source project and community can hinge on the project’s promotion, development, and evolution.

• TensorFlow: “Makes it easy for beginners and experts to create machine learning models for desktop, mobile, web, and cloud.”
• Selenium WebDriver: Supports W3C-compliant automation of all the major browsers in the market with a simple and concise interface.
• OpenStack: “…achieve visible common changes, push for basic levels of consistency and user experience, and efficiently improve certain areas where technical debt payments have become too high.”

Who is driving the narrative?

Eighty-two percent of IT leaders are more likely to select a vendor who contributes to the open-source community (Red Hat, 2022).

Vendor: How is the vendor benefiting from the open-source project?

User Community: Is there a dominant voice directing the focus and maturity of the project?

Step 1.3: Assess Your Readiness for Open Source

Activities

1.3.1 Assess the readiness of your team

This step involves the following participants:

• Applications team
• Product owner

Outcomes of this step:

• Application team’s readiness for open source

Enhance your SDLC to support open source

The software development lifecycle (SDLC) is a process that creates and ensures valuable software products are efficiently delivered to customers. It contains a repeatable set of activities needed to intake and analyze requirements and requests to design, build, test, deploy, and maintain software products.

How will open source influence my SDLC?

• Emphasis on custom development: Open-source software is often bare bones, requiring users to deploy, configure, and orchestrate it. Some tools and out-of-the-box integrations may be available to assist in implementation and maintenance, but they may not be enough for complex use cases. Investment in development capabilities is needed to merge open-source software with your current system.
• Quality assurance & code analysis: Open-source code is written by the community and may not meet your quality or regulatory standards. Much like code developed by professional services, software analysis and testing are needed in the final stages of deployment.
• Iterative delivery & continuous improvement: Enhancements, updates, customizations, and fixes are continuously added by the open-source community. Teams, delivery practices, and system owners must be aware of the direction and evolution of the open-source project and be capable of pushing changes on short notice.

To learn more, visit Info-Tech’s Modernize Your SDLC blueprint.

Open source emphasizes the importance of key IT capabilities

Portfolio Management: An accurate and rationalized inventory of all software verifies open source is supporting the goals and usage policies of the broader system. This becomes critical when software is updated frequently and licenses and community principles drastically change (e.g. after an acquisition).

Architectural Framework: Open-source software is designed to work alongside a broader set of solutions in an organization’s ecosystem. Principles and standards need to guide a sustainable and scalable growth of integrated and loosely coupled technologies.

Security & Access Management: Externally developed code may not include the measures, controls, and tactics you need to prevent vulnerabilities and protect against threats that matter to you or comply with your mandatory security frameworks and standards.

Data Management & Governance: Data can be transformed and consumed in various ways as it transits through various open-source and proprietary solutions. Data integrations, structures, and definitions must be well defined, governed, and monitored.

Application Management: Any open-source component can fail, be involved in a lawsuit, be compromised, or lose compatibility with other solutions. Teams and systems should be prepared to recover backups, roll back, and execute recovery plans at a moment’s notice.

Apply good practices in the use of open source

1. Reuse existing components wherever appropriate: Establish a process for sourcing the most suitable components to meet your needs and determine licensing compatibility with your initiative’s objectives.

2. Track and control changes to internal components: Complete an inventory and change log of software components and document the ones that are sensitive, especially those to be reused.

3. Control reuse of sensitive and external components: Develop an approved/prohibited list for the use, acceptable modifications, and management of sensitive and external components.

4. Verify every build and release: Inspect the code for unapproved components and changes and verify all externally developed component are documented, including the license implications.

5. Review compliance at key milestones: Evaluate the compliance of all software components at key software delivery milestones alongside existing continuous testing activities, accommodating changing business and legal factors and environments.

6. Manage community contribution and distribution: Apply the appropriate checks and balances and controls around code contribution to open-source communities to avoid the release of IP.

7. Assess software components before acquisition: Evaluate the components acquired from another organization, such as those not owned by the supplier, existing license obligations, and financial impact for incorporating the component into the existing system.

Commit to the open-source project and community

The direction and scope of an open-source project can significantly shift within a short period of time. These changes can jeopardize the value, supportability, and scalability of the impacted processes, applications, and commercial products if time and effort are not dedicated to collaborate and contribute to the project.

What does commitment look like?

• Collaborate on the Project’s Trajectory: Influence the future growth and maturity of the open-source project through the community. Verify and validate that the project’s priorities align with those of your organization so plans can be made to replace or minimize the reliance on open-source code if needed.
• Contribute to the Project: Regularly submit software code, configurations, integrations, and templates to the repository. Contributions demonstrate the software’s value in your industry and draws attention to your specific use cases.
• Assist Community Members: Provide fixes, updates, and enhancements for reported issues and requests. This establishes you as a reputable member of the community, giving you credibility as a contributor and leader.

1.3.1 Assess the readiness of your team

Output: Application team’s readiness for open source
Participants: Applications team, Product owner

1-3 hours

1. Review the current state of your application teams, including their capacity, skills and knowledge, delivery practices, and tools and technologies.
2. Determine the readiness of your team to adopt open source.
3. Discuss the gaps that need to be filled to be successful with open source.

Record the results in the “Open-Source Canvas” tab in the Open-Source Readiness Assessment.

Example:

Be prepared to address the risks with open source

“The reason why I stopped creating new open-source projects was because I couldn’t afford to maintain them.

I was expected to not only share my work, but continue adding new features, docs, and providing support for free, forever. It just wasn’t sustainable for me.”

– Kelsey Hightower, Distinguished Developer Advocate, Google, 2022

Related Info-Tech Research

Select a Sourcing Partner for Your Development Team
Choose the right partner to enable your firm to maximize the value realized from your sourcing strategy.

Drive Successful Sourcing Outcomes With a Robust RFP Process
Leverage your vendor sourcing process to get better results.

Develop and Deploy Security Policies
Enhance your overall security posture with a defensible and prescriptive policy suite.

Create a Data Management Roadmap
Streamline your data management program with our simplified framework.

Develop an IT Asset Management Strategy
Define your business-aligned approach to ITAM.

Deliver on Your Digital Product Vision
Build a product vision your organization can take from strategy through execution.

Enhance Your Solution Architecture Practices
Ensure your software systems solution is architected to reflect stakeholders’ short- and long-term needs.

Modernize Your SDLC
Deliver quality software faster with new tools and practices.

Application Portfolio Management Foundations
Ensure your application portfolio delivers the best possible return on investment.

Bibliography

The 2022 State of Open Source Report.” OpenLogic, 2022. Web.

“Contributing Overview.” React Native, 22 July 2022. Web.

“Copyright and attributions.” Selenium, 29 Aug 2022. Web.

“GNU Public License.” WordPress, n.d. Web.

Hightower, Kelsey [@kelseyhightower]. ““The reason why I stopped creating new open source projects was because I couldn’t afford to maintain them. I was expected to not only share my work, but continue adding new features, docs, and providing support for free, forever. It just wasn’t sustainable for me.” Twitter, 23 Nov 22. Web.

“Introduction to TensorFlow.” TensorFlow, n.d. Web.

“Licensing requirements.” OpenStack, 14 Sept 2021. Web.

Luszcz, Jeff. “Artifex v. Hancom: Open Source is Now an Enforceable Contract.” The Linux Foundation, 31 Aug 2017. Web.

O’Connell, Donal. “The total cost of ownership of open source software.” Intellectual Property Expert Group, n.d. Web.

“Open Source Software.” Synopsys, n.d. Web.

OpenStack-wide Goals.” OpenStack, 24 March 2022. Web.

“The State of Enterprise Open Source: A Red Hat Report.” Red Hat, 2022. Web.

Taylor, Mark. “How Much Does Open Source Cost?” SiriUS OpenSource, n.d. Web.

“WebDriver.” Selenium, 7 Sept 2021. Web.

Appendix B: Explore combining licensing

When it comes to picking a license for your software product, your choice does not have to be so binary. Sometimes it can be combined with great success.

Dual Licensing, Same Product

• Same software confers different rights to user depending on license chosen (open source versus commercial)
• Example: MongoDB, MySQL

Different Licenses, Different Products

• Open source – standard version
• Enterprise version or plug-ins would have a different commercial license
• Example: Eclipse, Android, Adobe Flex, WordPress CMS

Value-Add Services

• Software under an open-source license
• User pays for related value-add services