How They Do ItBETA
TREN

COMPANY PLAYBOOK

Mozilla

Mozilla aims to develop products and technology with a global community committed to an open-internet mission.
Operating system
  1. Mission
  2. community participation
  3. governance structures
  4. conduct standard
  5. public-benefit products.

System principles

  • Openness, innovation and opportunity.
  • A respectful space for participants.

Tensions and trade-offs

  • Open participation broadens access but requires consistent conduct and governance enforcement.

PRACTICES

How Mozilla builds its operating system

01
Governance

Community governance

Mozilla presents its governance through publicly described project and organizational structures.

How it works
The project makes governance information available as part of how the community operates.
Why it is used
It gives contributors a visible route to understand authority and mission.
Trade-off
Public structures alone do not eliminate informal influence.
Best fit
Mission-driven projects with substantial external contribution.
Open original source ↗
02
Culture

Community Participation Guidelines

Shared expectations for participant conduct are published.

How it works
A written code sets expectations for how community members interact.
Why it is used
It helps make broad participation safer and more predictable.
Trade-off
Rules need reporting and enforcement capacity to be credible.
Best fit
Open communities with many different contributors.
Open original source ↗
03
Mission

Public-benefit product approach

Mozilla positions products and innovation as advancing its open-internet mission.

How it works
Product work is explicitly connected to a stated public-interest mission.
Why it is used
It provides a shared decision frame beyond short-term commercial return.
Trade-off
Mission constraints can conflict with revenue or market speed.
Best fit
Organizations with a durable public-benefit charter.
Open original source ↗
04
Governance

Module ownership with independent peer review

Work is divided into bounded modules; an owner provides direction and is accountable for acceptance, but cannot approve their own code.

How it works
Each module records an owner and, where needed, peers; check-in needs owner/peer approval and an owner has a peer evaluate their own change.
Why it is used
Keeps authority close to the code or activity while retaining an independent quality check.
Trade-off
If owner or peer capacity is scarce, review queues slow flow.
Best fit
Technical product communities with many components and outside contributors.
Open original source ↗
05
Governance

Trust-tiered commit access

Repository write access is divided into three impact-based levels; more critical product code requires more vouching by current owners or peers.

How it works
Try/user access needs one voucher, general access one module-owner voucher, and core-product access two owner/peer vouchers; each level includes the previous one.
Why it is used
Lowers entry cost for low-risk contribution while raising the trust threshold for the core product.
Trade-off
Finding vouchers and administering access depend on volunteer and owner capacity.
Best fit
Projects open to contribution but with production code of differing impact.
Open original source ↗

Primary sources