# Open Collective Development > A coordination model for people who contribute judgment and agent-assisted effort to public projects they want to exist - HTML version: https://robbiepalmer.me/projects/open-collective-development - Status: idea - Started: 2026-09-04 # Working idea Open-source projects survive because people want them to exist. They contribute code, documentation, bug reports, support, money, judgment, and the emotional energy needed to keep a public project alive. Agentic coding changes who can contribute meaningful implementation work. A person no longer needs every specialist skill before helping. They can bring their own agent, tokens, attention, interests, and local context. That could let open groups build software that once required a large company. It could also bury maintainers under plausible but misguided issues and pull requests. GitHub already struggles to represent a shared plan for thousands of people with little common context. Making contributions cheaper amplifies that coordination problem. Agent access can make confidence grow faster than understanding. A contributor may feel able to change a system before they understand its constraints, while the maintainer has no cheap way to distinguish a useful attempt from one that will consume hours of review. Better generation alone makes this worse. Open Collective Development names the wider model. Agentic open source is one application, but the same structure could help people build public goods outside software. # The shift in contribution Historically, a "good first issue" often meant documentation cleanup or a small task selected because a new contributor could complete it without deep project knowledge. Cheap agents should handle much of that maintenance. Meanwhile, people who understand the problem but cannot code it alone can now direct agents through deeper work. The useful distinction becomes less about who can code. It becomes the difference between people who help build and govern the shared work graph, and people who contribute attention and agent-assisted execution to that graph. Both matter. # Proposed model Project owners publish a Work Graph containing outcomes, priorities, dependencies, constraints, and evidence requirements. Contributors ask their own agents for the highest priority ready task matching their skills and interests. A task receives one renewable lease. The contributor remains responsible for steering their agent and returns the work through the project's review path. No subscription credentials change hands. Contributors use products under their own terms or pay normal API prices. The shared system coordinates work and context, not access to private accounts. Direction can remain centralized where that helps coherence. Many successful projects use a lead maintainer or benevolent dictator. Participation remains voluntary, but authority, appeal, and ownership need to be explicit rather than smuggled in through repository permissions. # Why existing funding is not enough Sponsorship, Patreon, Kickstarter, and corporate support let people contribute money. They rarely provide enough stable income to sustain maintainers, and they do not capture the new supply of guided agent work. This idea is not a replacement for paying maintainers. It asks whether people can also contribute useful execution capacity to a shared plan without increasing the maintainer's coordination burden. If every contributed hour creates two hours of review, the system has failed. # Dependencies This is not on the first implementation path. It depends on: * a Work Graph that can express public priorities and completion evidence; * an Agent Coordinator that can offer bounded work without taking custody of a contributor's subscriptions; * strong automated review and deterministic validation; * knowledge packages that give an unfamiliar contributor enough context; and * personal and team evidence that these systems reduce coordination work. # Questions that could kill the idea * Can the system reject low-value work before it consumes maintainer attention? * How should observed contribution quality change which tasks an actor may claim? * Who owns agent-produced work and accepts licensing terms? * How are security-sensitive tasks separated from public contribution? * How does a project resist spam, coordinated capture, and large contributors buying practical control through compute? * Which decisions belong to maintainers, contributors, users, or sponsors? * Can contributors understand why a task matters without reading the whole project history? * Does matching people by interest create ownership, or merely turn open source into unpaid queue processing? # First test The first experiment should be much smaller than a new hosting platform. Publish the DAG for one project, expose a few bounded tasks with strong evidence requirements, and let invited contributors claim them with their own agents. Measure the maintainer attention required to reach an accepted result. Compare that with ordinary issues and pull requests. Only expand into governance, reputation, funding, or new organisational structures after that experiment shows net value. # Relationship to the wider initiative The [Semi-autonomous Software Development initiative](/initiatives/semi-autonomous-software-development) starts with personal projects and then a team. Open Collective Development is the later stress test. It asks whether the same feedback loops can coordinate a public group whose members have minimal shared context but a genuine desire to make the project exist. ## Initiatives - [Semi-autonomous Software Development](https://robbiepalmer.me/initiatives/semi-autonomous-software-development.md): A connected system that keeps useful work moving, asks for human judgment when it matters, and learns how to need less intervention next time --- Markdown index of this site: https://robbiepalmer.me/llms.txt