What open source means

Open source software is software whose source code is publicly available. Anyone can read it, copy it, modify it, and distribute it, subject to the terms of its license. This is in contrast to proprietary software, where the source code is kept secret and controlled by the company that made it.

The term covers a wide range of projects: operating systems (Linux), programming languages (Python, Rust), web frameworks (React, Django), databases (PostgreSQL), developer tools (Git, VS Code), and millions of smaller libraries that do specific things like parse dates, resize images, or send HTTP requests.

Most software built today depends on open source code. When a developer installs a library from the internet to use in their project, they are almost always pulling in open source software.

Package registries

Package registries are centralized repositories where developers publish and download open source libraries. Each programming language ecosystem has its own:

• npm is the registry for JavaScript and TypeScript. It hosts over two million packages.
• PyPI (Python Package Index) serves the Python ecosystem.
• Packagist is the registry for PHP, used through the Composer package manager.
• crates.io is Rust's package registry.
• RubyGems serves Ruby, NuGet serves .NET, Maven Central serves Java.

When a developer runs a command like npm install lodash or pip install requests, their package manager downloads the library (and all of its dependencies) from the relevant registry. These registries are free to use, both for publishing and downloading. Most are run by nonprofit organizations or funded by corporate sponsors.

A single project can pull in hundreds or thousands of packages through transitive dependencies — packages that depend on other packages, which depend on other packages.

Permissive vs copyleft licenses

Not all open source licenses work the same way. The two main categories are permissive and copyleft.

Permissive licenses (MIT, Apache 2.0, BSD) let you do almost anything with the code. You can use it in commercial products, modify it, and distribute it. The main requirement is that you include the original license text. Companies generally prefer permissive licenses because they impose few restrictions.

Copyleft licenses (GPL, LGPL, AGPL) require that if you distribute software that includes copyleft-licensed code, you must also release your source code under the same license. The GPL was designed to ensure that software derived from open source remains open source. The AGPL extends this to software running on servers — if users interact with AGPL-licensed code over a network, the source must be made available.

In practice, this means companies often avoid GPL-licensed libraries in their proprietary products, while MIT-licensed code ends up everywhere with minimal friction.

How maintainers work

Most open source software is maintained by individuals, not companies. A maintainer is the person (or small group of people) who reviews proposed changes, fixes bugs, responds to issues, publishes new versions, and makes decisions about the project's direction.

Some maintainers are employed full-time to work on open source by a company that depends on the software. Others are sponsored through programs like GitHub Sponsors or Open Collective. But the majority, especially for smaller libraries, are unpaid volunteers working in their spare time.

Maintaining a popular library is a significant amount of work. It involves triaging bug reports, reviewing code contributions from strangers, writing documentation, handling security vulnerabilities, and managing releases. This work is ongoing and has no natural end point.

The funding problem

A large portion of the world's digital infrastructure depends on open source software that is maintained by people working for free. Companies generating billions in revenue routinely build their products on top of libraries maintained by a single developer in their free time.

This creates a structural problem. The people who maintain critical software often have no financial incentive to keep doing it. They burn out, lose interest, or simply cannot afford to keep spending unpaid hours on a project that millions of people depend on.

The OpenSSL library, which handled encryption for most of the internet, was famously maintained by a handful of people with minimal funding before the Heartbleed vulnerability in 2014 drew attention to the problem. Similar situations have played out with other foundational projects.

When a maintainer walks away, the software does not disappear immediately. But it stops receiving security patches, bug fixes, and updates for compatibility with new systems. Over time, it becomes a liability for everyone who depends on it.

How companies use open source

Virtually every software company uses open source extensively. A typical commercial web application might depend on hundreds of open source packages — a web framework, a database driver, an authentication library, image processing tools, date formatting utilities, and so on.

Companies benefit from this arrangement enormously. They get free, battle-tested software that would cost millions to build in-house. In return, some companies contribute back by employing maintainers, sponsoring projects, or open sourcing their own tools. Many contribute nothing.

The economic imbalance is significant. A library that saves a company thousands of engineering hours often has a maintainer who has never been compensated for their work.

The xkcd "dependency" problem

There is a well-known xkcd comic (number 2347) that depicts all of modern digital infrastructure as a tower of blocks, with one small block near the bottom labeled "a project some random person in Nebraska has been mass maintaining since 2003."

This is not an exaggeration. Real examples exist across every ecosystem. A single JavaScript package called left-pad, which consisted of 11 lines of code, briefly broke thousands of builds across the internet when its author removed it from npm in 2016. Core cryptographic libraries, compression tools, and date-handling packages are often maintained by one or two people.

The problem is not that these projects are small. It is that no one notices them until something goes wrong. Dependencies buried deep in the dependency tree are invisible to most developers who rely on them.

GitHub stars, downloads, and what they actually measure

GitHub stars are a rough measure of interest. A user clicks a star button to bookmark a project or signal approval. Stars correlate loosely with popularity but do not indicate actual usage. A project can have 50,000 stars and minimal real-world adoption, or 200 stars and be a critical dependency in production systems worldwide.

Download counts from package registries are closer to measuring real usage, but they are inflated by CI/CD pipelines, mirror servers, and bots. A package with ten million weekly downloads on npm may have a fraction of that number of actual human users.

Neither metric measures quality, maintenance status, or security. A widely-downloaded package can be abandoned. A highly-starred project can have known vulnerabilities. These numbers are useful directional signals, but they are frequently misinterpreted as definitive measures of a project's health.

How packages get adopted

A package gets adopted when developers find it, evaluate it, and decide to use it. Discovery happens through several channels: search results on package registries, recommendations in blog posts and tutorials, mentions in conference talks, word of mouth in teams, and appearing as a dependency of another popular package.

Documentation is one of the strongest factors in adoption. A well-documented library with clear examples and a getting-started guide will be chosen over a technically superior alternative that is poorly explained.

Ecosystem fit matters. A React component library is only useful to React developers. A Python library that depends on a specific version of NumPy limits its audience. Packages that integrate smoothly with widely-used tools and frameworks spread faster.

First-mover advantage is real. Once a package is established as the default choice in its category, it is difficult to displace even if better alternatives exist, because existing projects already depend on it and developers are familiar with its API.

The maintenance burden

Maintaining a popular open source project means handling a constant stream of demands:

• Issues: Bug reports, feature requests, and questions from users. Popular projects receive dozens or hundreds of issues per month. Many are duplicates, poorly described, or out of scope.
• Pull requests: Code contributions from outside developers. Each one must be reviewed for correctness, style, compatibility, and security. Reviewing code is time-consuming and requires deep knowledge of the project.
• Security patches: When a vulnerability is discovered, maintainers are expected to fix it quickly, often under public pressure.
• Breaking changes: As programming languages and ecosystems evolve, libraries must be updated to stay compatible. Major version upgrades of dependencies can require significant rework.
• Documentation: Keeping docs accurate and up to date as the project changes.

This work compounds over time. The larger and more popular a project becomes, the more maintenance it requires, but the number of people doing the work rarely scales proportionally.

Corporate open source

Some of the most widely used open source projects were created and are maintained by large companies. React was created by Facebook (Meta). Kubernetes was created by Google. TypeScript was created by Microsoft. Go was created by Google. Swift was created by Apple.

Companies release open source software for several reasons:

• Adoption and ecosystem: Making a tool free drives adoption, which creates an ecosystem of developers, plugins, and integrations that benefits the company.
• Recruiting: Open source projects attract talent. Developers who use a company's open source tools are more likely to want to work there.
• Standardization: If a company's tool becomes the industry standard, the company has influence over the direction of the technology.
• Shared maintenance costs: By open sourcing a project, the company can receive contributions from outside developers, reducing its own maintenance burden.

Corporate open source is strategic, not altruistic. Companies open source the tools that benefit them to have widely used, and keep proprietary the parts that generate revenue.

Open source sustainability models

Several models exist for funding open source work:

• Sponsorship: Individuals or companies pay maintainers directly, often through GitHub Sponsors, Open Collective, or Patreon. This works for some projects but rarely provides a full-time income.
• Dual licensing: The project is available under a copyleft license for free, but companies that want to use it without copyleft obligations can purchase a commercial license. MySQL and Qt have used this model.
• Open core: The core software is open source, but premium features, hosting, or support are sold commercially. GitLab, Elastic, and Redis have used variations of this model.
• Consulting and support: Maintainers sell consulting, training, or support contracts to companies that use their software. Red Hat built a large business on this model with Linux.
• Managed hosting: The maintainers or a related company offer a hosted version of the software as a service. This is increasingly common, though cloud providers sometimes compete by offering their own hosted versions of the same open source software.
• Grants: Foundations and government programs occasionally fund open source work. The Linux Foundation, the Apache Software Foundation, and sovereign tech funds in some countries provide grants.

No single model works universally. Many maintainers combine several, and most open source projects have no funding at all.

Why developers contribute

People contribute to open source for a range of practical reasons:

• Scratching their own itch: A developer needs a tool or library that does not exist, builds it, and shares it. This is how many open source projects start.
• Learning: Contributing to open source is an effective way to learn new technologies, read well-written code, and get feedback from experienced developers.
• Reputation: A strong open source portfolio is visible proof of competence. It can be more convincing to potential employers than a resume.
• Job prospects: Many developers have been hired directly because of their open source work. Some companies specifically recruit from the contributor communities of projects they use.
• Professional necessity: Developers who find a bug in a library they depend on may fix it upstream rather than maintain a private patch.
• Community: Some developers enjoy the collaborative aspect of open source — working with people across the world on shared problems.

The motivations are mostly practical. Open source contribution is not charity work. It is a mix of self-interest, professional development, and genuine interest in building useful software.