FormicOS is maintained by the Intradyne team. This document describes how decisions are made, how contributions flow, and who has authority over what.
Maintainers have write access to the repository, can merge pull requests, and make architectural decisions. Current maintainers are listed in the repository's GitHub team settings.
Maintainer responsibilities:
- Review and merge pull requests
- Triage issues and security reports
- Approve Architecture Decision Records (ADRs)
- Maintain CI/CD infrastructure
- Enforce the code of conduct
Anyone who submits a pull request, files an issue, or participates in discussions. Contributors do not need special permissions.
In the context of FormicOS runtime, the "operator" is the human user who interacts with the Queen and directs the multi-agent system. This is a runtime role, not a governance role.
Significant architectural changes require an Architecture Decision Record
(ADR) in docs/decisions/. ADRs must be approved by at least one
maintainer before implementation begins.
The following changes always require an ADR:
- Adding or removing event types (closed union modification)
- Changing the 4-layer dependency rules
- Adding new external dependencies
- Modifying the knowledge confidence model
- Changing federation protocol semantics
- All code changes go through pull requests
- PRs require at least one maintainer approval
- CI must pass before merge
- The layer boundary lint, type checker, and test suite are mandatory gates
The event union is ADR-gated. Adding a new event type requires:
- An ADR explaining why the new event is necessary
- Maintainer approval
- Updates to all consumers (projections, view state, contract docs)
- TypeScript contract mirror update
- Open an issue or discuss in an existing thread
- Fork the repository
- Create a feature branch
- Sign the CLA (see below)
- Submit a pull request following the PR template
- Address review feedback
- Maintainer merges after CI passes and approval is given
FormicOS requires a Contributor License Agreement (CLA) for external contributions. The CLA gives Intradyne the rights needed to distribute contributions under the repository License and under commercial licensing terms, while keeping contributor-revenue mechanics on a contractual basis.
The canonical contributor agreement is CLA.md. Organizations whose employees contribute can sign the Corporate CLA to blanket-authorize all their developers.
Status: CLA enforcement requires admin-side configuration. See
docs/GITHUB_ADMIN_SETUP.md for the setup steps that a repository
administrator must complete.
Until the CLA app is fully configured, maintainers will manually verify contribution rights during PR review.
DCO sign-off may be used in addition to the CLA, but it is not a substitute for the CLA.
If the current maintainer team becomes inactive:
- Existing contributors with a track record of quality contributions may request maintainer access by opening an issue
- If no response within 30 days, the project should be considered unmaintained
- Forks remain available under the AGPLv3 base license and any additional permissions actually retained in the redistributed copy
All participants must follow the Code of Conduct.
FormicOS is distributed under the LICENSE file in this repository: AGPLv3 as the base license, with Section 7 additional permissions and a commercial licensing path. Commercial payment mechanics live in COMMERCIAL_TERMS.md. Token metering is specified in METERING.md. Contributor rights and revenue-share mechanics live in CLA.md. Machine-readable economic contracts for A2A agent participation are specified in docs/A2A_ECONOMICS.md.