Each path below states who it is for, what the next action actually is, and — because this is where participation pages usually rot — what keeps the destination alive and what to do if it stops working.
If a route turns out to be a dead end, that is a bug in this page. Please say so.
The repository is a large Rust workspace with a real contribution surface: kernel and app crates, a gateway, a CLI, and a documentation control plane. The architectural guardrails are written down, and they are enforced — reading them first will save you a review round.
Read the contributing guide, then build the workspace ↗A small, deliberately curated set of issues that are genuinely self-contained — they have a clear boundary, a stated expectation, and do not require holding the whole architecture in your head. The label is not applied to make the project look welcoming; if an issue turns out to be larger than advertised, say so on the issue.
Browse the open good-first-issue label ↗The project is short on plain-language review, accessibility testing on real assistive technology, governance and policy thinking, translation, and documentation that a non-engineer can follow. This is not filler work — the member-facing surface is the part of ICN furthest behind, and that is a design and language problem at least as much as an engineering one.
Start a discussion describing what you would like to work on ↗Not every question is worth opening an issue for, and requiring a GitHub account to ask one narrows who can participate to people already comfortable with developer tooling. The chat server is the doorway that does not.
Join the Discord server ↗The honest current answer for most institutions is "not yet, and here is specifically why". Before any conversation about adoption, it is worth understanding what exists, what is demonstrated only against fixtures, and what the project has not built. That page is written to be read by someone deciding whether to spend their organisation's time.
Read the institutional evaluation page, then open a discussionThere is no mailing list. Setting one up would mean asking you to trust that we will actually send it, and the project would rather point at something that updates whether or not anyone remembers to write a newsletter. Watching releases on the repository, or reading the recent-state-changes section of the maturity page, both do that.
Watch the repository, or read recent state changes ↗GitHub Sponsors is the only funding rail the project currently has. There is no foundation, no token, no equity, and no membership tier that buys influence over decisions — sponsoring supports the work and does not purchase standing in any institution ICN serves.
Sponsor the project on GitHub ↗Everything the project does happens in the open, including the parts that are unfinished. These are the surfaces to read if you would rather look than ask.
This page used to publish counts of branches, merged pull requests, and documentation files. Those are gone. A branch total counts dead branches, a merged-PR total measures nothing a reader cares about, and neither had a freshness guarantee. The project state page reports the things that are worth reporting, with the date each was verified.
The sections below go step by step through each path — the actual build commands, the checks to run before pushing, what an institution would need to bring, and what the project is honest about not having.
Rust workspace, actor-based runtime, strict kernel/app separation. If you write systems code and want to work on cooperative infrastructure that is not another SaaS or token protocol, this is the path.
icn/rust-toolchain.toml.git clone https://github.com/InterCooperative-Network/icn.git
cd icn/icn
cargo build
cargo test --workspace --lib
The Rust workspace lives inside the icn/ subdirectory, not at the repo root.
Run all cargo commands from there.
README.md — repo map and first-stop routing for contributors.docs/GETTING_STARTED.md — build, run, and verification quickstart.AGENTS.md — operating rules, verification commands, invariants, crate layout.CONTRIBUTING.md — architectural guardrails and the regulatory invariants PR checklist.CLAUDE.md — deep project map (also useful even if you aren't using Claude Code).epic:* label and one type:* label. Pick an epic that matches your interest.
docs/onboarding/README.md.
cargo fmt --all --check
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test --workspace --lib
Run these from icn/, the Rust workspace you entered in the build step. Full routing table is in AGENTS.md.
Work on a feature branch (feat/<slug>, fix/<slug>,
docs/<slug>). Open a PR against main. Every PR includes a
what, why, risk, and test plan.
If the change touches gateway APIs, ledger logic, or member-facing text, step through the regulatory
invariants checklist in CONTRIBUTING.md.
ICN is not only a Rust project. The system has to be described, designed, stress-tested, and translated into something cooperatives can actually use. The work below is real and needed.
Writing that explains what the system actually does without overclaiming. Gaps we know about: user-facing guides for non-developer members, step-by-step operator guides, explainers that keep What's Real Now honest as the surface changes.
First step: read docs/INDEX.md, find a gap, open a
docs issue
with type:doc.
The member-facing experience is the part of the system most visibly trailing the capabilities underneath. Design work on how identity, standing, governance, and receipts cohere into something a person can use is wanted and has room.
First step: read docs/design-language/brief-v0.md and
start a discussion
describing what you would want to work on.
Cooperative governance patterns, policy mechanisms, economic accounting rules, regulatory framing. ICN is shaped by how real institutions actually run; we need people who know that terrain to push back on designs that won't survive contact with a real membership.
First step: open a GitHub Discussion under Ideas or General with the question or proposal.
Running the daemon, running through the flows, filing specific bugs, and telling us where the experience breaks down. Adversarial reading of the public site and docs is valuable — inconsistency between What's Real Now and the rest of the site is a defect.
First step: Getting Started to stand up a node, then open an issue for anything that breaks, misleads, or surprises.
Connecting ICN to the cooperative, solidarity-economy, and public-interest-technology networks that should know about it. Introductions to aligned projects and institutions. Organizing conversations about cooperative infrastructure that don't route through platform incumbents.
First step: join the ICN Discord server or post in Discussions.
Cooperative movements are not Anglophone. The public site, docs, and concept glossary will need to be readable across at least the languages where active cooperative infrastructure communities already exist. This work has not started and is open.
First step: open a Discussion describing the target language and which surface (site, docs, glossary) you want to cover first.
If your cooperative, network, or aligned project is thinking about ICN as institutional infrastructure, the honest frame is not "vendor selection." It is early collaboration on infrastructure that is still being built.
Read For Cooperatives and What's Real Now. Watch the repository on GitHub. This is the right relationship for most cooperatives right now — you stay oriented without investing engineering capacity in something that isn't ready to hold your institution yet.
Governance patterns that work, accounting rules that don't fit generic tools, federation relationships that current software can't carry — this knowledge shapes the infrastructure. You don't need to write code to do this. Open a Discussion describing what your institution does and where the current stack fails.
If your institution has the capacity and the interest, working with the project directly as a cooperative or federation willing to shape how the infrastructure gets built is an option. This is engineering-heavy. Cooperatives engaging this way are co-building the substrate.
The current path is: open a Discussion describing your institution, the scope of engagement you have in mind, and the engineering capacity you can commit. How cooperative infrastructure works.
ICN is open infrastructure. Financial support goes to sustaining engineering capacity on the infrastructure — not to a commercial product with an investor ladder behind it.
The current financial-support rail is GitHub Sponsors, at the organization level. Sponsorship goes to sustaining work across the whole project, not to a specific sub-project or individual.
This is the only live donation rail today. We are not running Patreon, Open Collective, or a fiscal-sponsor donation portal. If a more structured funding path (fiscal sponsor, grants, institutional membership) becomes appropriate, it will be described on this page when it exists — not before.
Sponsor on GitHub ↗Developer work that expands execution coverage, improves contributor onboarding, or tightens member-facing and operator-facing surfaces.
Documentation work that makes the project easier to evaluate honestly and easier to contribute to without internal context.
Design, testing, and pilot feedback that exposes where the current user-facing surfaces still break down.
Institutional input from cooperatives, federations, and aligned networks about governance, accounting, and coordination problems the current stack fails to carry.
A polished non-technical onboarding flow for ordinary members.
Additional donation infrastructure beyond GitHub Sponsors.
A finished brand system or final ICN logo.
If you are still figuring out what ICN is before deciding how to engage, start with What is ICN and What's Real Now. Then come back here.