How Open-Source Software Development Works and Who Funds It

96% of the World's Servers Run on Software You Can Read, Modify, and Distribute for Free

Linux powers approximately 96% of the top one million web servers, 90% of cloud infrastructure including AWS and Google Cloud, the Android OS (on roughly 3 billion devices), and the International Space Station. Linux is open-source software — its source code is publicly available, and anyone may read, modify, and distribute it under the terms of its license. Open source is not a charitable model or an alternative to professional software development: it is the backbone of the global digital economy. The Linux Foundation estimates that freely available open-source software would cost $8.8 trillion to rebuild from scratch. Understanding how this ecosystem is produced — who contributes, how coordination works, who funds it, and what licenses govern it — explains one of the most consequential governance experiments in modern technology.

The Development Model: Distributed Collaboration at Scale

Open-source development is coordinated primarily through version control systems — particularly Git, itself an open-source tool created by Linus Torvalds in 2005. GitHub (acquired by Microsoft in 2018 for $7.5 billion) hosts over 420 million repositories and serves as the dominant platform for open-source collaboration globally. GitLab and Bitbucket serve similar functions.

The workflow for contributing to most projects follows a recognizable pattern: a contributor forks the project repository (creates their own copy), makes changes in a feature branch, and submits a pull request asking the maintainers to review and merge the changes. Maintainers — typically the most trusted long-term contributors — review code for correctness, security, style conformance, and architectural fit. This peer review process is central to open-source quality assurance and knowledge transfer.

Governance Models in Open Source

• Benevolent Dictator for Life (BDFL): A single founder or leader retains final authority over the project direction. Python (Guido van Rossum until 2018) and Linux (Linus Torvalds) operate under this model.
• Meritocracy / Committer model: Decision-making authority expands based on demonstrated quality contributions. Apache Software Foundation projects use this model.
• Foundation governance: A non-profit foundation (Linux Foundation, Apache Foundation, Eclipse Foundation) provides legal structure, trademark management, and neutral governance for major projects.
• Company-controlled open source: A single company publishes code under an open-source license but controls the roadmap. Common for commercial open source (MongoDB, Elasticsearch, HashiCorp products).
• Democratic committee: A steering committee (often called a Technical Steering Committee or TSC) makes decisions by voting. Kubernetes, under the CNCF, uses this model.

Licensing: The Legal Architecture of Open Source

An open-source license is the legal instrument that defines what recipients can do with the source code. Without a license, code is legally copyrighted by default and cannot be used by others. The Open Source Initiative (OSI) maintains a list of OSI-approved licenses; not all "open" licenses qualify as true open-source licenses under their definition.

Who Contributes — and Why

Open-source contribution is not primarily altruistic. Studies of contributor motivation show a mix of professional development, reputation building, intrinsic interest, and increasingly, paid work. The 2022 Linux Kernel Development report found that approximately 80% of kernel contributions came from developers employed by companies — Intel, Google, Red Hat, AMD, Facebook, Samsung, and others — who contribute as part of their paid roles because their products depend on Linux. This corporate-funded voluntary coordination model produces software of remarkable quality and scale.

Individual volunteers remain essential, particularly for smaller projects and for the specialized domain knowledge that companies don't fund internally. A 2021 Linux Foundation/LAEA study found that the critical open-source projects most depended on by commercial software had a median of just two maintainers — a concentration of responsibility that creates significant sustainability and security risk, as the Log4Shell and XZ Utils backdoor incidents demonstrated.

Funding: The Sustainability Problem

Open source's sustainability is a recognized systemic concern. The 2014 Heartbleed vulnerability — a critical flaw in OpenSSL, the cryptographic library securing nearly all HTTPS traffic — was discovered in software maintained by two developers, one of whom was effectively a volunteer. The incident prompted the creation of the Core Infrastructure Initiative (now the OpenSSF — Open Source Security Foundation), which channels corporate funding to security-critical projects.

• Foundations: The Apache Software Foundation, Linux Foundation, and CNCF pool corporate membership fees to fund infrastructure and staff for hosted projects.
• GitHub Sponsors and Open Collective: Platforms that enable direct financial support from users and companies to individual maintainers and projects.
• Open Core model: Companies publish a free community edition and charge for enterprise features, cloud hosting, or support (GitLab, Elasticsearch pre-license change, MariaDB).
• Dual licensing: Code is available under GPL for free; a commercial license is required for proprietary use (MySQL, Qt).
• Government funding: The European Commission has funded open-source public goods; the U.S. Cyber Trust Mark and CISA open-source security initiatives represent growing government interest in sustaining critical infrastructure.

The Tension with Commercial Interests

The late 2010s and early 2020s saw several high-profile open-source companies change their licenses to restrict cloud providers from offering managed versions of their software without contributing back. MongoDB switched to SSPL in 2018; HashiCorp switched Terraform to BUSL in 2023 (prompting the OpenTofu fork); Elasticsearch moved to Elastic License. These "source-available" licenses are not OSI-approved open-source licenses but allow users to inspect and modify code. The backlash from these changes — and the forks they prompted — illustrates the social contract underlying open source: the community's labor and trust are premised on enduring license freedoms, and attempts to extract value while limiting contribution produce lasting credibility damage and often successful competing forks.