A Field Guide to Open
Source Business Models

James Vasile
Open Tech Strategies

Open Source Goals

  Market insight
  Framework for partner collaboration
  Ease vendor lock-in fear
  Lead a standardization effort
  Improve product quality
  Amplify or expand developer base
  Improve developer hiring pool
  Improve internal collaboration
  Improve internal morale and retention
  Disrupt an incumbent, hold off insurgents
  Engage with users
  Branding and credibility
  Transparency for customers and partners
  Establish a basis for product reputation

Archetypes Captured

Wide Open
B2B Open Source
Multi-Vendor Infrastructure
Upstream Dependency
Controlled Ecosystem
Rocket Ship to Mars
open by Dinosoft Labs from the Noun Project Specialty Library
Mass Market
Trusted Vendor

  Wide Open

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.

  B2B Open Source

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.

  Upstream Dependency

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.

  Controlled Ecosystem

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.

  Rocket Ship to Mars

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.

open by Dinosoft Labs from the Noun Project Specialty Library

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.

  Mass Market

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.

  Trusted Vendor

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.

James Vasile

Mail by il Capitano from the Noun Project james@opentechstrategies.com
Twitter logo @jamesvasile

Open Source ROI: https://is.gd/foss_roi

This presentation: https://is.gd/ots_archetypes

The Archetypes report: https://is.gd/archetypes_report

Noun Project Icons

Created by
il Capitano
Created by
Shane Holley
Created by
Carlos Dias
Created by
Dinosoft Labs
Created by
Sharon Showalter
Created by
Juan Pablo Bravo
Created by
Stephen Plaster
From the Noun Project
Created by
Ralf Schmitzer
Created by
Created by
Gregor Cresnar
Created by
Juan Pablo Bravo
Created by
Justin Blake