The Idea
A commons is shared — a resource that sustains many, held and tended by the very community that depends on it. No single participant owns it. It is neither free of care, nor free of rules. It persists because those who draw from it also give back to it.
The original commons is the ecological world itself. A prairie is a commons shared by the grasses, the pollinators, the soil microbes, and the birds that pass through it. A forest is a commons shared by the trees, the fungi connecting their roots, the animals that live within it, and the streams that run through it. Each participant takes what it needs and returns what it can. The system holds because the participants hold it together, not because anyone manages it.
Human communities have long organized around commons of their own — grazing land, fisheries, irrigation systems, village wells, public squares, libraries, seed banks. The work of Elinor Ostrom showed that these arrangements persist, successfully, when the community around them holds practices of reciprocity, restraint, shared decision-making, and mutual accountability. Human commons do not survive on their cleverness. They survive on the care of the people who tend them, and they work best when they sit honestly within the ecological commons that sustains them.
An ecological commons, in the sense this project means, is a human arrangement in service of something larger than data: the ecological knowledge and wisdom that have accumulated in particular hands — researchers, practitioners, field observers, stewards, indigenous communities, long-standing programs — and that most people have no ready way to reach. A commons is one way that knowledge becomes available to everyone, so that more of us can live, decide, and act in closer relationship with the living world.
The material of this commons is broad. Species lists, field observations, survey notes, restoration logs, seed records, community classifications, taxonomic references, soils, weather, images, measurements, histories. Some of it is the product of rigorous science. Some of it is carefully held by people and programs working close to the ground. All of it is knowledge that someone, somewhere, already knows — and that someone else, somewhere else, could act on if only they could find it.
The commons is a shared practice and shared infrastructure for describing that knowledge honestly, making it findable, and making it reachable by the people and tools that need it. Attribution is real and visible. What grows from the commons is a community of participants and layers of trust, not a database.
What makes this particular type of commons possible now is that the infrastructure for such a thing is finally unremarkable. Databases, APIs, provenance tracking, consistent interfaces — the pieces required to make a commons of knowledge reachable are standard. What is hard in this time is not the technology. It is the combination of knowing what the knowledge means, caring about how it is represented, and holding the human practice that makes the whole thing more than a technical exercise.
An ecological commons is an attempt to do that work in the open, at whatever scale people and organizations are ready to hold. It begins where it begins — in this case, in Southeast Michigan with a small number of integrated sources and a regional program already practicing what a commons asks of its participants. It might be a timely idea and have a useful shape. It grows as others choose to be part of it.
Why infrastructure isn’t enough
Building the infrastructure is the easier half. The harder half is everything that determines whether a shared system actually gets used — how organizations decide to contribute data, how different communities find ways to work without forcing consensus, how decisions get made, how systems persist, and how trust is held as new kinds of participants enter the picture.
Two traditions of scholarship and practice have already done serious work on what this commons is trying to become. The information sciences — commons governance, data stewardship, boundary objects, knowledge infrastructures — have studied for decades what makes shared systems work or fail. The computing sciences — federated architectures, grounded synthesis, autonomous development — are active frontiers where the tools being built today will shape what an ecological commons can become. The lessons from both are available to be applied and this application, we think, holds some community-enhancing potential.
What becomes possible
The cost of building working software is collapsing. So is the cost of having a question and getting a grounded answer. Against a commons of honest data about the living world, these two shifts mean something specific: the questions people actually ask, and the answers too, can grow into tools that people actually use.
People ask “these” questions constantly. At native plant sales. At workshops. At preserves. In classrooms. On porches. The same questions, over and over, because the answers are scattered across databases, scientific papers, nursery staff memory, and the accumulated experience of volunteers — and there has never been an approach or a system that could simply answer them. The bones of such a solution now exist.
What should I plant here, given my soil and my light, to support the most life?
What was growing on this ground before it was a lawn?
Which plants in my garden are safe around my dog? Around children?
Where are the gaps in my yard’s bloom calendar, and what could fill them?
Is this plant invasive, and what should replace it?
What would this half-acre look like in five years if I kept planting? In ten?
How does my yard connect to my neighbors’ yards as habitat? Where would a single well-placed plant close a gap?
What seeds can I collect nearby, at what time of year, and how do I grow them?
What does a healthy version of this kind of place look like — a mesic southern forest, a wet prairie, a fen — and how far is this site from that?
Where did this recommendation come from, and should I trust it?
I’m a teacher. Can my class build an ecological network for our school grounds?
I’m a volunteer crew leader. What should we prioritize at this preserve today?
I’m twelve years old, and I want to do a real science project on the pollinators in my neighborhood. What should I look for?
Each one of these is something someone can now build an answer to. Not a funded team — anyone with the question and the care to see it through.
The questions in the list are the ones people already ask. The more interesting possibilities are the ones no one has thought to ask yet — the ones that require both a commons of trustworthy knowledge and the ability to build against it cheaply, conditions that have not existed together before this moment.
For the first time, what gets built can be shaped by what would actually help.
What this could become
More data can be added. The integration pattern is small and repeatable. As more sources are described and brought in, the commons gets richer. Some of that will be data from regional organizations and programs. Some of it will be data from community science — iNaturalist, eBird, Nature’s Notebook, and the many smaller observation projects that exist. Hosting community science datasets directly, with their full context and provenance preserved, is one of the simpler things a commons can do.
People can build against it. The commons is most useful when the people closest to the questions are the ones building the answers. Bootcamps for community scientists, crew leaders, teachers, and young naturalists — showing them how to use the tools now emerging to build against the commons — are a direct implication of what is becoming possible.
People can gather around it. A commons requires the people who hold and use the knowledge to talk to each other. A community symposium — data holders, regional organizations, indigenous communities, practitioners, researchers, agencies, nurseries — is where the shape of the commons gets discussed by the people it serves.
Why shared data infrastructure requires more than engineering
Suppose you build a system that makes ecological data from dozens of public sources findable, reachable, and usable through a consistent interface. The technologies are proven. Now suppose you want the system to serve practitioners beyond your own region, to get heritage programs and universities to contribute their data, and to persist for decades. This is where the technical problem ends and a different class of problem begins. Decades of research in information science and commons governance have identified these problems, why they are hard, and what makes solutions work. The following concepts are operational requirements for any shared data infrastructure that intends to scale.
Knowledge infrastructures are social systems, not just technical ones
A knowledge infrastructure is the full network of people, institutions, standards, practices, and technologies that together produce, share, and maintain knowledge. The term was formalized by Edwards, Borgman, Bowker, and colleagues at a 2012 workshop at the University of Michigan. Their central finding: the technical systems are only one layer. The infrastructure also includes institutional agreements about who contributes data, professional norms about how data is described, funding models that keep systems running, and social relationships that make collaboration possible. When shared data systems fail, the cause is almost never a software bug. It is a breakdown in the social or institutional layer.
Data friction and institutional trust
Organizations that hold valuable data routinely decline to share it, even when sharing would benefit everyone. Contributors worry about losing credit, about others misinterpreting data collected under specific conditions, about revealing gaps in their records, and about losing control over how their data is represented. Researchers call this data friction — the social and institutional resistance that prevents data from moving between organizations. The friction is not technical. The data could be shared with a file transfer. The barriers are trust, credit, control, and incentive structures that reward data collection but not data sharing. Any system depending on multiple organizations contributing data must design for these barriers explicitly, or it will have excellent architecture and empty tables.
Commons governance
In 1990, Elinor Ostrom demonstrated — and later received the Nobel Prize for showing — that communities worldwide have managed shared resources for centuries without privatizing them or handing control to a central authority. She identified design principles shared by long-enduring commons: clear boundaries, rules matching local conditions, collective decision-making, community-accountable monitoring, graduated consequences, accessible conflict resolution, and nested governance connecting local management to larger systems. Recent work has applied these principles to digital data commons, finding that the same logic holds: shared data infrastructure needs clear rules about who contributes, who benefits, how decisions are made, and how the system sustains itself. Without these structures, shared systems collapse through neglect or get captured by the most powerful participant.
Boundary objects and coordination without consensus
Different communities can collaborate around shared artifacts even when they understand those artifacts differently. Star and Griesemer identified this pattern in 1989, studying how amateur collectors, professional scientists, and administrators all contributed to a natural history museum despite having different goals. The shared artifacts — specimens, field notes, standardized forms — were flexible enough to serve each group while stable enough to hold the collaboration together. In shared ecological data infrastructure, species names, community classifications, and site data function the same way: a restoration practitioner, a network ecologist, and a nursery owner all use them differently, but they need the same underlying data. Designing shared reference points that serve multiple communities without forcing consensus is an active design challenge, not a technical default.
FAIR principles and data stewardship
The FAIR principles — Findable, Accessible, Interoperable, Reusable — published in 2016, are the international standard for scientific data management. They require rich metadata, searchable repositories, machine-readable formats, and clear licensing. The CARE principles for Indigenous Data Governance extend this to address collective benefit, authority, responsibility, and ethics — recognizing that technical accessibility does not resolve who should control data and who should benefit. GBIF, the largest biodiversity data aggregator with over two billion records, has adopted both frameworks. Any new ecological data infrastructure operates within this established landscape of principles, standards, and expectations.
Bridging expert data and public use
Most shared data infrastructure is designed by researchers for researchers. The interfaces assume users who understand domain vocabulary and conventions. But the people making daily decisions about landscapes — homeowners, volunteer crews, municipal land managers, school garden coordinators — need the same underlying knowledge delivered in a form that they can act on. A homeowner deciding what to plant deserves to know whether a recommendation comes from a state botanist or a general algorithm, while the interface and framing must differ fundamentally from a research dashboard. Serving both audiences from the same data layer — without dumbing down the data or overwhelming the practitioner — is a design problem at the intersection of information science, ecology, and community engagement that most data infrastructure simply ignores.
Infrastructure sustainability
Building shared data infrastructure is easier than sustaining it. Systems depending on a single grant, a single maintainer, or a single institution routinely fail when that support disappears. The systems that persist — GBIF (2001), ICPSR (1962), the Catalogue of Life (2001) — share common characteristics: distributed governance so no single withdrawal is fatal, sustained value to enough stakeholders that defunding becomes politically costly, and communities of practice that maintain institutional knowledge across personnel changes. Sustainability is not an afterthought. It is a design requirement that shapes architecture, governance, and partnership strategy from the beginning.
Designing for careful use
A commons of this kind will be used in ways its designers cannot fully anticipate. People will reach into it directly. Software built on top of it will reach into it on behalf of people. New kinds of tools, including ones that leverage powerful capabilities that did not exist a few years ago, will be built against it. Some of that software will be written by hand. Increasingly, much of it will be assembled by automated systems working from specifications.
None of this is categorically new. Any system built on powerful capabilities — a library, a database, a service, a model — has to be designed with care for relevant failure cases and the assumptions built into it. Systems that ignore this tend to fail in ways that are structural rather than intentional: the component did what it was designed to do, but something outside the system changed, or an assumption the designer made turned out to be wrong.
For a commons of ecological knowledge, the implication is direct. A source described honestly — what it is, who made it, how it was derived, what it does and does not cover — is a source that can be used carefully by whatever is referencing it, whether that is a person, a piece of software, or a system assembling an answer from many sources at once. The commons does not have to solve every question of trust and safety in how its data gets used. It has to be honest about what it holds, so that the systems built on top of it have something real to reason over.
Why this matters for scaling
Everything above has the same implication: a technically successful system for one region does not automatically become infrastructure that works across regions. Scaling requires solving institutional trust, commons governance, boundary object design, FAIR-compliant stewardship, practitioner-facing interfaces, and long-term sustainability — none of which are engineering problems.
If the goal is a restoration tool for one community in Southeast Michigan, the technical components alone are sufficient. If the goal is a commons that enables any community, anywhere, to reach the ecological knowledge they need, then every concept on this page is a prerequisite — and each one represents a body of research and practice that can be applied.
A computing frontier
Where this work meets active problems in computing research and practice
An ecological commons rests on decades of well-established computing patterns and touches several modern frontiers. Both matter to what gets built.
What is already established
Federation is one of the oldest patterns in networked computing. The internet itself is a federation. DNS has worked this way since 1983. Email since 1982. GBIF has federated biodiversity data across national nodes since 2001. Federation means many independent systems sharing enough common ground to interoperate, while each participant keeps control of its own corner. Ecological knowledge is inherently regional — what grows together in Michigan is not what grows together in Oregon — and federation is the shape that matches the underlying knowledge. The commons is being built as a federation from the start.
Provenance tracking is the record of where a piece of information came from and what was done to it. The discipline has mature frameworks, standard representations, and decades of research behind it. Every record the commons serves carries its derivation, preferably in forms that satisfy broad descriptive needs.
Relational databases, APIs, caching, geospatial indexing, federated schemas — the pieces required to build something of this shape are standard infrastructure. None of it is exotic.
Two years ago, this commons could not have been built. The tools to specify, assemble, and maintain a system of this shape at the speed and cost a small team can carry did not yet exist. Anyone who can describe clearly what a system should do can now build it.
Grounded synthesis
When a tool answers a question by assembling information from multiple sources, the answer’s value depends on the grounding. An answer that reads fluently but misrepresents its sources, or hides their disagreements, is worse than no answer. The research area sometimes called retrieval-augmented generation, and more broadly grounded synthesis, is about building systems that assemble answers while preserving attribution and honoring what each source actually says. A commons where every source is honestly described and every record carries provenance is structured ground for that work.
Agents as participants
A commons now has two kinds of participants reaching into it: people and software that reaches in on behalf of people. Increasingly, that software was itself written by an agent working from a specification. The commons’s responsibility is the same in either case:
- describe what it holds honestly, so whoever or whatever is reaching in has something real to reason about
- offer access mechanisms that serve the requester
- provide access layers that capture and offer trust evaluations for a wide set of domains, regions, or use cases
Complex systems behavior
When many components interact within a system — some human, some automated, some autonomous — the system’s behavior is not determined by any single component. Useful things emerge. So do surprises. Failures in complex systems are usually not intentional errors by any participant. They are structural: each component did what it was designed to do, and the interaction produced something no one designed. The discipline of anticipating and monitoring this behavior is its own field of practice.
The shift in how software gets built
The way software gets made is changing fast. Before 2025, the standard pattern was a team of developers writing code by hand over months and years. 2026 sees working systems built by small teams who specify what the software should do in natural language, let autonomous agents implement against those specifications, and use independent evaluation systems to check the result. The trajectory is towards carefully structured automation, agentic frameworks guided by extensive context guidance, and humans defining what should be built.
What remains for humans is the most important part. We can learn to do that by judging carefully, specifying clearly, and understanding the world and our systems as a whole. Indeed, if implementation becomes trivial, we have the opportunity to focus on what really matters — deciding together what should exist.