OpenRoots

Adoption

Who is carrying an instrument today.

Public evidence and self-reported use are kept apart on purpose. Every named repository below was checked for a real OpenRoots licence, so you can verify it yourself. The private count is reported separately and is not independently verifiable, and it is labelled that way rather than folded into one flattering number.

Public, named
12
Private, counted
30
Total
42
Surveyed
2026-08-24

Read this first

Early, and specific about what that means.

First-party adoption proves the instruments apply cleanly to real work. It does not prove third-party acceptance yet, and it is not presented as if it does.

Every repository below belongs to a committee member and currently carries an archived 1.0 instrument. That is evidence that 1.0 was applied, not evidence of third-party acceptance or adoption of the current 1.1 terms. New projects should use 1.1; existing 1.0 grants retain the historical terms attached to those copies.

The committee reports that 30 further private repositories carry an instrument. They are counted in the inventory and never named, because publishing their names would disclose private work. This number is self-reported, cannot be checked through the public API, and is not public adoption evidence.

By instrument

Which instruments are in use.

ORA-1.0

6

ORL-1.0

6

Public repositories

12 named, with 128 stars between them.

Sorted by stars. Star count is a weak proxy for reach, and it is checkable.

mjmirza/app-store-complianceORA-1.0Python93 stars

Enterprise App Store and Google Play rejection compliance playbook: rejection maps, mistake taxonomy, 2026 enforcement and legal layer, a tested pre-submission guard, and an agent audit skill.

Professional delivery standards for n8n automation and AI consultants. Scoping gates, contract templates, security and compliance checklists, handover and retainer artifacts.

mjmirza/headless-claudeORL-1.0Shell6 stars

Ultra-Advanced, Production-Ready Patterns for Headless Execution

mjmirza/patternsORA-1.0Python5 stars

Master level software patterns reference. 18 dimensions per entry, every claim cited and verified.

Free bilingual (DE/EN) screenshot-by-screenshot guide to filing a discrimination complaint with Germany's Federal Anti-Discrimination Agency (Antidiskriminierungsstelle des Bundes). Not legal advice.

mjmirza/quran-datasetORA-1.0Python1 stars

Clean, uniquely structured, independently validated Arabic Quran dataset. 114 surahs, 6236 ayahs, rich metadata, 6-layer validation. CC BY 4.0.

mjmirza/apple-design-systemORA-1.0Shell0 stars

Named, documented, reproducible reference catalog of Apple's design system (HIG components, foundations, patterns, fonts, SF Symbols, templates, bezels). Fetches assets directly from Apple; redistributes none.

Single-file client-side calculator for the full monthly cost and profit of an all-Cloudflare app

mjmirza/devtoORL-1.00 stars

Cover banner host for dev.to articles

mjmirza/foundryORL-1.0Shell0 stars

Foundry. The agent skill that makes any AI coding assistant an expert at building agentic tooling.

mjmirza/mjmirzaORL-1.00 stars

Github profile README

Why self-hosting Xentral is a dead end for modern integrations: research, the OpenXE deploy recipe, the traps, and the verdict.

Machine-readable at /adopters.json

How this is counted

Four ways to count, and no way that phones home.

OpenRoots ships no analytics and no telemetry, so adoption can only be measured from the outside in. Every method below is one you can run yourself without asking anyone for access.

Public code search

Every public repository whose licence metadata carries an OpenRoots identifier.

Run it yourself

GitHub code search for "LicenseRef-OpenRoots" across all public repositories, then one search per instrument identifier.

What it proves

That a named, public repository has actually applied the identifier. Anyone can click the result and read the LICENSE file.

What it cannot see

Private repositories, internal mirrors, and any adopter who applied the text without the SPDX identifier string.

Package registry metadata

Packages declaring an OpenRoots identifier in their manifest licence field.

Run it yourself

Query the npm, PyPI and crates.io metadata APIs for the licence string. LicenseRef is valid SPDX today, so it survives the round trip.

What it proves

Adoption that reached a published artifact rather than only a repository.

What it cannot see

Ecosystems with no machine-readable licence field, and anything never published to a registry.

SBOM appearance

OpenRoots identifiers appearing in software bills of materials downstream.

Run it yourself

Once an SPDX identifier is granted, scan public SBOM corpora for it. Until then the LicenseRef string is what appears.

What it proves

That the licence travelled past the first adopter into somebody else's dependency tree.

What it cannot see

Everything before an SPDX identifier exists, which is the current state.

Voluntary self-report

Adopters who tell us directly, including private and internal use.

Run it yourself

A message through the contact route on the report page. No account, no form, no tracking pixel.

What it proves

Nothing independently. It is a claim by the adopter and is counted separately for that reason.

What it cannot see

Everyone who does not bother, which is most people. This number is always an undercount.

The strings to search for

LicenseRef-OpenRoots-ORL-2.2LicenseRef-OpenRoots-ORD-2.2LicenseRef-OpenRoots-ORM-2.2LicenseRef-OpenRoots-ORA-2.2

Why there is no fifth method

A licence that phones home is a licence nobody adopts for anything that matters, and the objection is correct. The moment a generated notice, a configurator, or a canonical text fetch identifies its user, adopting an instrument becomes a disclosure decision rather than a licensing one.

So the count here is deliberately outside-in. It undercounts, it lags, and every figure on this page can be reproduced by a stranger without asking OpenRoots for anything. That trade is the point rather than a limitation to be engineered away later.