Governance

Governance

Open source management strategy for MetaForge

Table of Contents

  1. Governance Model
    1. Year 1: BDFL + Core Maintainers
    2. Decision Model
    3. Year 2+: Transition to Steering Committee
  2. Contribution Rules
    1. Skills
    2. Tool Integrations
    3. Core Changes
  3. Release Process
    1. Versioning
    2. Release Cadence
    3. Release Checklist
  4. Community Growth Strategy
    1. Timeline
    2. Target Audience
    3. Engagement Channels
  5. Code of Conduct
    1. Core Principles
    2. Enforcement
  6. Intellectual Property
    1. License
    2. Contributor License Agreement
    3. Third-Party Dependencies
  7. Related Documents

Governance Model

Year 1: BDFL + Core Maintainers

Role Count Responsibility
BDFL (Benevolent Dictator for Life) 1 Final architecture decisions, release approval
Core Maintainers 2-3 Review PRs, triage issues, maintain CI/CD

Decision Model

Area Authority Process
Core architecture BDFL only RFC required, maintainer review
New skills Maintainers PR review, schema + test validation
Tool integrations Maintainers PR review, integration test pass
Documentation Any contributor PR review by 1 maintainer
Bug fixes Any contributor PR review by 1 maintainer

Year 2+: Transition to Steering Committee

As the project matures, governance will transition to a steering committee model with elected representatives from key contributor groups:

  • Platform core developers
  • Skill contributors (by domain)
  • Tool adapter maintainers
  • Community representatives

Contribution Rules

Skills

All contributed skills must include:

Requirement File Description
Schema schema.py Typed input/output schemas with validation
Tests tests.py Unit tests with >80% coverage
Validation definition.json Complete metadata and configuration
Documentation SKILL.md Human-readable usage guide
Naming — Follow snake_case naming convention

Skill PR Checklist:

  • definition.json is valid and complete
  • Input/output schemas defined and documented
  • All tests pass
  • SKILL.md explains purpose, inputs, outputs, and examples
  • No hardcoded paths or credentials
  • Compatible with skill registry auto-discovery

Tool Integrations

All contributed tool adapters must:

Requirement Description
Containerized Provide a Dockerfile for isolated execution
MCP schema Define tool capabilities via MCP protocol
Integration tests Pass automated integration tests
Version pinning Specify supported tool versions
Health check Implement healthCheck() endpoint
Documentation README with setup instructions

Core Changes

Changes to core platform code (digital_twin/, orchestrator/, mcp_core/, skill_registry/) require:

Step Description
1. Design discussion Open a GitHub Discussion or Issue
2. RFC document Write an RFC in docs/rfcs/
3. Maintainer review At least 2 maintainer approvals
4. Implementation PR with tests and documentation
5. BDFL approval Final sign-off for architectural changes

Release Process

Versioning

MetaForge follows Semantic Versioning:

  • MAJOR: Breaking API or schema changes
  • MINOR: New features, new skills, new tool adapters
  • PATCH: Bug fixes, documentation updates

Release Cadence

Type Frequency Approval
Patch As needed 1 maintainer
Minor Monthly 2 maintainers
Major Quarterly BDFL + all maintainers

Release Checklist

  • All tests pass (unit, integration, e2e)
  • CHANGELOG.md updated
  • Documentation updated
  • Migration guide (if breaking changes)
  • Release notes written
  • Git tag created
  • Package published

Community Growth Strategy

Timeline

Month Action Goal
Month 3 Publish architecture blog post Establish technical credibility
Month 6 Public demo video Show working vertical
Month 9 Invite contributors First external PRs
Month 12 Community call / Discord Regular engagement

Target Audience

Focus community growth on:

Audience Why How
Mechanical engineers Core domain users FreeCAD/CalculiX content, CAD forums
PCB designers Key user segment KiCad community, EDA forums
Firmware developers Embedded expertise Embedded Rust/C communities
Open source tool developers Tool adapter contributors FreeCAD, KiCad, OpenFOAM communities

Explicitly not targeting: Random AI hype crowd. MetaForge is infrastructure for engineers, not a demo toy.

Engagement Channels

Channel Purpose Timeline
GitHub Discussions Technical Q&A, RFCs From Day 1
GitHub Issues Bug reports, feature requests From Day 1
Blog / Dev Log Architecture decisions, progress updates Monthly from Month 3
Discord Real-time community chat Month 12
Conference Talks Visibility, credibility Month 12-18

Code of Conduct

MetaForge follows the Contributor Covenant Code of Conduct.

Core Principles

  1. Be respectful — Treat all contributors with dignity
  2. Be constructive — Provide actionable feedback
  3. Be collaborative — Share knowledge, help others
  4. Be professional — Focus on technical merit

Enforcement

Violation Action
First offense Private warning
Second offense Temporary ban (30 days)
Severe violation Permanent ban

Reports go to the BDFL and core maintainers.

Intellectual Property

License

MetaForge is licensed under the MIT License.

Contributor License Agreement

By submitting a PR, contributors agree that:

  • Their contribution is their original work
  • They grant the project a perpetual, worldwide, non-exclusive license
  • Their contribution will be licensed under MIT

Third-Party Dependencies

All dependencies must:

  • Have a compatible open-source license (MIT, Apache 2.0, BSD)
  • Be documented in dependency manifests
  • Not introduce copyleft obligations (GPLv3 only for optional, isolated tools)
Document Description
Contributing Guide How to contribute code and documentation
Execution Roadmap When features are planned
Repository Structure Where code goes
System Vision What we’re building

Document Version: v1.0 Last Updated: 2026-02-16

← Roadmap Contributing →