Open source

Open source is a model for delivering software (Private) in which the source code is available, either freely or for a charge. Unlike proprietary software development models, it's common for end users of open source projects to be deeply involved in their development, creating tighter feedback loops.


By default, all code is subject to copyright. Unlicensed code can't be incorporated into a project without explicit approval from the owners.

For a summary of common licenses, see Choose a License.

Public domain

Code contributed to the public domain, the realm embracing property rights that belong to the community at large, aren't subject to copyright and can be used freely.

Changing licenses

Changing a project's license is only possible with permission from all contributors. If permission cannot be obtained, the source code for the affected components will need to be rewritten.


Forges are centralised places which host the source code, issue tracking and communications for projects.

Other projects (e.g. Linux) follow a decentralised model, performing development across many personal forked repositories and sharing patches via mailing lists.


  • Maintainers direct the project, triage issues and review pull requests, merging those aligned with the project's goals.
  • Committers make contributions to the project. It's now commonplace for these contributions to be made via pull requests from forks of the project rather than by granting commit access directly to the project's canonical home.

Governance models

Small maintainer

The vast majority of open source projects are maintained by individuals who fulfil all project roles.


In the Benevolent Dictator for Life model a single individual holds the decision making authority.

Ashley Williams:

BDFLs work if they see themselves as facilitators, not controllers.

Most notably:

  • Guido in the Python community.
  • Ryan Dahl in early Node.js.
  • Larry Wall in Perl.
  • Linus Torvalds in Linux.
  • Matz in Ruby.

By committee

Larger projects like Node.js have large-scale management structures that govern administrative portions of the project.

  • The Board of Directors contains representation from major Node.js sponsors, as well as elected community members. They can make decisions on how the project spends its revenue, e.g. on travel and conference attendance. They can't make technical decisions, by design, but may decide on the project's license.
  • The Technical Steering Committee sets release dates, manages codes of conducts, decides on code standards and manages the contributors' relationships with the foundation.
  • Most technical decision making is delegated to Collaborators.
  • Working Groups self-organise and and do most day-to-day development, e.g. build, release, libuv.

Business models

Commonly, projects are distributed through an open community model. Projects may be commercialised through:

  • Support contracts allow the project to be distributed freely, with organisations purchasing support from the maintaining organisation.
  • Advertisement partnerships allow projects like Firefox to collect funding.
  • Open core allows the core of a project to remain open whilst separate modules are distributed only to paying members.
  • SaaS products offer support and hosting in addition to the source code, allowing you to "host your own".
  • Sponsorship, either of projects or individuals, allows organisations and individuals to support the projects that enable their businesses.