Saying that software is open source describes its license, not the way it is built. Two projects with the same license can live completely different lives: one is maintained by a single person in their spare time, another by a hundred salaried engineers, a third by a consortium of competing companies. Understanding which development model sits behind a project helps you predict how it will evolve, how easy it is to contribute and what risks you take on by adopting it.
The volunteer community project
This is the oldest model and still the most common by number of projects. One or a few authors create a tool for their own needs, publish it and, if it is useful, attract other people who report problems and propose changes.
Typical traits:
- decisions are made by those who write the code, often the founder;
- release timing is irregular and depends on people's availability;
- the barrier to contributing is low, because every bit of help is welcome;
- the main risk is a low bus factor: if the lead maintainer stops, the project stops.
Many foundational libraries live this way for years. They work perfectly well as long as someone has the time and energy; the problem appears when usage grows far faster than the number of people supporting it.
The company-led project
In this model a company owns the project, employs most of the developers and sets the direction. The code is public, but the roadmap is drawn up inside the company and reflects its commercial goals.
Concrete advantages:
- continuous, predictable development with planned releases;
- polished documentation, extensive automated tests, paid support available;
- fast response to vulnerabilities.
Risks to consider:
- the most advanced features may end up in a separate commercial edition;
- the company can change the license, as has happened to several projects that moved to source-available licenses;
- external contributions are accepted only if they fit internal plans, and often require signing a rights assignment or license agreement.
A useful signal: look at who authored the commits over the last twelve months. If almost all of them use the same company's email domain, the project is in practice controlled by that company, whatever the website says.
The foundation-hosted project
When a project becomes infrastructure for many organisations, it is often handed over to a neutral foundation. The foundation holds trademarks and sometimes rights, provides legal and administrative services and enforces governance rules that prevent any single participant from taking control.
In this model:
- decisions go through technical committees or groups of maintainers elected or appointed under written rules;
- employees of different, even competing, companies contribute;
- processes are slower and more formal, but more stable over time;
- a sudden license change is much less likely.
The price is bureaucracy: proposing a major change may require design documents, public discussion and votes.
Hybrid models
In reality the boundaries blur. There are:
- projects that started as community efforts and were later adopted by a company that hired the founder;
- company projects donated to a foundation to gain trust and contributors;
- consortia in which several companies fund a small group of independent maintainers.
Each transition shifts the balance. A donation to a foundation, for example, usually makes the project more open to outside contributions but slows decisions down.
Quick comparison
| Aspect | Community | Company | Foundation |
|---|---|---|---|
| Who decides | Lead maintainers | The company | Bodies with written rules |
| Development pace | Variable | Steady | Steady but slower |
| Ease of contributing | High | Medium | Medium, with procedures |
| Risk of license change | Low if many authors | Higher | Low |
| Risk of abandonment | Higher | Tied to business interests | Low |
How to recognise a project's model
You do not need to trust statements: a few checks in the repository are enough.
- Governance files: look for
GOVERNANCE.md,MAINTAINERSor an equivalent section in the documentation. - Distribution of contributions: contributor statistics show whether the work is concentrated in one person or one organisation.
- Owner of trademarks and domain: this tells you who controls the project's name.
- Agreements required from contributors: an agreement that transfers rights to a company is a strong hint of centralised control.
- Where the roadmap is discussed: in public, on mailing lists and issues, or only in announcements once decisions are made.
In my work, when I assess a component to include in a system that has to last for years, these five checks take a few minutes and often explain more than the «about us» page.
Which model suits you
It depends on your role:
- if you adopt software, a foundation project or one with many independent contributors offers stronger guarantees of continuity; a company project often offers more polish and support;
- if you want to contribute, a community project will give you visibility and responsibility sooner;
- if you start a project, choose deliberately from the outset: deciding later who has the final say is always harder.
In short
- The license says nothing about how a project is developed and governed.
- The three main models are community, company-led and foundation-hosted, with many hybrid variants.
- Each model has different strengths and risks regarding continuity, licensing and openness to contributions.
- Governance, contributors, trademarks and required agreements reveal the real model in minutes.
