Skip to content

Join as a member project

Your project keeps its code, roadmap and home page. We list it in the directory and on the forum, and once it has tagged releases we can package it in the signed apt repository.

Start on the forum Read the standards (PDF)

You provide Source in git, a working build and install (CMake for C/C++, pyproject.toml for Python, etc.), and a tagged release schedule.

We provide The secure build pipeline, signed packages, a project page in the directory, and a place on the forum.

Member stages

Projects join at the stage that fits. Pond projects are incubating and get mentoring. Explorer is for research code, which is a member as it is. Estuary, Bay and Ocean are maturity levels 1 to 3.

Pond
Incubating

Member projects

Explorer
Research focus

Estuary
Maturity level 1

Bay
Maturity level 2

Ocean
Maturity level 3

Minimum standards

We ask what your documentation and process must answer, not which tool writes it. A README, docstrings, tests, or a paper appendix all count.

Documentation

  1. Purpose. What the component does and its intended scope.
  2. Usage. At least one minimal, realistic example.
  3. Interface. Inputs, outputs, expected behavior, and failure modes.
  4. Assumptions and constraints. Preconditions, units, coordinate frames, timing.

Maintainability

  1. Build reproducibility. A contributor can build from a clean state with documented steps.
  2. Interface contracts. Message formats, types, units, and frames are stated.
  3. Verified behavior. Tests, a runnable example, or a manual validation procedure.
  4. Issue visibility. A public way to report defects and see known issues.

Plus a published OSI-approved license.

Maintainability badges

A badge tells users what to expect. Each level lists the minimum standard, the DevOps help we offer to reach it, and well-known open-source projects at that level.

Standard: builds from documented steps on at least one known platform. Some evidence of tested behavior. Issues reportable via any channel.

DevOps: builds locally. No CI or packaging required.

Examples: many code releases that accompany academic papers.

Standard: clean build from documented steps. At least one automated test or runnable example. Public issue tracker. Interface inputs and outputs documented.

DevOps: CI on the primary platform. Dockerfile available.

Examples: MOOS-IvP, MAVLink.

Standard: CI runs on changes. Interfaces formally defined and tested. Installable on at least one target platform. Contributing and issue guidelines published.

DevOps: multi-platform CI. Packages in the shared repository. Multi-arch Docker images.

Examples: ROS 2 core packages, ArduSub.

Standard: multi-platform packaging. Full regression suite. Schema-validated configuration. Changelog and deprecation policy.

DevOps: integration tests with other member projects. Release automation.

Examples: ArduPilot, PX4.

Standard: formal compatibility guarantees across platforms and versions. Governed CI infrastructure. Long-term support commitments.

DevOps: cross-project CI. Shared build infrastructure. Reproducible deployment stacks.

Examples: ROS 2 full ecosystem, Linux kernel.

Research code is welcome

The standards explicitly support research and experimental software. For Research-Grade projects these are acceptable:

  • Manual validation in place of automated tests
  • Source-only distribution with documented build workarounds
  • One known-good platform instead of broad portability
  • Interface contracts documented in a paper or README section

How to apply

  1. Introduce the project. Post on the forum. Maintainers can apply; users can nominate a project they depend on.
  2. Self-assess. Link evidence for the eight minimums and your license.
  3. Peer review. Member maintainers review and agree on a stage and badge.
  4. Onboard. Your project page goes live in the directory, and we start on packaging.

Start on the forum