Open-Source and Tech DD: Spotlighting Crucial Areas for Success

When it comes to investment opportunities where tech plays a central role, two vital concerns often grab the attention of both investors and vendors: Intellectual Property (IP) and monetization strategies. Traditionally, a company’s proprietary code, encompassing functionalities, integrations, self-developed algorithms, and machine learning models, serves as the cornerstone of its IP portfolio and its monetization strategy and ultimately its value and success. 

However, the story takes a twist when we shift our focus to companies with open-source products. In such cases, a significant portion, if not all, of the company’s code is available to the public. Teams may choose open-source development as it offers plenty of great advantages. However, inevitably this approach to development gives rise to various questions, too, such as: ‘Does open source mean that anyone can freely use the code and emerge as a market rival?’ Both investors and vendors are not only concerned about safeguarding the IP but also about formulating effective monetization strategies in the open landscape. How do you derive revenue when your core product is freely available to all? It’s a scenario that presents its own set of unique challenges and potential opportunities.

One such challenge is the question of how to carry out tech due diligence (Tech DD) in these companies. A detailed and thorough deep dive with a different perspective is required to ensure that the open-source software adheres to standard coding practices, is secure, actively leverages community efforts and engagement, and has no licensing issues. In other words: does the product harness the advantages, but does it stick to its obligations at the same time?

As we will discover, there are scenarios where embracing open source can actually lead to greater opportunities, as demonstrated by industry titans like Red Hat, WordPress, and MongoDB. Even more intriguing is the fact that large enterprises are now using open-source software to collect invaluable data and insights about their products and services.

In this article, we will highlight the advantages, strategies for monetization, challenges, and Tech DD considerations that should be carefully navigated when considering open-source software in tech investments.

Advantages of Open Source

Community Collaboration

Open-source projects thrive on the power of community collaboration. A diverse group of developers, enthusiasts, and experts work together to enhance the software, find and fix bugs, and drive innovation.

Open-source is a unique world where competitors can also be collaborators. Both individual contributors and participants from various companies come together to improve and expand the capabilities of open-source projects. Each participant, whether a corporation or an individual, contributes to the project for their own reasons. Some companies go the extra mile, allocating dedicated teams to open-source projects full-time to ensure seamless compatibility with their hardware or software. For instance, Microsoft (The same company that compared Linux to cancer back in 2001) began contributing to the Linux kernel in 2009 to develop essential drivers required for Microsoft’s Hyper-V virtualization technology, and later to enhance the Linux experience on its Azure cloud platform, or in 2016, Samsung provided ARM support to .NET Core and contributed to Xamarin, enabling it on a variety of Tizen devices, enthusiastically stating to be “excited to be part of the .NET community”.

Individual contributors may have a range of motivations as well: from learning and self-improvement, enhancing their reputation in the community, or simply the belief in creating open software that anyone can use and improve.

This broad collective effort often results in a product that’s not only robust but continually evolving. This diversity of thought and effort often leads to creative solutions that might not have been possible in a closed, proprietary environment.

Faster Development

Open source projects often have faster development cycles as contributors worldwide work together to improve the codebase. This agility can be a competitive advantage in the technology industry.

The distributed nature of open-source development means that innovation happens at an accelerated pace. Bugs get identified and fixed more rapidly, and new features are developed with the collective wisdom of a global developer community.

Low Entry Barrier for Potential Clients

Offering a free version of the software serves as a powerful marketing tool. It allows potential clients to try the software with minimal risk, enticing them to explore commercial services later.

This eliminates the need for expensive licensing fees or long-term commitments and can be incredibly attractive to startups and small businesses, which are often more budget-conscious than enterprises. Once they’ve experienced the value of the open-source version, many companies find it logical to invest in more advanced commercial offerings as extensions to the open-source version, such as SLAs, additional functionality for scalability, or consulting services.

Increased Security and Transparency

Transparency is a cornerstone of open source and contributes to building invaluable trust with customers. Anyone can inspect the code, which boosts their confidence in the absence of hidden vulnerabilities or malicious code, and verifies that the software meets their security and compliance requirements. Tech DD should include a thorough review of the project’s security practices, vulnerability management, and compliance with industry standards and regulations.

Open-source software is known for its security benefits. When vulnerabilities are discovered, there is an army of developers and security experts ready to address the issue. This rapid response can be a major advantage in today’s fast-paced and ever-changing threat landscape.

Flexibility in Customization

Open-source software is highly customizable, allowing businesses to tailor it to their specific needs. This flexibility broadens the user base and increases adoption over time.

Unlike proprietary software, open-source software provides customers with the freedom to modify the code to suit their unique requirements. This leads to increased adoption and can even foster entirely new businesses built around customizing and supporting open-source solutions.

Monetization Strategies

Below are some commonly utilized monetization strategies for companies with open-source products:

Paid Support

Offering commercial support services, such as consulting and premium customer support, can be a lucrative revenue stream.

Many companies using open-source software require support. They need assistance with installation, configuration, troubleshooting, and scaling. This creates a demand for commercial support services, which can be offered as a premium service.

Customization services, where open-source software is tailored to meet the unique requirements of specific businesses, can also be a lucrative niche. Such customizations are often complex and require ongoing support, creating long-term partnerships and revenue opportunities.

A notable example of this strategy is Red Hat. While CentOS and Fedora Linux are free and open-source, they serve as the upstream, community distro of Red Hat Enterprise Linux (RHEL). Red Hat provides paid support for its enterprise Linux distribution, offering 10-year life cycle support,  targeted at businesses requiring guaranteed support, stability, and security.

Enterprise Version (Open Core)

Developing an enterprise version of the open-source software with premium features including proprietary plugins or extensions that enhance the core product (also known as the “freemium” model) is a common monetization strategy. Businesses are often willing to pay for these add-ons, especially if they streamline their operations or provide essential functionality. 

GitLab uses this strategy to monetize its product. The GitLab Community Edition is open-source and freely available under the MIT license. However, GitLab Inc., provides an enterprise version called GitLab Enterprise Edition which offers additional features like advanced CI/CD capabilities, code quality reports, and security tools.

Hosting/Cloud Version (OpenSaaS)

Providing a cloud-based version of the software can generate recurring revenue through subscription models.

Cloud-based versions of open-source software provide convenience for users who don’t want to manage the software infrastructure themselves. A subscription-based model can generate steady, recurring revenue.

Automattic, the company behind WordPress, offers WordPress.com as a hosted version. While WordPress is a well-known open-source content management system, WordPress.com provides a managed platform with additional features, themes, and plugins compared to the self-hosted version and allows users to choose free or paid plans based on their requirements.

Training & Certification

Professionals seek accreditation and expertise in open-source technologies. Providing educational resources like training sessions and workshops can play a pivotal role in empowering users to better comprehend and make effective use of the product. This will also ensure the formation of an actively engaged professional community around the product. This, in turn, can result in a wider adoption and increased success. One successful example of this strategy is the Linux Foundation.

Dual Licensing

Employing a dual licensing model is a common approach to support free software business models in a commercial environment. In this model, companies distribute the same software under two different license forms: a traditional proprietary license and an open source one, often from the GPL (GNU General Public License) family. 

The company then profits by selling proprietary licenses to commercial operations looking to incorporate the software into their own business, providing flexibility for customers with distinct needs. One well-known example of dual licensing is Oracle’s MySQL database management system. 

Challenges and Caveats During Tech DD

When it comes to Tech DD on open-source products, there are specific areas that require special attention. While some practices are common across both open-source and proprietary code products, the focus and approach differ. Below are some key areas that are carefully assessed during the Tech DD process on open-source products to ensure a thorough evaluation and risk mitigation:

Community Management

Managing an open-source community presents a unique challenge for companies that offer open-source products. Unlike teams working in isolation, community management is a crucial aspect of an open source-driven company and is a continuous effort that can be quite demanding. This process involves aligning company goals with community interests and contributions, presenting the product at conferences, and attracting open-source developers. 

In the Tech DD process, we thoroughly examine strategies for managing community-driven enhancements to ensure the open-source nature attracts users and builds a collaborative environment. Below are some common challenges that we typically observe in such companies

• Active engagement with the community: When issues reported by the community remain unresolved for an extended period without any feedback, or when pending pull requests from the community stay idle with no comments or feedback, it is evident that the company is not actively incorporating the community’s considerations, thereby failing to leverage the unique advantages of being open source. 
• Incorporating community feedback in roadmap planning: Aligning and prioritizing features becomes more challenging when there are diverse stakeholders from community to business, with varying and sometimes conflicting requests. We examine the company’s processes for handling divergent viewpoints in feature planning or strategic decisions, including product discovery and prioritization frameworks in use. This is to ensure that all stakeholders’ perspectives are taken into account and that incoming product requests are given due consideration. The absence of a balance between community requests and other stakeholders (such as enterprise users or the internal marketing team) can be a concerning sign during Tech DD.

In order to mitigate the above risks, companies should utilize practices that ensure:

• Reported issues from the community are resolved in a timely manner or contain constructive feedback with statuses such as: “requires more details”, “being worked on”, “planned”, “duplicate”, etc.
• No abandoned pull request without feedback exists.
• Clearly defined guidelines for collaboration and templates on how to request features or report bugs exist. These guidelines should be communicated to the community in a clear and accessible manner, ensuring that everyone understands how to contribute effectively.

A typical approach to tackle the above challenges is to define a “Community Manager” role. This role takes on various traditional software and product development responsibilities for an open-source community, ensuring that everything runs smoothly. Primary responsibilities of this role include moderating, engaging, and supporting external contributors as well as coordinating with other departments—such as product, engineering, and content marketing—to support community initiatives. The presence of a “Community Manager” role is a positive indicator that the company takes community management seriously. 

Resource Dependency

Assessing the level of reliance on specific resources or expertise that may affect the company’s ability to monetize effectively. This includes evaluating the availability and sustainability of internal staff and external contributors and consultants. Understanding the dependency on these resources helps determine the potential challenges and risks associated with maintaining the product. We measure the impact of all internal and external contributions to the code to ensure that no one entity pushes the product in a specific direction without considering company and community goals. These evaluations are crucial in assuring a robust and healthy community engagement.

One such metric to identify the key contributors and gauge a project’s resilience to this risk of losing crucial knowledge is known as the “Bus Factor”. At TechMiners, we utilize our proprietary algorithm during the Tech DD process to pinpoint key contributors to the code. This aids us in assessing the risk of knowledge loss and ensuring the project’s continuity even in the event of unexpected changes and losing vital contributors.

A potential red flag in this scenario would be the identification of core parts of the product being heavily dependent on a single person (i.e. a bus factor of 1). The risk becomes even more significant if that person is an external contributor, as there is no legal obligation for them to continue working on the product or share their knowledge. They can essentially cease contributing to the code at any time. 

Key knowledge should not be centralized with a single individual, and to mitigate this risk, companies should actively work towards spreading the knowledge of the code, particularly regarding the core parts of the product, within their internal development teams. This can be achieved through proactive documentation, knowledge-sharing sessions, and conducting regular training and workshops.

Quality Assurance

To build a reputable open-source project and attract third-party contributors, it is crucial to implement robust quality assurance processes. As the company and its product gain traction and community contributions increase, effective steering mechanisms become essential to maintain high quality.

During Tech DD, we investigate the company’s strategies for managing and incorporating community-driven enhancements into the product. Our goal is to ensure that the open-source nature not only attracts users but also builds a collaborative environment that ultimately enhances the overall quality of the product. Below are some key areas we assess to ensure the maintenance of high-quality standards in this dynamic collaborative environment:

• Effective quality management of external contributions: We check for clear guidelines on how to contribute to code externally (e.g. defined requirements for creating a pull request). We look for well-defined roles and responsibilities for reviewing external code and providing constructive feedback to guide community collaboration. The role of a “Community manager” becomes significant in facilitating communication between internal teams and external contributors. This continuous engagement enables a robust feedback channel to the community on how they can improve the quality of their contributions.
• Overall quality, readability, and organization of the code base: Furthermore, we recommend archiving or deleting inactive repositories to maintain a clean code base and minimize unnecessary clutter.
• Well-defined quality gates: We look for the implementation of mandatory code formatting, linting, and code analysis tools in the development pipeline. These tools serve as checkpoints to prevent low-quality code from being pushed to the source.
• Extensive test coverage: Having a high level of test coverage, accompanied by automated constraints defined in the development pipeline.

The above practices become particularly crucial in open source products, where managing a diverse range of contributions from developers over whom the company has no control over their coding practices requires careful supervision to uphold code quality in the long run. We want to make sure that what sounds like a great opportunity for high efficiency doesn’t actually end up creating a chaotic mess on its way to a standstill.

Documentation 

The importance of documentation differs significantly between open-source and proprietary products. Open-source products particularly rely on high-quality and up-to-date documentation to attract external contributors and engage the community effectively. It is crucial to have comprehensive documentation readily accessible to absorb these contributors and maintain their interest. Furthermore, transparently outlining the product’s future evolution through clear documentation also plays a vital role in gaining the community’s trust. Therefore, it is essential to provide an accessible roadmap that allows everyone to see the product’s planned direction. 

In the Tech DD process, a concerning observation would be to see outdated documentation or lack of clear ownership for documentation in teams. In order to mitigate the risks, companies should define clear owners for documentation and always have up-to-date documentation available to the community. To mitigate risks, companies should assign clear owners for documentation and consistently maintain up-to-date documentation accessible to the community. Without these measures, the open-source community may not find sufficient motivation (or knowledge) to engage.

Code Architecture and Customization

During the Tech DD process, we delve deep into the code architecture and applied design patterns to ensure that the software is flexible enough to be easily customized and tailored to meet the specific needs of users, without limiting others from doing the same. We analyze topics such as:

• What parts of the code are customizable without requiring to modify the core components, and to what extent?
• Does the product offer a flexible plug-in mechanism, without requiring in-code configurations that allow easy and independent functionality added to the product without modifying the core parts?
• How do the product and tech teams decide which part of the product should be flexible and extensible for customization?

The software’s ability to offer a high level of customization allows it to adapt to the diverse needs of users across different industries and domains. This not only expands the product’s reach but also creates opportunities for growth in new areas. On the other hand, if the software requires major modifications to its core to support common additional functionalities, it can be a major obstacle to future growth. To prevent such issues, during the product discovery phase, companies should prioritize identifying the essential components that users are likely to customize and plan ahead to ensure maximum flexibility for customization in those parts.

Security and Vulnerability Management

It’s important to note that a high level of security on open-source products cannot be taken for granted. Greater transparency could give potential attackers a chance to find weak spots. To help avoid this, we focus heavily on the availability and proper configuration of automated scans as part of CI/CD (e.g. Trivy, dependabot) in our Tech DD process. This will enable the company to identify any possible weaknesses and security threats early and continuously, thereby validating the product’s strength and ensuring its security.

Licensing, Legal Compliance, and IP protection

While licensing is commonly associated with the legal domain, it plays a significant role in a Tech DD as well. To achieve compliance with legal requirements, the following practices are implemented during the Tech DD process:

• Conducting a comprehensive analysis of the third-party open-source licenses utilized by the product.
• Evaluating the company’s adherence to the chosen licenses and assessing its compliance.
• Examining the compatibility of various open source licenses with each other, as well as with any proprietary software involved.
• Assessing the company’s awareness of licensing compatibility, e.g. black/white listing of third-party licenses similar to what Google has. 
• Checking CI/CD pipeline to verify that automated licensing checks of third-party libraries exists 

In addition to assessing standard third-party licensing compliance in code (which is also applicable to products with proprietary code), examining whether the company has implemented measures to protect its competitive advantage and maintain a strong market position is crucial. Different open-source licenses have varying requirements and restrictions. Failing to choose an appropriate license at the beginning can lead to disputes and licensing wars, as seen in the Elastic and Amazon dispute. 

To avoid such disputes, companies should carefully decide on the license from the start and seek guidance from a legal firm to ensure they have made the right decision. For example, in the case of OpenSaaS, it is essential to have appropriate licenses in place to safeguard the company’s intellectual property and prevent competitors from exploiting the open-source code without contributing back to the community.

By incorporating these practices, the Tech DD process ensures that companies with open-source products navigate licensing issues effectively and operate within the bounds of applicable legal regulations. Monitoring solutions such as FOSSA are as essential as security scans for open-source products, and something we especially look for as part of a Tech DD.

Conclusion

Open-source is not just about code; it’s about building ecosystems that thrive on collaboration and openness. The advantages of open source, from community collaboration to increased transparency and flexibility, cannot be overstated. As businesses continue to explore creative monetization strategies and navigate the challenges with finesse, the potential for growth and success in the open-source tech landscape is undeniable.

In the realm of open-source, it is crucial to approach intellectual property with a different perspective in a Tech DD process. Unlike proprietary software, where IP is closely guarded, open-source encourages a different approach. While protecting IP is still important, the focus shifts towards fostering collaboration and allowing the community to contribute and innovate. This requires a delicate balance of managing IP rights while maintaining an environment that encourages open collaboration. Effective community management becomes a vital aspect of open-source projects. Ensuring that contributors feel valued, their ideas are heard, and conflicts are resolved effectively is key to building a thriving open-source community. Moreover, code and documentation quality take on greater significance. Maintaining high standards of code and documentation becomes crucial for ensuring the project’s success and longevity. By placing proper focus on these factors during Tech DD, investors can gain a comprehensive understanding of the company’s position and potential in the open-source ecosystem.

Open-source presents a promising landscape for investors who understand its potential and are willing to navigate its complexities. While the risks are real, so are the rewards. Investing in open-source is not a path for the faint-hearted, but it’s a journey filled with opportunities. 

This is a guest blog post by Kamyar Paykhan, TechMiners .

About the Author:

Kamyar Paykhan works as a Senior Technology Analyst at TechMiners. Kamyar is a seasoned CTO with extensive experience across multiple ventures, specializing in AI, cloud computing, and orchestrating software engineering teams at scale.

About TechMiners:

TechMiners is a data-driven Technology Due Diligence provider, offering trusted advisory services from experienced CTOs and providing in-depth insights through proprietary software.

Find out more about TechMiners here – https://www.techminers.com/