Examples: Rust (present day) , Apache HTTPD

Licensing: Can be copyleft or non-copyleft.

Community standards: Very welcoming to contributors, to the point of having formalized systems for onboarding newcomers.

Component coupling: This archetype applies to many technically different projects, so the component organization could go any number of ways.

Main benefits: Enables large-scale collaboration. Community can become selfsustaining, which allows the original sponsoring organization some flexibility in deciding how involved to stay.

Typical governance: Group-based and more or less democratic. In practice, most decisions are made by consensus, but voting is available as a fallback when consensus cannot be reached. There is usually a formal committer group to approve contributions and anoint new committers.

Examples: Android, Chromium

Licensing: Almost always non-copyleft.

Community standards: In general, the lead company does not put much emphasis on welcoming or nurturing contributors; exceptions may be made for strategically important organizational partners.

Component coupling: Tightly coupled modules, to allow the lead company to market one unified product.

Main benefits: Can drive industry adoption of a technology that is strategically important to your organization.

Typical governance: Maintainer-led by a group within the lead company.

  Multi-Vendor Infrastructure

Examples: Kubernetes, Open Stack

Licensing: Typically non-copyleft, given that many members of the community are likely to maintain proprietary forks of the core product.

Community standards: Welcoming, but formal, and often difficult for individual contributors to enter. Participation takes a high level of resources.

Component coupling: Loosely-coupled modules joined by de facto standards.

Main benefits: Fosters collaboration with partner organizations to solve shared problems.

Typical governance: Formal tech committee, with membership by each of the major contributing companies.

Examples: OpenSSL, WebKi

Licensing: Typically non-copyleft.

Community standards: Welcoming, and specifically amenable to one-time contributions.

Component coupling: Standalone, decoupled from one another and the downstream projects that pull them in.

Main benefits: Connections to many downstream dependee projects offers insight into market and usage trends, and can provide openings to potential partners.

Typical governance: Informal, maintainer-led, committer groups.

Examples: Wordpress, Drupal, Joomla

Licensing: Can be either copyleft or non-copyleft. When copyleft, decisions must be made about whether the core interfaces (and maintainer-promulgated legal interpretations) encourage or discourage proprietary plugins.

Community standards: Welcoming, often with structures designed to promote participation and introduce new contributors

Component coupling: Loosely coupled modules, frequently in a formal plugin system.

Main benefits: Builds a sustainable ecosystem in which the founding organization retains strong influence.

Typical governance: Benevolent dictatorship, with significant willingness to compromise to avoid forks.

Examples: Meteor, Signal

Licensing: Usually non-copyleft, but may be copyleft under certain circumstances.

Community standards: Difficult to enter; focused on the core group.

Component coupling: Tight, in order to ship one core product.

Main benefits: Achieves a quick, focused effect on a specific area; if successful, can co-opt competition.

Typical governance: Maintainer-led by the founding group.

Examples: libssl, libmp4

Licensing: Usually non-copyleft.

Community standards: High barriers to entry, largely because contributors are expected to be experts.

Component coupling: Tightly coupled. These libraries are structured to do one thing well.

Main benefits: Ensures a shared solution to a specific technical problem. Cooperation at the engineering level can lead to new organizational partnerships.

Typical governance: Formal committer group that can grant committing privileges to new contributors.

Examples: Firefox, LibreOffice, MediaWiki (due to Wikipedia instance)

Licensing: Non-copyleft generally, but may be copyleft depending on the project’s business strategy.

Community standards: Fully open, but relatively brusque for the vast majority of users. Because of the large number of users, these projects evolve toward a users-helping- users pattern, rather than the development team serving as user support. The team itself can often seem somewhat distant or unresponsive.

Component coupling: Mix and match packages. This archetype can support a number of different component packaging techniques.

Main benefits: Large user base can help the project be broadly influential.

Typical governance: Technical committee and/or formal committer group.

Examples: MongoDB, Hypothes.is, Coral

Licensing: Can be copyleft or non-copyleft; copyleft is often used to discourage competition from forking.

Community standards: Users and contributors have input to roadmap, though they may not contribute directly.

Component coupling: Tightly coupled.

Main benefits: User community — including deployers and commercial support vendors — tends to be long-term, which provides both stability and word-of-mouth marketing to the project.

Typical governance: Maintainer-led by the vendor.

Licensing: Varies, sometimes missing, often incoherent.

Community standards: Community is dormant to non-existent.

Component coupling: Depends on the project, but in practice often standalone spaghetti.

Main benefits: Doesn’t cost anything to run.

Typical governance: None.