The Community Orchestration Software Development Sprint

An annual, nine-month program from the Network Theory Applied Research Institute for building software that communities can own and operate themselves.

Most of the software communities depend on to run their daily lives — to buy and sell, to coordinate care, to respond to emergencies, to talk to one another — is rented, not owned. The terms can change without notice. The price climbs. The code is closed, so no one outside the company that wrote it can see how it works, repair it, or adapt it to local needs. For a single household that is an annoyance. For a community trying to build durable economic and social infrastructure, it is a structural dependency that quietly drains resources and forecloses self-determination.

The Community Orchestration Software Development Sprint, or COSDS, is the Network Theory Applied Research Institute's answer to that problem. It is an annual program, running nine months from August to May, in which volunteers from around the world gather in shared online workspaces to build software communities can use to operate their own social and economic activity — without the perpetual rent that proprietary platforms demand. Every year the sprint takes on a fresh slate of projects, trains a new cohort of contributors, and returns finished tools to the public.

Software that returns to the commons

Everything produced during COSDS is released under a copyleft license: the GNU Affero General Public License, version 3. The terms are simple to state. Anyone may use the software, study it, run it, and modify it. The only obligation is reciprocity — those who improve the software must share their improvements as freely as they received the original. The AGPL extends that promise to software run as a network service, which is how most community platforms are actually delivered, closing the loophole that lets hosted software quietly become closed again.

The effect is that the work never stops being a public good. A reputation system, a marketplace, an emergency-response tool — once built under these terms, it cannot be enclosed, repriced, or taken private by whoever happens to run it next. NTARI's role is to keep that commons coherent: it helps communities maintain canonical branches of each project and unites local developers across the world in a single space for study, research, and collaboration over shared problems.

How the sprint works

A COSDS cycle is built around small, full-stack teams, each devoted to a single project. Two project managers oversee development and shipping and lead a team of four front-end and back-end developers who write and instantiate the code. A project steward documents the build and develops the long-term infrastructure — the continuous-integration and continuous-deployment automations that let the project keep moving after the cycle ends. Stewards commit for longer than the rest of the team and stay on through a structured handover, so that knowledge and tooling carry forward rather than evaporating in May. Across the whole sprint, a shared development support staff troubleshoots problems wherever they surface — Slack, Jira, Confluence, GitHub, Google Workspace, and the other platforms the teams rely on.

The roles are open to students, professionals, and community members at different stages. Developers can be pursuing a bachelor's degree or already hold one; project managers and stewards bring graduate-level training or a demonstrated record of shipping real software. Contributors commit a set number of hours each week for the duration of the cycle, and the work happens entirely online, which is what lets a single project draw on talent from anywhere.

What participants get

NTARI equips every volunteer to do serious work. Each receives an @ntari.org email address, enterprise access to Google Gemini and NotebookLM, access to Claude, a dedicated Slack channel, and accounts on Jira and Confluence, along with access to NTARI's shared GitHub organization. Onboarding runs through a volunteer orientation course; those who complete it select their project on a first-come, first-served basis. Every contributor receives an acceptance letter, time-tracking workflows built into Slack and Jira, and a completion letter detailing their role and contributions. And because the software is open, every contributor is credited by name in the official documentation of the finished product — a durable, public record of the work.

What gets built

The point of COSDS is not one application but a growing library of community tools, and the range of any given cycle reflects that. Recent projects include a community agriculture marketplace connecting farmers, gardeners, processors, and consumers to strengthen regional food systems; a distributed community computing platform that lets neighborhoods generate local economic value from shared compute rather than leaning on distant data centers; and a reputation-and-trust framework, inspired by MIT system-safety scholar Nancy Leveson, that evaluates the safety and reliability of interactions instead of reducing them to five stars.

That trust framework in turn underpins a childcare network that helps families find caregivers on the basis of real experience and reliability. Other projects reach toward emergency communication and coordination, a collaboration platform that gives communities control over their own data, a tool that helps social workers connect people leaving homelessness or incarceration with shelter and support, a proximity-based outdoor recreation game, and an outreach engine that promotes these very platforms to the communities that could use them. Each cycle's slate changes, but the through-line holds: practical software for the work of living together, owned by the people who depend on it.

Why it matters

The deeper goal of COSDS is to train people — university students, working professionals, and communities themselves — in how to build and maintain open-source software, and in doing so to improve the socioeconomic resources available on the internet. Proprietary platforms extract rent precisely because the communities using them never learn to build or hold their own tools. The sprint inverts that. It treats software not as a product to be purchased again and again, but as infrastructure a community can own outright, study openly, and pass on intact. Each year it sends a new cohort of builders out into the world having done exactly that, and leaves behind a little more of the commons than it found.