Governance

OrganoidOS is governed as an open community standard, not as a single-author project. This document describes how that governance works today and how it will evolve as the project grows.

Why governance matters

A spec with no governance plan becomes one of two things:

1. A hostage to its initial author. If the author loses interest, the spec dies. If the author takes a job at a vendor, the spec becomes a vendor marketing document.
2. A battleground. Multiple vendors show up, each tries to add their proprietary extension to the spec, and the spec becomes an incoherent mess.

A clear governance plan prevents both. This document is that plan.

Current state (v0.1)

• Initial author: modarresi1913 (2026-08-24)
• Decision-making: lazy consensus. PRs merge after ≥1 maintainer review unless a contributor objects, in which case the issue is escalated to Discussion.
• Spec PRs: require ≥2 maintainer reviews (currently only one maintainer exists; we will lift this requirement when we have ≥2 maintainers).
• Ethics PRs: require ≥1 maintainer review + the contributor’s acknowledgement that they have read docs/ethics.md.
• License: MIT, in perpetuity. The license cannot be changed without a formal community vote (see “Future state” below).

Principles

These principles are immutable. Any future governance change must preserve them.

1. Vendor neutrality

The spec treats all MEA hardware vendors equally. The spec MUST NOT include vendor-specific extensions in its core. Vendor-specific extensions live in neural_os/api/<vendor>.py driver files, clearly labeled and isolated.

A maintainer employed by a vendor MAY contribute to the spec, but MUST recuse themselves from votes on PRs that exclusively affect their employer’s hardware.

2. Openness

• All spec discussions happen on GitHub. No private back-channels.
• All code lives in this repository. No “enterprise” versions.
• All decisions are documented in PR comments or Discussion threads.
• The maintainer’s calendar (for community calls) is public.

3. Honesty about limits

The spec is honest about what it does not cover (see spec/v0.1-architecture.md §7). PRs that over-claim — promising capabilities the underlying biology cannot deliver — will not be merged, even when they would make the project look more impressive.

This is a non-negotiable principle. Over-claiming has killed more open standards than under-claiming has.

4. Right to fork

The MIT license guarantees anyone can fork the spec at any time. This is not a bug — it is the safety valve that keeps the maintainer honest. If the maintainer ever strays from these principles, the community can and should fork.

The maintainer commits to never trademark-troll a fork. The “OrganoidOS” name will be defended against misuse (e.g., a closed- source product calling itself “OrganoidOS Pro”), but never against a genuine open-source fork.

5. Welfare-first ethics

When the spec touches closed-loop protocols on living neural tissue, the welfare considerations in docs/ethics.md take precedence over technical convenience. A protocol that is technically elegant but ethically reckless will not be merged.

Future state (governance evolution)

The governance structure will evolve as the community grows. The expected progression:

v0.1 (current) — single maintainer

• One maintainer (initial author)
• Lazy consensus for non-spec PRs
• Spec PRs require ≥2 reviews (currently vacuous — only 1 maintainer exists)

v0.2 — multiple maintainers (target: by 50 stars)

• ≥2 maintainers
• Spec PRs require ≥2 reviews (now meaningful)
• Each maintainer has a stated area of responsibility (e.g., kernel, drivers, spec docs, ethics)

v0.5 — advisory board (target: by 500 stars)

• 5–7 member advisory board (see docs/community.md)
• Board votes on v1.0 spec freeze
• Board meets quarterly; minutes are public

v1.0+ — foundation (target: by 1,000 stars)

• Project moves to a foundation (Linux Foundation, Apache, NumFOCUS — see docs/community.md)
• Foundation holds the trademark
• Foundation’s governance rules supersede this document

Decision-making process

For code PRs (non-spec)

1. Open PR
2. CI must pass
3. At least one maintainer approves
4. If no objections in 7 days, merge
5. If objections, escalate to Discussion

For spec PRs

1. Open PR (or, for large changes, open a Discussion thread first to reach rough consensus on the shape of the change)
2. CI must pass (does not apply to spec-only PRs)
3. At least two maintainers approve
4. Wait at least 7 days for community comment
5. If no sustained objections, merge
6. Update CHANGELOG.md and bump version per semver

For ethics PRs

1. Open PR with the ethics-review label
2. At least one maintainer approves
3. The contributor must acknowledge (in the PR description) that they have read docs/ethics.md
4. Wait at least 14 days for community comment
5. If no sustained objections, merge
6. Update CHANGELOG.md with an ethics-vX.Y tag

For governance changes (changes to this document)

1. Open a Discussion thread with the governance label
2. Wait at least 30 days for community discussion
3. Maintain a written summary of the discussion in the thread
4. The maintainer (or, post-v0.5, the advisory board) makes the final decision
5. Document the decision in CHANGELOG.md

Conflict resolution

Disagreements happen. The escalation ladder is:

1. PR comments — first try to resolve in the PR.
2. Discussion thread — if PR comments don’t converge, open a Discussion thread with the needs-discussion label.
3. Maintainer decision — the maintainer makes a call and documents the reasoning.
4. Fork — if the maintainer’s decision is unacceptable, the right to fork is always available. The maintainer will not stand in the way.

Code of Conduct enforcement

See CODE_OF_CONDUCT.md and .github/SECURITY.md. The maintainer is the default Code of Conduct enforcer. If the maintainer is the subject of a CoC report, the report goes to the advisory board (once one exists) or, in the interim, to a named external contact (TBD when the first external contributor joins).

License of this document

MIT. Anyone may quote freely. If you fork the spec, you may use this governance document (modified or unmodified) under MIT.