Mozilla

At Mozilla authority goes to volunteers and employees alike, regardless of employer, as they show ability through their contributions, with active steps to reduce bias in who gains it.

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.

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.

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.

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.

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 who already holds level 2 or higher, and Mozilla employees need none; general access, rarely used, needs one module owner; core-product access (Firefox, GeckoView, Thunderbird) needs two owner/peer or Tree Sheriff vouchers, or one level-3 owner when upgrading from level 2. 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.

Anyone contributing to Firefox with AI tools keeps patches small, must be able to understand and explain every line, and completes their own review before asking for one. Confidential or security-sensitive information is not given to external AI tools. The policy was published in November 2025; the self-review requirement was added in May 2026.

How it works

Accountability stays with the author: the reviewer checks a person’s work, not a tool’s output. “Good first” bugs reserved for newcomers are meant for learning, so clearing them in bulk with AI alone is discouraged.

Why it is used

AI makes it easy to produce code that looks right but is wrong; the rule protects scarce review capacity and newcomers’ path to learning.

Trade-off

It relies on trust rather than detection and defines no enforcement mechanism; it adds self-review time to every patch.

Best fit

Large open-source codebases with many outside and volunteer contributors where review capacity is the bottleneck.