A Common Sense Guide for Corporations Using Open Source

Marak's request for a six-figure salary may initially appear unreasonable given the library's small size and limited maintenance requirements. However, evaluating the request solely by lines of code or maintenance hours misses the fundamental issue. The appropriate measure is the actual business impact when the library breaks, as demonstrated by the widespread disruption caused by the intentional infinite loop.

A critical principle emerges from this analysis: when software is critical to business operations, its value should not be measured by implementation complexity but by the impact and distress caused when it fails. This principle serves as a heuristic for determining appropriate financial investment in supporting projects, sponsoring maintainers, or allocating dedicated teams. Corporations cannot reasonably expect to receive all benefits without any costs or obligations. The common corporate practice of avoiding financial support due to institutional greed represents the core problem this article addresses.

While individual corporations might view a six-figure salary as excessive, collective action transforms the equation. One hundred companies sharing this cost through voluntary cooperation¹ would reduce each organization's contribution to a negligible amount for multi-billion dollar companies. This collective funding model establishes groundwork for the governance frameworks discussed later in this article.

Based on years of experience within free software and open-source communities and conversations with numerous maintainers, my speculation is that even modest recognition would have prevented this incident. A single corporation providing $10,000 annually would likely have been sufficient for Marak to feel appreciated and motivated to continue maintaining the library. While the library is small and relatively simple to implement, corporations chose to depend on it rather than building their own solutions. This dependency creates responsibility.

Before evaluating project characteristics, corporations must assess the business role and criticality of the open-source software within their operations. This assessment determines the acceptable risk levels and required investment in governance.

Classifying project usage is essential for understanding the actual business impact when failures occur. Different failure scenarios create distinct consequences: inability to meet compliance requirements may result in regulatory penalties or legal liability, fully or partially stopped operations directly affect revenue generation and customer commitments, disrupted development teams delay critical updates and security patches, and compromised security increases the risk of data breaches with potentially catastrophic financial and reputational damage. This classification informs governance investment decisions and ensures appropriate risk mitigation strategies align with potential business impact.

The following categories represent different levels of business dependency and usage patterns for open-source projects.

Software that forms the foundation of the business product or service delivery. For example, a backup hosting vendor depends critically on Proxmox Backup Server, ZFS or Btrfs filesystems, and the underlying Debian operating system. Digital certificate management represents another critical dependency, with tools like Certbot and ACME clients essential for automating TLS certificate provisioning. Small and medium businesses, along with numerous open-source projects, depend heavily on Let's Encrypt as their certificate authority.

Without functioning certificate infrastructure, HTTPS services become inaccessible, breaking web applications, APIs, and secure communications. Failure of these components directly disrupts the core business offering.

Software required for business operations to continue, typically included in Business Continuity Planning programs. These systems must maintain high availability and have defined recovery procedures. Failures impact revenue generation or regulatory compliance. Examples include VPN solutions like OpenVPN or WireGuard for secure remote access, multi-factor authentication systems, Single Sign-On solutions such as Keycloak providing OIDC/SAML authentication, directory services like OpenLDAP or FreeIPA for centralized user management, and database systems like PostgreSQL or MySQL that store critical business data. Loss of these services can halt employee productivity, prevent customer access, or violate compliance requirements.

Tools essential for the development organization's ability to integrate, build, test, and deploy code. Examples include Git for version control, build systems like Make or Gradle, CI/CD platforms such as Jenkins or Drone CI, code hosting platforms like Gitea for self-hosted solutions or GitLab which offers both paid support and SaaS plans, continuous deployment tools like ArgoCD or Flux, and container registries such as Harbor. While not directly customer-facing, these tools affect the organization's ability to develop and deploy software. In environments with heavy Infrastructure as Code usage, failure of these systems can prevent developers from pushing critical changes, deploying security fixes, or restoring services during incidents, effectively blocking the organization's ability to respond to production issues.

Software critical to specific operational domains, including observability and incident response capabilities. Examples include monitoring systems like Prometheus for metrics collection, logging platforms such as Loki or Elasticsearch for log aggregation and analysis, alert management systems like Alertmanager for notification routing, and visualization dashboards like Grafana for monitoring system health and detecting anomalies. Infrastructure orchestration tools like OpenTofu (Terraform) and Ansible manage deployment automation, while container orchestration platforms like Kubernetes and OpenShift handle application lifecycle. Virtualization platforms such as Xen, QEMU, and Proxmox provide the foundation for infrastructure management.

Failure of these systems can blind operations teams to production issues, prevent incident detection and response, block infrastructure changes, or cause cascading failures in automated systems. While these tools serve specific operational domains, their failure can effectively halt business operations by preventing teams from detecting, diagnosing, or resolving production incidents.

Libraries, utilities, and development tools that provide supporting functionality and can be easily replaced with alternatives. Examples include IDEs and editors like VS Code, Emacs, or Vim where developers can switch between tools without blocking code delivery, YAML parsing libraries where multiple equivalent options exist such as js-yaml, yaml, or yamljs in the Node.js ecosystem, and logging formatters where numerous interchangeable implementations are available. These components warrant less governance investment due to their replaceability and minimal impact on operational continuity.

Mature open-source projects typically demonstrate established governance structures, strong community engagement, and proven operational stability. These projects present lower business risks due to their polished codebases, active maintenance, and diverse contributor bases. Organizations often find that mature projects already have corporate sponsors or commercial entities providing support through the operational models discussed later in this document. The presence of multiple companies investing in and depending on a project signals reduced single-point-of-failure risk and sustainable long-term development.

When evaluating an open-source project for adoption, consider the following maturity indicators:

Security assessment is critical when evaluating open-source dependencies. Beyond examining the code itself, organizations must assess the project's vulnerability to supply chain attacks, including compromised developer accounts, malicious dependency injection, and unauthorized code modifications. The effectiveness of developer security controls such as two-factor authentication enforcement, commit signing requirements, and rigorous code review processes directly impacts the project's resilience against targeted attacks. Response speed and accuracy to security threats, including CVE disclosure handling and patch deployment timelines, reveal the project's security maturity. Supply chain security practices such as dependency lock files, automated vulnerability scanning, and proper dependency management demonstrate proactive risk mitigation. A thorough security evaluation should examine:

scorecard --repo=https://github.com/crossplane/crossplane

RESULTS
-------
Aggregate score: 8.6 / 10

Check scores:
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
|  SCORE  |          NAME          |             REASON             |                                               DOCUMENTATION/REMEDIATION                                               |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | Binary-Artifacts       | no binaries found in the repo  | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#binary-artifacts       |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 8 / 10  | Branch-Protection      | branch protection is not       | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#branch-protection      |
|         |                        | maximal on development and all |                                                                                                                       |
|         |                        | release branches               |                                                                                                                       |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | CI-Tests               | 12 out of 12 merged PRs        | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#ci-tests               |
|         |                        | checked by a CI test -- score  |                                                                                                                       |
|         |                        | normalized to 10               |                                                                                                                       |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 0 / 10  | CII-Best-Practices     | no badge detected              | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#cii-best-practices     |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | Code-Review            | 12 out of last 12 changesets   | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#code-review            |
|         |                        | reviewed before merge -- score |                                                                                                                       |
|         |                        | normalized to 10               |                                                                                                                       |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | Contributors           | 34 different organizations     | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#contributors           |
|         |                        | found -- score normalized to   |                                                                                                                       |
|         |                        | 10                             |                                                                                                                       |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | Dangerous-Workflow     | no dangerous workflow patterns | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#dangerous-workflow     |
|         |                        | detected                       |                                                                                                                       |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | Dependency-Update-Tool | update tool detected           | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#dependency-update-tool |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | Fuzzing                | project is fuzzed with         | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#fuzzing                |
|         |                        | [GoBuiltInFuzzer]              |                                                                                                                       |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | License                | license file detected          | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#license                |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | Maintained             | 30 commit(s) out of 30 and 13  | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#maintained             |
|         |                        | issue activity out of 30 found |                                                                                                                       |
|         |                        | in the last 90 days -- score   |                                                                                                                       |
|         |                        | normalized to 10               |                                                                                                                       |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| ?       | Packaging              | no published package detected  | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#packaging              |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 8 / 10  | Pinned-Dependencies    | dependency not pinned by hash  | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#pinned-dependencies    |
|         |                        | detected -- score normalized   |                                                                                                                       |
|         |                        | to 8                           |                                                                                                                       |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 9 / 10  | SAST                   | SAST tool detected but not run | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#sast                   |
|         |                        | on all commmits                |                                                                                                                       |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | Security-Policy        | security policy file detected  | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#security-policy        |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| ?       | Signed-Releases        | no releases found              | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#signed-releases        |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 0 / 10  | Token-Permissions      | non read-only tokens detected  | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#token-permissions      |
|         |                        | in GitHub workflows            |                                                                                                                       |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|
| 10 / 10 | Vulnerabilities        | no vulnerabilities detected    | https://github.com/ossf/scorecard/blob/376f465c111c39c6a5ad7408e8896cd790cb5219/docs/checks.md#vulnerabilities        |
|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|

This model involves hiring a third-party organization with expertise in the specific open-source software your corporation uses. This is the most expensive support option but provides direct access to expert support teams experienced in resolving issues. These companies offer timely responses, minimize downtime, and increase productivity. Service Level Agreements (SLAs) provide security by guaranteeing response times and aligning expectations between both parties.

The primary disadvantage is cost. Specialized support requires significant investment, particularly challenging for smaller organizations. While this provides the clearest governance structure, not all open-source projects have companies offering specialized support services.

Examples of companies operating under this model include Red Hat (for Red Hat Enterprise Linux, OpenShift, Ansible) and Canonical (for Ubuntu, Kubernetes, OpenStack). These companies provide enterprise support for their own distributions and products built on open-source software.

This model provides ongoing financial support to open-source maintainers working on software your corporation depends on. Sponsorship establishes a relationship between the corporation and maintainer, offering several advantages: direct communication channels, ability to influence development priorities, significantly lower costs than hiring specialized companies or internal teams, and contribution to long-term project sustainability. This approach also generates positive public relations by demonstrating genuine commitment to the open-source ecosystem.

Corporations must understand that sponsorship does not grant control over the project. Maintainers retain autonomy over technical decisions, priorities, and roadmap. Setting clear expectations upfront prevents misunderstandings and maintains healthy working relationships. Benefits may not materialize immediately, particularly when operational incidents are infrequent. Sustainable sponsorship requires ongoing financial commitment rather than opportunistic engagement only during crises.

This model involves hiring dedicated employees specifically responsible for maintaining and supporting the open-source software your corporation depends on. These in-house maintainers become your internal experts who understand both your organization's needs and the open-source project's architecture.

The cost structure differs from specialized company support and depends on several factors: the number of dedicated employees required, their salary expectations, and the target SLA. While this may initially seem expensive, in-house maintainers can typically provide faster response times since they work exclusively for your organization rather than supporting multiple clients simultaneously.

Key benefits include direct control over support processes, development of deep in-house expertise, and the ability to customize the software to your specific needs. This internal knowledge base provides long-term strategic value, reducing dependency on external vendors and enabling faster decision-making.

Having in-house expertise enables rapid security response. Internal maintainers can patch vulnerabilities in the software and its dependencies without waiting for upstream fixes, significantly reducing exposure windows during security incidents. Organizations can also maintain internal forks, allowing them to preview upcoming features, test experimental changes in controlled environments, and roll out modifications independently of the upstream release schedule. This autonomy proves particularly valuable for organizations with specific compliance requirements or unique operational constraints.

The primary challenge lies in recruitment. This approach requires hiring developers who already possess expertise in the relevant open-source project, or hiring experienced developers willing to invest time developing that specialized knowledge. Finding qualified candidates with the right technical background can be difficult, particularly for specialized or niche projects.

Beyond recruitment, this model faces all the standard logistics challenges of managing a team: scheduling vacations, handling sick leave, managing unpaid time off, coordinating training periods, and ensuring knowledge continuity during transitions. Corporations expecting high SLAs with only a small number of maintainers set themselves up for failure. A team of one or two maintainers cannot realistically provide 24/7 coverage or maintain rapid response times during absences. Achieving enterprise-grade SLAs typically requires a larger team, significantly increasing costs.

This reality makes the approach generally unfeasible for medium and smaller businesses. The substantial ongoing investment required to maintain an adequately sized team often exceeds their budget constraints. For these organizations, the specialized company support model discussed earlier frequently proves more practical and cost-effective, as these vendors distribute operational costs across multiple clients and maintain larger support teams capable of meeting SLA commitments.

This model allocates a portion of existing developers' time to contribute code and resources to open-source projects the organization depends on. Rather than hiring dedicated maintainers or paying for external support, corporations leverage their current engineering workforce to participate in upstream development.

Benefits extend beyond direct technical contributions. Organizations gain increased influence over development processes and build internal expertise in critical dependencies. Contributing to open-source generates positive public relations and demonstrates authentic community engagement. For developers, this provides opportunities to build public portfolios, develop recognition in the open-source community, and increase job satisfaction through meaningful work beyond internal corporate projects.

However, this approach presents significant challenges. While less resource-intensive than hiring a dedicated internal team, corporations must still invest substantial time in onboarding. Developers need adequate time to learn the project architecture, understand community norms, and become proficient contributors. Corporations cannot expect immediate results or miracles; meaningful contributions require developers to first build expertise and credibility within the project community.

The model demands sustained allocation of developer time away from internal priorities, proving particularly challenging for smaller organizations with limited engineering capacity. Control over project direction remains limited, as open-source communities maintain their own priorities and governance structures. Navigating these community dynamics requires time and experience that cannot be rushed.

Corporations must maintain realistic expectations. While less expensive than hiring dedicated maintainers, part-time contributors cannot match the output or expertise of full-time maintainers. Within the same timeframe, a full-time maintainer will become proficient and capable much faster than a part-time contributor. Developers splitting time between internal work and open-source contributions face context switching costs that compound the learning curve.

Even if corporations attempt to maintain the same SLA expectations as they would with a dedicated internal team, part-time contributors face constant conflicts with other internal priorities. Urgent deliveries, production incidents, and internal deadlines will inevitably take precedence over open-source contributions, making consistent response times unrealistic. This model remains less resource-intensive than maintaining a full dedicated team for support and maintenance, but it also delivers correspondingly lower impact and influence within the project. Success requires long-term commitment measured in months or years, not weeks.

Direct use of the upstream project without modifications. Requires a compatible operational model (specialized company support, sponsoring maintainers, dedicated internal team, or part-time contributors) but minimal technical overhead. This approach depends entirely on upstream development and release cycles.

Using a project from upstream without any governance model represents significant risk, as demonstrated by the colors library incident. For low-impact projects with minimal external dependencies, which reduce vulnerability surface area and update frequency, and low complexity, which requires infrequent fixes, a technical mitigation involves using dependency lock files to pin specific versions.

Lock file mechanisms across programming languages:

• Nix: flakes
• Python: Poetry, UV
• JavaScript/Node.js: Yarn, package-lock.json
• Java: Maven's pom.xml with dependency management, Gradle lock files
• PHP: composer.lock
• Rust: Cargo.lock
• Go: go.mod
• Ruby: Gemfile.lock

These tools provide reproducible builds and prevent unexpected upstream changes from affecting production systems.

Maintaining a mirror of the upstream project for supply chain security and availability guarantees. This approach requires some maintenance work to keep the mirror synchronized but does not involve code modifications. Useful for ensuring availability if upstream disappears or for organizations with strict supply chain requirements. Compatible operational models include dedicated internal teams or part-time contributors for mirror maintenance.

When using automatic synchronization for the fork, this approach only prevents harm from upstream project deletion but does not protect against malicious changes like the colors library incident. Automatic mirroring without review provides no defense against intentionally broken code or compromised maintainer accounts.

Maintaining a fork that includes custom patches, security fixes, or feature modifications. Requires dedicated internal maintainers who understand both the upstream codebase and organizational needs. This approach provides control over security response times and feature deployment while still benefiting from upstream improvements through regular rebasing. The operational model must be a dedicated internal team, as the complexity of maintaining patches and rebasing against upstream requires full-time focus and expertise.

Building and maintaining a complete implementation independently. This approach provides maximum control over all aspects but requires the heaviest maintainer burden. Appropriate for simple libraries where the implementation effort is minimal, or when requirements diverge significantly from any existing project.

In this model, the project is no longer open-source adoption but becomes a standard internal project within the company's portfolio, even if the company chooses to publish it as open source. It falls under the same governance structures, resource allocation, and maintenance practices as any other internal software project. The operational model is inherently a dedicated internal team.