Chapter 35: Governance Models and Stewardship

Chapter Overview

Governance is the question every community mapping project eventually confronts: who decides? Who owns the data? Who can use it, modify it, or shut it down? This chapter examines the structures, models, and practices that determine how community maps are controlled, maintained, and sustained over time. From community advisory boards to data trusts, from open licensing to funder relationships, governance shapes whether a map serves its community or becomes another tool of extraction.

Learning Outcomes

By the end of this chapter, you will be able to:

Explain why governance matters in Community Mapping and what happens when it is absent
Identify and compare governance models, including advisory boards, data trusts, and cooperatives
Analyze how open source principles apply to Community Mapping governance
Evaluate licensing choices and their implications for data reuse and control
Recognize the challenges of sustaining community maps over time
Articulate the tensions between funder requirements and community authority
Apply governance frameworks to real or hypothetical community mapping projects

Key Terms

Governance: The systems, processes, and structures that determine who has authority over a community map and its data.
Data Trust: A legal structure where data is held in trust for a community, with trustees responsible for managing it in the community's interest.
Data Cooperative: A member-owned organization that collectively governs data and decides how it is used.
Open Data License: A legal framework that permits reuse, modification, and redistribution of data, often with conditions like attribution or share-alike.

35.1 Who Decides

The first governance question is the most fundamental: who gets to make decisions about the map?

In many community mapping projects, this question is never explicitly asked. A nonprofit launches the project, builds the map, collects the data, and assumes it owns everything. A municipal planner commissions a map and assumes it belongs to the city. A researcher maps a community for a thesis and takes the data with them when they leave. In each case, the community members whose knowledge, stories, and places are represented have no formal authority over what happens next.

This is not governance — it is extraction with better PR.

Real governance means creating formal structures that give communities authority over the mapping process and its outputs. It means deciding, in advance and collectively, who can access the data, who can edit it, who can publish it, who benefits from it, and who has the power to end the project if it stops serving the community's interests.

Governance decisions shape everything downstream. They determine whether a map becomes a tool for community empowerment or a dataset harvested for outside use. They determine whether the map is maintained and updated or abandoned once the grant funding runs out. They determine whether the community can say "no" when a corporation or government agency wants access to sensitive data.

Without governance, the default is that power flows to whoever has the technical skills, the funding, or the institutional authority. With governance, power can be distributed more equitably — and held accountable.

The challenge is that governance is hard. It takes time, energy, and sustained attention. It requires clear roles, transparent decision-making processes, and mechanisms to resolve conflict. It requires documentation — bylaws, terms of reference, data policies. It requires people willing to take on leadership, and structures that prevent any one person or organization from dominating.

But the alternative — no governance — is worse. Without it, community maps become ghost infrastructure: built with enthusiasm, abandoned when the founder leaves, and leaving communities with nothing but screenshots and broken links.

35.2 Community Advisory Boards

One of the most common governance structures in community mapping is the community advisory board (CAB). A CAB is a group of community members, leaders, and representatives who provide oversight, guidance, and accountability to the project.

The composition of a CAB matters. At minimum, it should include:

Residents from the mapped community, representing different demographics, neighborhoods, and perspectives
Representatives from key community organizations (nonprofits, cultural groups, faith communities)
Elders or long-time residents who hold institutional memory
Youth or emerging leaders
People with lived experience relevant to the mapping focus (e.g., people experiencing homelessness in a housing vulnerability map, or Indigenous knowledge keepers in a cultural mapping project)

A CAB typically meets regularly (monthly or quarterly) to review progress, provide feedback, validate findings, raise concerns, and advise on decisions. In a strong governance model, the CAB has real authority — not just the ability to offer suggestions, but the power to approve or veto decisions about data use, publication, partnerships, and funding.

In practice, CABs often struggle with power imbalances. The project lead or host organization may control the agenda, the budget, and access to the data. Board members may not have technical skills or may feel intimidated by jargon. Tokenism is a persistent risk: a CAB that exists to legitimize decisions already made elsewhere, rather than to exercise genuine authority.

To mitigate these risks, effective CABs:

Are compensated for their time and expertise (stipends, honoraria, or in-kind support)
Receive training on data governance, privacy, and mapping ethics
Have clear terms of reference that define their role, authority, and decision-making process
Meet in accessible formats and languages
Are supported by staff or facilitators who can translate technical issues into plain language
Have the power to say "no" — and a process for resolving disagreements

A CAB is not the same as community control. It is a form of community input, but it does not replace the need for broader participation, consent, and accountability. Still, a well-structured CAB is far better than the alternative: an organization making all decisions internally and calling it "community-based" because they talked to a few people once.

35.3 Data Trusts and Data Cooperatives

As concern over data exploitation has grown, new legal and organizational structures have emerged to give communities more control. Two of the most promising are data trusts and data cooperatives.

A data trust is a legal arrangement where data is placed in the hands of a trustee, who manages it on behalf of a defined group of beneficiaries — in this case, the community. The trustee has a fiduciary duty to act in the beneficiaries' best interest, not their own. This creates a legal obligation to protect community interests, not just a moral commitment.

Data trusts are still evolving, and the legal frameworks vary by jurisdiction. But the core concept is powerful: the community mapping data does not belong to the nonprofit that collected it, the researcher who analyzed it, or the funder who paid for it. It belongs to the community, and the trust structure enforces that.

The UK Open Data Institute has developed frameworks for civic data trusts, and pilot projects are underway in health, mobility, and urban planning. In the Community Mapping context, a data trust could govern a long-term asset map, ensuring that even if the original organization dissolves, the data remains under community authority.

A data cooperative is a member-owned organization where members collectively decide how data is used. Cooperatives are familiar structures in agriculture, energy, and finance; applying them to data governance is newer but growing. In a data cooperative, community members (or organizations representing them) become members with voting rights. Major decisions — such as whether to share data with a corporation or government, whether to commercialize the data, or whether to end the project — are made democratically.

The Salus Coop in Spain is one example, providing healthcare data governance through a cooperative model. In Aotearoa New Zealand, Māori communities have developed data sovereignty frameworks that function similarly, placing authority with iwi and hapū rather than with external institutions.

Data cooperatives can be resource-intensive to establish and maintain. They require legal incorporation, bylaws, membership structures, and ongoing governance capacity. But for long-term, high-stakes community mapping projects — especially those dealing with vulnerable populations or sensitive data — the investment can be justified.

Both data trusts and cooperatives offer something that advisory boards alone do not: legal standing. They turn community authority from a moral principle into a legally enforceable reality.

35.4 Open Source as Governance

Another governance model, borrowed from software development, is open source. In an open-source model, the data, code, documentation, and methods are made publicly available under a license that permits reuse, modification, and redistribution.

The most prominent example is OpenStreetMap (OSM), a global collaborative mapping project governed by the OpenStreetMap Foundation. Anyone can contribute. Anyone can use the data. The governance happens through a combination of community norms, technical infrastructure (version control, change tracking, dispute resolution), and foundation oversight.

Open source governance has strengths:

Transparency: All changes are visible, traceable, and reversible.
Distributed authority: No single organization controls the map.
Resilience: If one contributor or host leaves, the project can continue.
Adaptability: Users can fork the project, creating customized versions for specific needs.

But open source governance also has limitations in the Community Mapping context:

Volunteer labor: OSM depends on unpaid contributors, which can replicate inequities (who has time to map?).
Technical barriers: Participating meaningfully in OSM requires skills and tools that many community members lack.
Lack of formal accountability: There is no legal mechanism to ensure the map serves a specific community's interests.
Public-by-default: Open source typically means open data, which is inappropriate for sensitive community information.

Despite these limitations, open source principles can be adapted. A community mapping project might:

Use open-source tools (QGIS, PostgreSQL, OpenStreetMap tools) to avoid vendor lock-in
License non-sensitive layers openly while restricting sensitive data
Document methods and code transparently so others can learn and replicate
Adopt version control and change-tracking practices to maintain transparency

Open source is not a complete governance model for Community Mapping, but it offers valuable tools and principles — especially around transparency, collective stewardship, and resistance to proprietary control.

35.5 Licensing and Reuse

Governance is not just about decision-making structures — it is also about the legal frameworks that govern how data can be used. This is where licensing matters.

A license is a legal instrument that defines what others can and cannot do with the data. Without a clear license, users have no legal certainty about whether they can use, share, or modify the data. And without legal certainty, the data is effectively locked.

The Creative Commons family of licenses is widely used for open data. Each license makes different commitments:

CC0 (Public Domain): No restrictions. Anyone can use the data for any purpose, with no attribution required.
CC BY (Attribution): Users can do anything with the data as long as they credit the source.
CC BY-SA (Attribution-ShareAlike): Users can use and modify the data, but any derivative work must be shared under the same license. This prevents someone from taking open data, adding value, and then locking it behind paywalls.
CC BY-NC (Attribution-NonCommercial): Users can use the data for non-commercial purposes only. This protects against corporate extraction, but it also limits community organizations that generate revenue.

In the mapping world, the Open Database License (ODbL), used by OpenStreetMap, functions like CC BY-SA but is tailored to databases. It requires attribution and share-alike, ensuring that improvements to the data remain open.

Licensing decisions have strategic implications. A community mapping project that wants to maximize reuse and impact might choose CC BY. A project concerned about corporate extraction might choose CC BY-NC or CC BY-SA. A project that wants to place the data fully in the public domain might choose CC0 — though this removes all control, including the ability to prevent harmful use.

There is no one-right-answer. The choice depends on the community's values, the sensitivity of the data, and the desired balance between openness and control.

It is also worth noting that not all data should be licensed openly. Sensitive data — such as locations of vulnerable individuals, sacred sites, or high-risk assets — should be governed under restricted-access agreements, not open licenses. Chapter 32 discussed privacy; here the governance lesson is: clarity about who can access what, under what conditions, enforced through both technical and legal mechanisms.

35.6 Sustaining Community Maps

A community map is only as good as it is current. Outdated data misleads. Broken links erode trust. Abandoned platforms become digital graveyards. Sustaining a community map requires resources, commitment, and governance.

The sustainability challenge has multiple dimensions:

Technical sustainability: Servers cost money. Domains expire. Software requires updates. Platforms get deprecated. A map built on proprietary software that the vendor discontinues becomes inaccessible. A map hosted on a free platform that changes its terms of service can disappear overnight. Technical sustainability requires choosing stable, maintainable platforms — often open-source tools hosted on infrastructure the community controls or on reliable institutional servers with long-term commitments.

Financial sustainability: Community mapping projects often start with grant funding. When the grant ends, so does the map. Financial sustainability means identifying ongoing revenue sources: municipal funding, organizational operating budgets, user fees (controversial but sometimes necessary), or collaborative funding models where multiple stakeholders share costs.

Human sustainability: Maps need people — to update data, respond to inquiries, validate changes, and make governance decisions. Volunteer energy fades. Staff turn over. Human sustainability means building redundancy (multiple people trained), documenting processes, and creating roles that survive individual departures.

Data sustainability: Data decays. A business closes. A service moves. A contact changes. Data sustainability requires a commitment to ongoing updates, validation protocols, and clear accountability for who is responsible.

Many community mapping projects fail not because they were poorly designed, but because no one planned for what happens after year one. Governance structures should include:

A sustainability plan that identifies ongoing costs, revenue sources, and responsible parties
A succession plan for leadership transitions
A maintenance schedule for data updates and technical upkeep
A decision rule for when to archive, sunset, or retire the map (see 35.9)

Sustainability is not glamorous. It is not fundable in the same way a new, exciting project is. But it is essential. A map that lasts five years and remains accurate is worth more than ten maps that launch with fanfare and die within a year.

35.7 Funder Relationships and Strings

Most community mapping projects depend on external funding — from foundations, government grants, or corporate sponsors. Funders shape the project in visible and invisible ways. Governance must account for this.

Visible strings are the explicit requirements in grant agreements: deliverables, timelines, reporting, evaluation, and restrictions on how funds can be used. These are negotiable, to a degree. A community organization proposing a mapping project can push back on requirements that undermine community authority — such as demands that all data be made public, or that the funder have veto power over publications.

Invisible strings are subtler. Funders signal what they value through their RFPs, their funding priorities, and their past decisions. Organizations respond by shaping projects to fit funder preferences, even when those preferences do not align with community needs. A foundation interested in "innovation" might fund a flashy app over a long-term asset map. A government funder focused on service efficiency might prioritize needs mapping over asset mapping. Over time, this shapes what gets mapped, what gets ignored, and whose knowledge counts.

Governance must create space to ask hard questions:

Does this funding advance the community's priorities, or the funder's?
What compromises are we making to secure funding, and are they acceptable?
If the funder's goals diverge from the community's, whose goals win?
What happens to the map when the funding ends?

Best-practice funders recognize these dynamics and structure grants to support community authority:

Unrestricted or flexible funding that allows communities to define their own priorities
Multi-year commitments that enable long-term planning and sustainability
Support for governance capacity-building, not just technical outputs
Willingness to fund maintenance, not just new projects
Transparency about the funder's own interests and constraints

Best-practice community organizations:

Negotiate grant terms that protect community authority
Diversify funding sources to reduce dependence on any one funder
Say "no" to funding that comes with unacceptable strings
Build reserves or endowments to reduce reliance on short-term grants

The hard truth is that funder relationships are power relationships. Governance structures that acknowledge this, and build in safeguards, are stronger than those that pretend funders are neutral partners.

35.8 Conflict, Disagreement, and Repair

Governance is not just about making decisions — it is about what happens when people disagree. In community mapping, conflict is inevitable. Residents disagree about what should be mapped. Organizations compete for credit. Data reveals uncomfortable truths. Funders and communities clash over priorities.

Effective governance anticipates conflict and builds in mechanisms for repair.

Conflict resolution processes should be defined in advance:

Who mediates disputes?
What is the process for raising concerns?
How are decisions appealed or revisited?
What happens if a core partner withdraws?

Some projects establish a dispute resolution committee, separate from the advisory board, to handle conflicts impartially. Others use external mediators, especially when conflicts involve power imbalances (e.g., between a well-resourced institution and a grassroots group).

Transparency helps prevent conflict from escalating. When decisions, data, and methods are visible, disagreements can focus on substance rather than suspicion. When governance is opaque, conflict becomes personal.

Repair is as important as resolution. A conflict resolved through a formal process may leave relationships damaged. Repair might involve:

Acknowledging harm done
Committing to changed practices
Rebuilding trust through follow-through
Making amends where possible

Indigenous governance traditions often emphasize repair over punishment. Rather than asking "who was wrong?" the focus is on "how do we restore balance?" Community mapping governance can learn from this.

Not all conflicts are resolvable. Sometimes values are irreconcilable. Sometimes relationships are too damaged. In those cases, governance should include an exit process: how does a partner leave without destroying the project? How is data divided or archived? What responsibilities remain?

Conflict is not failure. It is a sign that people care enough to fight for what matters. Governance that treats conflict as normal, and builds capacity to navigate it, is more resilient than governance that avoids hard conversations until it is too late.

35.9 Sunset Clauses and Map Lifecycles

Not all community maps should live forever. Some are project-specific: a one-time assessment, a snapshot for a report, a campaign map. Others are meant to be ongoing but lose relevance, funding, or community support over time. Governance should include a plan for the end.

A sunset clause is a predetermined condition under which the project ends. Examples:

The map will be retired after three years unless a community review votes to continue.
If no one updates the data for six months, the map will be archived.
If the original funder withdraws and no replacement funding is found, the project will conclude within one year.

Sunset clauses prevent zombie projects — maps that linger online, outdated and misleading, because no one has the authority or capacity to shut them down.

Archiving is different from deletion. An archived map is no longer actively maintained, but it remains accessible as a historical record. Archiving is appropriate when the map represents a snapshot of a moment in time — such as a community mapping project conducted during a crisis, or a participatory mapping workshop.

Retirement means taking the map offline entirely. This is appropriate when:

The data is too outdated to be useful and risks causing harm
The community withdraws consent for continued public access
Legal or ethical concerns make continued publication inappropriate

Retirement does not mean destroying the data. Data can be preserved in restricted-access archives, available to researchers with community permission, while the public-facing map is taken down.

The lifecycle of a map should be documented:

Launch: When did the map go live, and under what governance?
Updates: When and how is data refreshed?
Review: When is governance reviewed and renewed?
Transition: What happens if leadership or hosting changes?
Sunset: Under what conditions does the map end?
Archive or retirement: What happens to the data after the map is no longer active?

Planning for the end is not pessimistic — it is responsible. It prevents harm, preserves community authority, and ensures that when a map does end, it ends with dignity rather than neglect.

35.10 Synthesis and Implications

This chapter has traced governance from its foundational question — who decides? — through structures, models, and challenges. It has moved from community advisory boards to data trusts, from open licensing to funder dynamics, from conflict resolution to map lifecycles. Now it is worth pulling together what Part VI as a whole has established, and what comes next.

Part VI opened with ethics (Chapter 31): the commitment to "do no harm," the centrality of consent, the obligation to center community authority. Chapter 32 examined privacy — what it means to map people without exposing them, how to balance transparency and protection, and why anonymization is not enough. Chapter 33 addressed Indigenous data sovereignty, grounding the principle that Indigenous Peoples have the right to govern data about their communities, territories, and knowledge. Chapter 34 explored power — who benefits, who is excluded, how maps reproduce or challenge existing hierarchies.

Governance, the subject of this chapter, is where all these threads come together. Governance is the mechanism through which ethics are enforced, privacy is protected, sovereignty is respected, and power is held accountable. Without governance, the values articulated in Chapters 31–34 remain aspirations. With governance, they become enforceable commitments.

The practical lesson: governance is not optional. Every community mapping project, from a one-day participatory workshop to a decades-long municipal asset map, needs to answer the governance questions: Who decides? Who benefits? Who is accountable? How are decisions made? What happens when things go wrong?

The models presented here — advisory boards, data trusts, cooperatives, open-source frameworks, licensing choices — are tools, not prescriptions. The right governance structure depends on the context, the community, the resources available, and the values at stake.

But some principles hold across contexts:

Community authority must be real, not performative. Governance structures that give communities advisory roles without decision-making power are forms of consultation, not governance.
Transparency matters. Decisions, data, and methods should be visible and documented.
Sustainability requires planning. Maps that are not maintained become liabilities.
Conflict is normal. Governance should anticipate it and build capacity to repair.
All maps eventually end. Planning for sunset or archiving is an act of respect.

These are the foundations of stewardship. And stewardship is what distinguishes a community map from a dataset.

Looking ahead to Part VII: Analysis and Interpretation, governance remains relevant. The analytical methods, spatial tools, and interpretive frameworks explored in Part VII are not neutral techniques. They are shaped by who has authority to ask questions, define problems, and frame findings. A map analyzed without community input may produce technically correct insights that miss the lived reality. A map interpreted by outsiders may reinforce harmful narratives. Governance ensures that analysis serves the community's understanding, not just the analyst's agenda.

35.11 Governance Charter Workshop

Purpose: This exercise guides you through drafting a governance charter for a real or hypothetical community mapping project, translating the principles in this chapter into concrete commitments.

Materials Needed:

Blank paper, digital document, or shared whiteboard
Access to examples of governance documents (sample bylaws, terms of reference, or data policies)
If working in a group, a facilitator

Steps:

Define the project. Briefly describe the community mapping project you are chartering. Who is the community? What is being mapped? What is the purpose? Who initiated the project?
Identify stakeholders. List everyone who has a stake in the project: community residents, organizations, funders, researchers, government agencies, etc. Be specific.
Assign decision-making authority. For each of the following decisions, identify who has the authority to decide (and how):
- What gets mapped
- Who can access the data
- Whether to share data with third parties
- How to handle sensitive or contested information
- Whether to accept funding from a particular source
- When to update or retire the map
Choose a governance structure. Based on Section 35.2–35.4, select a governance model (or combination): Advisory board? Data trust? Cooperative? Open-source? Hybrid? Justify your choice.
Draft key policies. Write one-paragraph policies for:
- Data access: Who can see the data, under what conditions?
- Licensing: What license will govern data reuse?
- Conflict resolution: What happens if stakeholders disagree?
- Sustainability: Who is responsible for maintaining the map, and how will it be funded?
- Sunset: Under what conditions will the map be archived or retired?
Reflect on power. Identify where power imbalances exist in your governance structure. Who has more influence? Who might be excluded? What safeguards can you build in to address this?

Deliverable: A 2–3 page governance charter that includes the project description, stakeholder map, decision-making framework, governance model, policies, and reflection on power.

Time Estimate: 90–120 minutes

Safety and Ethics Notes: If you are drafting a charter for a real project, ensure that the process itself is participatory — do not write a governance charter about a community without the community's involvement. If this is a hypothetical exercise, acknowledge the limitations of designing governance from outside the community context.

Key Takeaways

Governance determines who has authority over a community map, its data, and its future.
Without explicit governance, power defaults to those with technical skills, funding, or institutional authority.
Community advisory boards, data trusts, and cooperatives offer structured ways to center community authority.
Licensing decisions (CC BY, CC BY-SA, ODbL, etc.) shape how data can be reused and who benefits.
Sustaining a map requires technical, financial, human, and data maintenance — and a governance structure that ensures accountability.
Funder relationships involve power dynamics that must be acknowledged and managed.
Governance must include mechanisms for conflict resolution, repair, and, eventually, sunset or archiving.

Plain-Language Summary

Governance is about deciding who gets to make decisions about a community map. Without clear governance, the people or organizations with the most power — usually those with money or technical skills — end up controlling everything. That's not fair, and it's not sustainable.

This chapter looked at different ways communities can take control. Some projects use advisory boards where community members have a real say. Others use legal structures like data trusts or cooperatives, which give communities actual legal authority over the data. Open-source models let anyone contribute and use the data, but they're not always a good fit for sensitive community information.

Governance also means deciding who can reuse the data. Licenses like Creative Commons let you set the rules — whether people have to give credit, whether they can make money from it, and whether they have to share any improvements they make.

Good governance also plans for the long term. Who will update the map? How will it be paid for? What happens if the funder leaves? And eventually, when does the map get archived or shut down?

Maps are powerful. Governance is how communities make sure that power stays in the right hands.

End of Chapter 35.

Chapter 35. Governance Models and Stewardship