Collaborative Maintenance¶

Keep a shared knowledge artifact current through an open community working under five documented-and-exercised governance pathways — proposal, review, dispute resolution, deprecation, and attribution — rather than a single custodian.

Core Idea¶

Collaborative maintenance is the governance arrangement in which a shared knowledge artifact — a controlled vocabulary, ontology, schema, or standards document — is kept current by an open community of users and contributors operating under publicly documented decision rules, rather than by a single custodian working alone.

The OBO Foundry's formulation is the reference case: a resource counts as collaboratively maintained when its governance documentation specifies, and the community actually exercises, at least five coordinated mechanisms. First, a change-proposal pathway — any qualified contributor may open an issue, submit a pull request, or raise a term request through a declared channel, not an ad-hoc back channel. Second, a review-and-approval pathway — designated curators or maintainers assess proposals against published acceptance criteria (scientific accuracy, conformance with existing term structure, avoidance of redundancy), with the decision visible in a traceable record. Third, a dispute-resolution pathway — contested changes escalate through defined steps rather than blocking indefinitely or resolving by whoever shouts loudest. Fourth, a deprecation policy — obsolete or superseded terms are marked deprecated with redirects to current preferred terms, never silently deleted, so existing annotations remain interpretable. Fifth, an attribution and accountability rule — contributors are credited, and the provenance of each change is recoverable from the version history.

The pattern is constitutively ongoing: a one-off act of community contribution does not qualify. The resource is treated as having an indefinite operational lifetime that will continuously require co-stewardship. This is why the maintenance work and the governance overhead are permanent features of the arrangement, not tasks to complete and close.

The structural effect is to distribute custodial labor that would otherwise concentrate in a single point of failure, while converting what would otherwise be a commons-herding problem — many users benefiting, few contributing — into a structured division of maintenance labor with explicit accountability for who changed what and why. The Gene Ontology is the canonical worked instance: term proposals arrive through a GitHub issue tracker, a curator panel reviews on a defined release cadence, content disputes escalate to periodic content meetings, and deprecation follows a published policy with documented redirects. The same governance shape recurs in the Linux kernel's maintainer hierarchy, in IETF working-group review cycles, and in Wikipedia's editorial policy apparatus — each is a different instantiation of distributed stewardship over a shared knowledge or standards artifact under explicit decision norms.

Structural Signature¶

Sig role-phrases:

the shared artifact — a controlled vocabulary, ontology, schema, or standards document whose value depends on staying current and interpretable
the open contributor community — qualified users and maintainers who both benefit from and supply upkeep, in place of a single custodian
the indefinite-lifetime commitment — the artifact is treated as having an ongoing operational life requiring continuous co-stewardship, not a task to close
the change-proposal pathway — a declared channel through which any qualified contributor opens a term request, issue, or pull request
the review-and-approval pathway — designated curators assess proposals against published acceptance criteria, with the decision left in a traceable record
the dispute-resolution pathway — contested changes escalate through defined steps rather than stalling or resolving by whoever holds commit access
the deprecation policy — obsolete terms are marked and redirected to current preferred terms, never silently deleted, so downstream annotations stay resolvable
the attribution-and-provenance rule — contributors are credited and each change is recoverable from version history, so errors can be audited back to a decision
the distribution-of-custodial-labor outcome — upkeep that would concentrate in a single point of failure is spread across the community with explicit accountability

What It Is Not¶

Not "the repository is busy." Frequent commits, an active issue tracker, and a named institutional host establish activity, not collaborative maintenance. High traffic over an undocumented decision rule is the signature of a single fast custodian — one departure from death however lively it looks — while the arrangement is defined by whether the proposal, review, dispute, deprecation, and attribution pathways are documented and exercised, not by how much motion the repository shows.
Not a one-off act of community contribution. A burst of crowd input that produces an artifact nobody is committed to keep current is a different regime entirely. The load-bearing feature is the indefinite-lifetime commitment — the resource is treated as having an ongoing operational life requiring continuous co-stewardship — so a finished, frozen crowd-built artifact falls outside the concept rather than being a weak instance of it.
Not a decision rule. Consensus, curator authority, and working-group vote are interchangeable fillings of the review-and-approval slot, not synonyms for the arrangement. A resource does not become more or less collaboratively maintained by switching from consensus to curator authority; changing the rule inside the machinery does not change whether the machinery is present.
Not "good governance" or a guarantee of quality. That the five pathways are documented and live establishes a standing arrangement, not that its decisions are wise or its acceptance criteria sound. Collaborative maintenance is a structural property of how upkeep is distributed and made accountable; a community can run all five mechanisms faithfully and still approve poor terms. The concept certifies the machinery, not the verdicts it produces.
Not deletion-tolerant tidying. The deprecation discipline is a first-class requirement, not housekeeping. Silently deleting an obsolete term — however tidy — breaks the maintenance contract, because downstream annotations across the ecosystem must stay resolvable; under collaborative maintenance, retired terms are marked deprecated and redirected to current preferred terms, never removed.

Scope of Application¶

Collaborative maintenance lives across the governance of informational commons — the subfields where a shared, indefinitely-lived knowledge or standards artifact is kept current by distributed voluntary stewardship under explicit decision norms; its reach is within that substrate family (the looser co-stewardship analogues in fisheries or pasture belong to the parent, commons governance, not here).

Open scientific ontologies and controlled vocabularies — the home turf (OBO Foundry, Gene Ontology, EDAM, schema.org): the five-pathway template was formulated here, and term-proposal, curator review, content-meeting escalation, and deprecation-with-redirects are exercised on a defined release cadence.
Public-knowledge wikis — Wikipedia editorial governance and Wikidata property management: open contribution channels, policy-based review, dispute escalation (talk pages, arbitration), and revision-history provenance instantiate the same arrangement over an encyclopedic or structured-data artifact.
Open-source software projects with stated governance models — Linux kernel (maintainer hierarchy, Reviewed-by tags, Linus's release rhythm), Python (PEP process), Kubernetes, Apache: the codebase is the shared artifact, pull-request/issue pathways the proposal channel, and deprecation cycles preserve downstream compatibility.
Standards bodies — IETF working groups (mailing list → working group → Last Call → RFC), W3C consortia, ISO technical committees: the standards document is co-stewarded through documented proposal, review, and dispute-resolution stages with attributable contributors.
Open mapping projects — OpenStreetMap edit-and-review norms: distributed editors maintain a shared geospatial artifact under community rules for contribution, conflict resolution, and change provenance.
Metadata standards, registries, and open-data dictionaries — controlled-vocabulary registries and schema projects beyond the biomedical core, where adopters apply the identical proposal/review/dispute/deprecation/attribution checklist to assess whether the resource will stay current and interpretable.

Clarity¶

Naming collaborative maintenance separates a property that adopters of a shared vocabulary or ontology badly need to assess from the surface features they tend to read it off. Without the concept, "is this resource maintained?" collapses into proxies that mislead — recent commits, an active issue tracker, a named institutional host — none of which establishes that the artifact will stay current and interpretable as the field moves. The term reframes the question structurally: maintenance is not activity but a standing arrangement of pathways — proposal, review, dispute resolution, deprecation, attribution — that are both documented and exercised. An adopter choosing between two ontologies, or a funder deciding what to depend on, can now ask the sharp question (which of the five mechanisms are present, and are they visible in the contribution trace?) rather than guessing from how busy the repository looks.

The concept also sharpens distinctions the governance literature otherwise blurs. It separates collaborative maintenance from one-off community contribution: a burst of crowd input that produces an artifact nobody is committed to keep current is not the same regime, and the indefinite-lifetime commitment is the load-bearing difference. It separates the maintenance machinery from the decision rule running inside it — consensus, curator authority, or working-group vote are alternative review-and-approval mechanisms, not synonyms for the arrangement itself. And it makes the deprecation discipline legible as a first-class governance requirement rather than housekeeping: the rule that obsolete terms are marked and redirected, never silently deleted, is what keeps existing annotations across the ecosystem readable, so a maintainer can now see term-deletion as a breach of the maintenance contract rather than a tidy-up.

Manages Complexity¶

The landscape an adopter or funder actually faces is unmanageably various: thousands of ontologies, schemas, and standards documents, each hosted differently, moving at its own cadence, governed by its own idiosyncratic mix of curators, committees, and conventions. Collaborative maintenance compresses that variety to a fixed, finite checklist — are the five pathways (proposal, review-and-approval, dispute resolution, deprecation, attribution) documented, and are they exercised in the contribution trace? — so that "will this artifact stay current and interpretable?" is read off a small set of present/absent flags rather than reconstructed afresh for each candidate from commit volume, host reputation, and tracker activity. Because the arrangement is constitutively indefinite-lifetime, those flags also fix the qualitative outcome over time: a resource with all five mechanisms live survives custodian departure and propagates fixes, while one missing the deprecation or dispute pathway is predictably brittle in a specific, nameable way. The move is from inspecting a resource's full, particular history to scoring it against one short governance template — and from each adopter independently re-deriving what "maintained" should require to a shared standard every project in the family can be measured against at a glance.

Abstract Reasoning¶

Once a shared artifact is recognized as collaboratively maintained — or as failing to be — the concept licenses a set of governance inferences keyed to the five mechanisms.

Diagnostic (read brittleness off the missing pathway). The mechanism that is absent predicts the specific way the resource will fail, not merely that it will. A vocabulary with a live proposal and review pathway but no deprecation policy is diagnosed as accumulating silent term-deletions, which means existing annotations downstream will become unresolvable — the failure surfaces in consumers, not in the resource's own tracker, which is why it goes unnoticed by activity-watching. A resource with proposal, review, and deprecation but no dispute-resolution pathway is diagnosed as prone to indefinite stalls on contested terms or, worse, resolution by whoever holds commit access — a governance capture signature. A resource with all the change machinery but no attribution/provenance rule is diagnosed as having an unrecoverable change history: when a term's meaning is later questioned, nobody can reconstruct who changed it or why, so errors cannot be audited back to their decision. The move is from a flat observation ("under-maintained") to a named pathology located at a specific pathway, which tells the analyst where the eventual breakage will appear.

Diagnostic (separate the standing arrangement from the activity trace). A busy issue tracker with frequent commits is not evidence of collaborative maintenance, and the concept licenses the inference that high activity over an undocumented decision rule predicts a bus-factor-of-one custodian who is simply fast — the resource is one departure from death regardless of how active it looks. Conversely, a quiet tracker over a fully-documented-and-exercised set of five pathways predicts resilience: low traffic because the artifact is stable, not because it is abandoned. The reasoning inverts the naive activity proxy.

Interventionist (add the pathway, predict the regime shift). To move a single-custodian resource toward collaborative maintenance, the lever is to install and exercise the missing pathway — and the predicted effect is specific to which one. Publishing acceptance criteria and a public review channel converts back-channel term requests into a traceable review-and-approval record, with the predicted effect of distributing the custodial bottleneck and surviving the custodian's departure (the single-point-of-failure is dissolved). Adding an escalation procedure for contested changes has the predicted effect of unblocking stalled terms without ceding them to whoever shouts loudest. Adding a deprecation-with-redirects rule has the predicted effect of keeping the whole downstream annotation ecosystem readable across versions — an effect that lands outside the resource, on its dependents. Each intervention names not just the action but the brittleness it is predicted to remove.

Boundary-drawing (decide whether the concept applies at all). Before scoring a resource, the analyst must decide whether collaborative maintenance is even the right frame. A one-off crowd-built artifact that no one is committed to keep current is out of scope — it lacks the constitutive indefinite-lifetime commitment, so the five-mechanism checklist does not apply and scoring it against the template would mislead. The boundary test is: is the resource treated as having an ongoing operational lifetime requiring continuous co-stewardship? If no, the concept does not bind and the resource should be assessed as a frozen artifact instead. A second boundary separates the maintenance machinery from the decision rule running inside it: consensus, curator authority, and working-group vote are interchangeable fillings of the review-and-approval slot, so a change in decision rule does not change whether the resource is collaboratively maintained — an inference that prevents mistaking a governance-style preference for a governance-regime difference.

Comparative (score and rank candidates against one template). Given two competing ontologies, the concept licenses a direct comparison: score each against the five present/absent flags as visible in its contribution trace, and the resource with more pathways live is predicted to stay current and interpretable longer under field change. This converts "which should I depend on?" from an impression of repository busyness into a defensible ranking on a fixed checklist — and lets a funder or adopter justify the choice by pointing at which mechanisms each candidate has, rather than at how active each looks.

Knowledge Transfer¶

Within knowledge-infrastructure governance the concept transfers as mechanism, not as analogy. A curator trained on the OBO Foundry's five pathways walks into a new schema project, a metadata standard, a controlled-vocabulary registry, or an open-data dictionary and applies the identical checklist — is there a documented change-proposal channel, a review-and-approval pathway with published acceptance criteria, a dispute-escalation procedure, a deprecation-with-redirects policy, an attribution rule? — and reads the same brittleness off the same missing slot. The vocabulary carries intact across the substrate family: open scientific ontologies (OBO, EDAM, schema.org), public-knowledge wikis (Wikipedia editorial governance, Wikidata property management), open-source software projects with stated governance models (Linux kernel, Python, Kubernetes, Apache), standards bodies (IETF working groups, W3C, ISO TCs), and open mapping (OpenStreetMap edit-and-review norms). These are not metaphors for collaborative maintenance; they are co-instances of it. Each is a shared, indefinitely-lived knowledge or standards artifact kept current by distributed voluntary stewardship under explicit decision norms, and the deprecation discipline, the bus-factor diagnostic, and the proposal/review/dispute machinery mean the same thing and predict the same failures in every one. The artifact's content differs — gene terms, RFCs, map tiles, encyclopedia articles — but the governance structure and its diagnostics travel without translation.

Beyond that substrate family the transfer is best read as case (B): a more-general mechanism recurs across genuinely distinct domains while collaborative maintenance's own named machinery stays home-bound. The general pattern that travels is commons governance / distributed stewardship in the Ostrom sense — co-management of a shared resource under community-internal rules: bounded membership, monitored use, graduated sanctions, conflict-resolution mechanisms, nested decision-making. That pattern genuinely recurs in fisheries, irrigation districts, communal pasture, and neighborhood watch as co-instances, none of which is "like" collaborative maintenance by resemblance — they share the abstract co-stewardship mechanism. But what does not travel out is the cargo specific to informational artifacts: the deprecation-with-redirects requirement (which exists because old annotations across an ecosystem must stay resolvable when a term is retired — a constraint peculiar to symbolic, non-rival, versioned artifacts, with no analogue in a fishery, where you cannot "redirect" a depleted stock); the change-proposal/pull-request/issue-tracker pathway (predicated on a digital, forkable, version-controlled artifact); and the provenance-recoverable-from-version-history rule. A fishery is rival and depletable; an ontology is non-rival and degradable-by-neglect-and-fragmentation — so the upkeep problem, while structurally a commons problem, is solved by different concrete machinery. The honest move when the lesson is needed in a non-informational commons is therefore to carry the parent — distributed stewardship of a shared resource under explicit internal rules — and not the named OBO concept, whose five-pathway apparatus is library-and-information-science furniture that does not survive extraction to a pasture. Invoking "collaborative maintenance" for a fishery renames the components and borrows the shape while dropping the artifact-specific machinery that gives the original its diagnostic force; that is analogy, and should be marked as such (see Structural Core vs. Domain Accent).

Examples¶

Canonical¶

The Gene Ontology, curated by the GO Consortium, is the reference instance. Its structured vocabulary of gene-function terms (each carrying a stable identifier of the form GO: followed by seven digits) lives in a public version-controlled repository where anyone can open a term request or correction as a tracked issue or pull request. Designated curators review each proposal against published criteria — biological accuracy, fit with the existing is-a/part-of term structure, non-redundancy — and contested definitions escalate to periodic content meetings rather than resolving by whoever holds merge rights. Crucially, superseded terms are never deleted: they are marked obsolete and, where possible, carry a replaced_by or consider pointer to the current preferred term, so that the millions of downstream gene-annotation records referencing the old identifier stay resolvable. Every change is recoverable from the commit history with its author.

Mapped back: The gene-function vocabulary is the shared artifact; the Consortium's contributors and curators are the open contributor community, standing in for a single custodian. The issue/pull-request tracker is the change-proposal pathway; curator assessment against published criteria is the review-and-approval pathway; content-meeting escalation is the dispute-resolution pathway. The obsolete-with-replaced_by-pointer discipline is the deprecation policy that keeps downstream annotations resolvable, and the authored commit history is the attribution-and-provenance rule.

Applied / In Practice¶

The Linux kernel keeps a single, indefinitely-lived codebase current under the same five-pathway shape without any single owner writing the code. Contributors submit patches by email to the subsystem mailing lists named in the repository's MAINTAINERS file; subsystem maintainers review them, and reviewers and the submitter attach Signed-off-by and Reviewed-by trailers (the Developer Certificate of Origin chain) before a change is accepted. Contested patches are argued out on the public lists and, when needed, escalated up the maintainer hierarchy to Linus Torvalds, who integrates the merge windows on a roughly two-month release rhythm. Rather than deleting supported interfaces, the project runs staged deprecation cycles that preserve downstream compatibility for a stated period before removal. The full authorship trail persists in git history, so any regression can be traced to the patch and person that introduced it.

Mapped back: The kernel source tree is the shared artifact and the worldwide developer base is the open contributor community, kept alive across decades as the indefinite-lifetime commitment. Emailed patches are the change-proposal pathway; maintainer review is the review-and-approval pathway; escalation up the maintainer hierarchy is the dispute-resolution pathway. Staged interface deprecation is the deprecation policy, and the Signed-off-by/Reviewed-by git trail is the attribution-and-provenance rule that spreads upkeep across the community as the distribution-of-custodial-labor outcome.

Structural Tensions¶

T1: Documented versus exercised (the two halves that can come apart). The definition insists each pathway be both written down and actually run, and the interesting failures live in the gap between them. A resource can carry an immaculate governance charter — proposal channel, acceptance criteria, escalation ladder, deprecation policy all specified — while none of it is exercised, so the documentation is theatre certifying a machinery that does not turn. The mirror case is a fast custodian who runs a genuine review discipline entirely in their own head, exercising every pathway informally while documenting none, so the arrangement dies with them. The concept requires the conjunction precisely because either half alone is a known failure mode, yet an assessor scanning a repository sees documents and activity separately and must resist scoring either as sufficient. Diagnostic: For each pathway, can you point to both the written rule and a traced instance of it being run — or only one of the two?

T2: Distributed resilience versus permanent overhead (what the arrangement costs to buy safety). Spreading custodial labor across a community dissolves the single point of failure — the artifact survives any one custodian's departure — but the price is that governance overhead becomes a constitutive, permanent feature rather than a task to finish. Review panels, content meetings, escalation procedures, and provenance discipline are standing costs the arrangement must pay indefinitely because it is defined as indefinite-lifetime co-stewardship. A single custodian is brittle but cheap and fast; the collaborative regime is robust but slow and expensive, and the same machinery that guarantees survival also guarantees that trivial changes route through ceremony. The trade is not eliminable by good design — it is the structural cost of trading a bus-factor-of-one for distributed accountability. Diagnostic: Is the governance ceremony buying resilience the artifact actually needs, or taxing a resource whose lifetime and stakes would be better served by a fast single custodian?

T3: Deprecate-and-redirect versus a growing graveyard (why never-delete cuts both ways). The deprecation discipline — mark obsolete terms and redirect, never silently delete — is load-bearing because millions of downstream annotations must stay resolvable when a term retires; deletion breaks the maintenance contract. But the very rule that protects consumers also forbids ever shrinking the artifact: the vocabulary only accretes, the obsolete-term layer grows without bound, and every consumer must carry logic to chase replaced_by chains that may run several hops deep. Interpretability is bought with permanent bloat and redirection complexity. The tension is that the informational commons cannot be tidied the way a filesystem can — cleanliness and downstream-resolvability are directly opposed, and the governance choice is fixed toward resolvability at the standing cost of an ever-larger deprecated stratum. Diagnostic: Does retiring this term preserve every existing annotation's resolvability through a redirect, or is someone proposing a deletion that will tidy the artifact by orphaning its dependents?

T4: Certified machinery versus uncertified verdicts (what the property does and does not guarantee). Collaborative maintenance is a structural property of how upkeep is distributed and made accountable — not a warrant that the decisions the machinery produces are correct. A community can run all five pathways faithfully and still approve scientifically wrong terms, adopt a bad ontological structure, or entrench a mistaken definition through impeccable process. The concept certifies that changes are proposed, reviewed, contested, deprecated, and attributed; it says nothing about whether the reviewers are competent or the acceptance criteria sound. This cuts both ways for an adopter: the checklist reliably predicts resilience and interpretability but is silent on quality, so a resource can score five-of-five and still be substantively poor, while a lightly-governed resource curated by an expert may hold better content. Diagnostic: Are you assessing whether upkeep is accountable and durable, or whether the terms it produces are actually right — and are you mistaking the first for the second?

T5: Interchangeable decision rule versus power that is not (where capture hides). The concept deliberately treats consensus, curator authority, and working-group vote as interchangeable fillings of the review-and-approval slot — swapping one for another does not change whether the resource is collaboratively maintained. Yet the dispute-resolution pathway exists precisely because who actually decides matters: without it, contested changes resolve by whoever holds commit access, the governance-capture signature. So the same framework that declares the decision rule immaterial also names the absence of dispute machinery as a specific pathology. The tension is real: the arrangement abstracts away from the review rule while insisting an escalation rule be present, because power that is nominally distributed can re-concentrate at the exact point where disagreement is adjudicated. Treating all decision rules as equivalent can blind an assessor to a captured escalation path. Diagnostic: Is the decision rule a genuine choice among equivalents, or is the review slot filled by consensus in name while contested calls silently route to whoever holds merge rights?

T6: Autonomy versus reduction (its own named apparatus or the informational instance of commons governance). "Collaborative maintenance" is a specific, canonically formulated arrangement — the OBO five-pathway template with its issue trackers, replaced_by pointers, and version-history provenance — and within the informational-commons family it travels intact as mechanism across ontologies, wikis, kernels, and standards bodies. But its portable core is Ostromian distributed stewardship of a shared resource under explicit internal rules, which recurs in fisheries, irrigation, and pasture as co-instances that share the abstract co-management structure without any of the artifact-specific cargo. What does not travel out is exactly what makes the concept diagnostically sharp: deprecation-with-redirects, the forkable pull-request pathway, provenance-from-version-history — machinery peculiar to non-rival, versioned, degradable-by-fragmentation artifacts, with no analogue in a depletable fishery. The tension is between a home-bound named apparatus that earns its own checklist and the recognition that its cross-domain reach belongs to the commons-governance parent. Diagnostic: Resolve toward the parent (distributed stewardship under internal rules) when carrying the lesson to a non-informational commons; toward collaborative maintenance's five-pathway apparatus when scoring an actual knowledge or standards artifact.

Structural–Framed Character¶

Collaborative maintenance sits at the framed-leaning band of the spectrum — a human governance arrangement, wholly constituted by a contributor community and its decision norms, that is nonetheless relatively neutral in the verdicts it renders. On evaluative_weight it is close to neutral in an unusually principled way: the concept certifies machinery, not verdicts — a resource can run all five pathways faithfully and still approve poor terms — so it is a structural property of how upkeep is distributed and made accountable, not a judgment that the decisions are wise. Every other criterion points framed. It is strongly human-practice-bound: a collaboratively maintained artifact exists only where an open community actually exercises documented pathways, and dissolves without that ongoing practice — there is no collaborative maintenance in observer-free nature, only where people are co-stewarding a shared artifact. Institutional_origin is pronounced: the concept is the OBO Foundry's five-pathway formulation (proposal, review, dispute resolution, deprecation, attribution), an explicit governance template of standards-and-vocabulary practice, not a fact of nature. On vocab_travels the artifact-specific machinery — deprecation-with-redirects, the pull-request/issue-tracker proposal channel, provenance-from-version-history — carries intact across the informational-commons family but does not survive extraction to a non-informational commons: a fishery cannot "redirect" a depleted stock. Import_vs_recognize is accordingly bimodal: across ontologies, wikis, kernels, and standards bodies the same arrangement is recognized as a co-instance, but carried to a pasture or fishery it travels only by analogy, while the genuine recurrence belongs to the commons-governance parent.

The portable structural skeleton is commons_governance — Ostromian distributed stewardship of a shared resource under explicit community-internal rules (bounded membership, monitored use, conflict-resolution, nested decision-making) — which collaborative maintenance instantiates for the special case of a non-rival, versioned, degradable-by-fragmentation informational artifact. That parent is what genuinely recurs in fisheries, irrigation districts, and communal pasture as co-instances sharing the abstract co-management structure, while collaborative maintenance's own cargo (the five-pathway apparatus, deprecation-with-redirects, version-history provenance) is library-and-information-science furniture that stays home. Its character: a practice-constituted, discipline-originated governance arrangement that certifies distributed accountability rather than quality, structural only in the commons-governance skeleton it instantiates and framed in the informational-artifact machinery that pins its five-pathway template to knowledge and standards resources.

Structural Core vs. Domain Accent¶

This section decides why collaborative maintenance is a domain-specific abstraction and not a prime, and it carries the case for its domain-specificity too — worth being exact about what could lift and what stays home.

What is skeletal (could lift toward a cross-domain prime). Strip the ontologies and version control away and a thin relational structure survives: a shared resource that many benefit from but few would upkeep is co-stewarded, over an indefinite horizon, by a bounded community operating under explicit internal rules for who may change it, how changes are approved, how disputes are settled, and how contributions are accounted for. The portable pieces are abstract — a common-pool resource vulnerable to a contribute/free-ride imbalance, a membership, a set of community-internal decision and conflict-resolution rules, and standing accountability. That skeleton is genuinely substrate-portable, which is exactly why it is the catalog prime commons_governance — Ostromian distributed stewardship of a shared resource under community-internal rules (bounded membership, monitored use, graduated sanctions, conflict resolution, nested decision-making) — that collaborative maintenance instantiates, and why the same shape genuinely recurs in fisheries, irrigation districts, and communal pasture as co-instances. But this co-stewardship structure is the core collaborative maintenance shares, not what makes it collaborative maintenance.

What is domain-bound. Everything that makes the concept collaborative maintenance in particular is machinery peculiar to a non-rival, versioned, degradable-by-fragmentation informational artifact, and none of it survives extraction. The deprecation-with-redirects rule — mark obsolete terms and point them at current preferred terms, never silently delete — exists only because millions of downstream annotations across an ecosystem must stay resolvable when a term retires; the change-proposal pathway presupposes a forkable, version-controlled artifact one opens an issue or pull request against; the provenance-recoverable-from-version-history rule presupposes a commit trail; and the whole OBO five-pathway template (proposal, review-and-approval against published acceptance criteria, dispute escalation, deprecation, attribution) is library-and-information-science furniture. The decisive test: carry the concept to a fishery and it renames every component and drops its machinery — you cannot "redirect" a depleted stock, there is no pull request against a pasture, a fishery is rival and depletable where an ontology is non-rival and degradable-by-neglect. Remove the versioned informational artifact and what is left is the bare co-stewardship problem, no longer collaborative maintenance but the parent it instantiates. The five-pathway apparatus that makes it "collaborative maintenance" specifically is exactly the domain baggage the prime bar asks it to shed.

Why this does not clear the prime bar. A prime is a relational structure whose vocabulary travels and whose cross-domain transfer is recognition of the same mechanism, not analogy. Collaborative maintenance's transfer is bimodal. Within the informational-commons family it travels intact as full mechanism — a curator trained on OBO's five pathways walks into a schema project, a wiki, a kernel, a standards body, or an open-data dictionary and applies the identical checklist, reading the same brittleness off the same missing slot, because these are co-instances, not metaphors. Beyond that substrate family it travels only by analogy: invoking "collaborative maintenance" for a fishery borrows the co-stewardship shape while dropping the deprecation, pull-request, and provenance machinery that gives the original its diagnostic force. Crucially, when the bare lesson — "co-manage a shared resource over an indefinite horizon under explicit community-internal rules" — is genuinely needed in a non-informational commons, it is already carried, in more general form, by the commons_governance parent, whose recurrence in fisheries, irrigation, and pasture is co-instantiation rather than resemblance. The cross-domain reach belongs to that parent, of which collaborative maintenance is the informational special case; "collaborative maintenance," as named, carries the artifact-specific five-pathway machinery that should stay home where versioned knowledge resources give it content.

Relationships to Other Abstractions¶

Current abstraction Collaborative Maintenance Domain-specific

Parents (3) — more general patterns this builds on

Collaborative Maintenance is a kind of Commons Governance Prime

Collaborative maintenance is commons governance specialized to versioned knowledge and standards artifacts.
Collaborative Maintenance is part of Maintenance Prime

Ongoing maintenance is a defining constituent of collaborative maintenance rather than merely a precondition.
Collaborative Maintenance is part of Provenance Prime

Recoverable contribution and change provenance is one of collaborative maintenance's defining governance pathways.

Not to Be Confused With¶

Commons governance / distributed stewardship (Ostrom) — the parent / umbrella. The substrate-neutral prime collaborative maintenance instantiates: co-management of a shared resource under community-internal rules (bounded membership, monitored use, graduated sanctions, conflict resolution, nested decision-making). This umbrella carries the cross-domain reach — fisheries, irrigation districts, communal pasture are genuine co-instances — while collaborative maintenance adds artifact-specific machinery (deprecation-with-redirects, pull-request pathways, version-history provenance) that has no analogue in a depletable fishery. Tell: is the resource a non-rival, versioned informational artifact under a five-pathway template (collaborative maintenance), or any shared resource co-stewarded under internal rules (commons governance)?
Crowdsourcing. Aggregating contributions from a distributed crowd to build or enrich an artifact — often a one-off push. It shares the open-contribution flavor but lacks the constitutive indefinite-lifetime commitment: a burst of crowd input that yields a frozen artifact nobody is committed to keep current is a different regime, not a weak instance. Tell: is the artifact treated as having an ongoing operational life requiring continuous co-stewardship (collaborative maintenance), or produced by a bounded contribution effort and then left as-is (crowdsourcing)?
Open-source development / the bazaar model. The broad practice of developing software in the open with public contributions. This is a broader phenomenon than collaborative maintenance, which is specifically the governance layer — the documented-and-exercised proposal, review, dispute, deprecation, and attribution pathways. An open-source project with an active tracker but no stated governance is open development without collaborative maintenance; only projects with the five pathways qualify. Tell: is code merely being written in public (open source), or is upkeep distributed through documented-and-exercised governance pathways over an indefinite horizon (collaborative maintenance)?
Bus factor / single point of failure. A risk measure — how many custodians must be lost before a project stalls. This is the hazard collaborative maintenance is designed to dissolve, not the arrangement itself: a high bus factor is an outcome of live governance pathways, not a synonym for them. A busy single custodian has a bus factor of one however active the repository looks. Tell: is the object a count of how fragile custody is to departures (bus factor), or the standing arrangement of pathways that spreads custody to raise that count (collaborative maintenance)?
Version control / provenance tooling (git, issue trackers). The technical substrate — commit history, pull requests, replaced_by pointers — on which the governance runs. Tooling is necessary but not sufficient: a repository can have full version control and an active tracker while its decision rule is entirely undocumented, which is the signature of a fast single custodian, not collaborative maintenance. The arrangement is the documented-and-exercised pathways, not the software that hosts them. Tell: is the object the version-control and tracking machinery a project uses (tooling), or the documented governance pathways exercised over it (collaborative maintenance)?
Single-custodian / benevolent-dictator stewardship. Upkeep concentrated in one authoritative maintainer (or a tightly-held core) who decides by personal judgment, however consultative. This is the contrast regime collaborative maintenance replaces: it can be fast and coherent but is brittle (bus-factor-of-one) and its decision rule typically lives in the custodian's head rather than documented pathways. Note some projects blend the two (a BDFL atop documented pathways). Tell: does custody survive any one person's departure through documented, exercised pathways (collaborative maintenance), or does it rest on a single custodian whose undocumented judgment is the governance (single-custodian stewardship)?

Neighborhood in Abstraction Space¶

Collaborative Maintenance sits in a crowded region of the domain-specific corpus (28^th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Trust Infrastructure for Shared Knowledge (6 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12