Abstract

This document defines the community and governance principles that guide how the Open Science Archive (OSA) project is run, who makes decisions, and how contributions are welcomed. For technical design principles, see OEP-0003.

Motivation

OSA aims to be a neutral, open standard, and that requires explicit principles about how its contributors work together. Technical excellence is not enough, the protocol will not be adopted widely unless the governance process is open and participatory.

Specification

Principles

Open governance

No single entity controls the protocol. Decisions are made transparently through the OEP process. Anyone can propose changes, and rationale is preserved for future maintainers.

Specification over implementation

The protocol specification is separate from any reference implementation. Compliant software can be written in any language by any team. The spec is the source of truth, not the code. This means that pre-existing data platforms can adopt the OSA progressively, without changing their tech stack.

Community-owned semantics

Vocabularies, validators, and schemas are maintained by domain experts, not by OSA protocol maintainers. The OSA project only provides mechanisms for creating and disseminating these domain-specific components.

Low barrier to contribution

Rough ideas are welcome. The OEP process includes an "ideation" state for early-stage proposals that aren't fully formed. You don't need a complete specification to start a conversation.

Diverse perspectives

OSA is not just a software project. Building infrastructure for scientific data requires input from many disciplines: researchers who understand data workflows, ML practitioners who consume datasets, software engineers who build systems, designers who shape user experiences, librarians who understand metadata, and domain experts who define quality standards. We actively seek contributors from all these backgrounds. Technical decisions have human consequences, and the best protocols emerge from diverse perspectives.

Pluralism over consensus

Different communities may have different needs. The protocol should accommodate divergent approaches rather than forcing premature standardisation. Two communities can define incompatible vocabularies, that's fine. Alignment happens organically when it's useful, not by mandate.

Communication Channels

Zulip

For informal discussion, questions, and early ideas. This is the best place to start if you're new to the project and want to get involved.

Join the Zulip chat

OEP Pull Requests

For formal proposals to change the protocol. See OEP-0001 for the process. Start here if you have a well-formed idea ready for community review.

opensciencearchive/oeps

Rationale

These principles are informed by the success and failures of other open standards:

• IETF/W3C: Strong on open process, but high barrier to contribution
• PDB: Successful domain-specific archive, but tightly coupled to one community
• Schema.org: Good model for community-owned vocabularies
• ActivityPub/Fediverse: Demonstrates federation without central control

OSA aims to combine open governance with low barriers and explicit support for community divergence.

Backwards Compatibility

N/A - this is an informational document.

Security & Privacy

This document defines governance principles and has no direct security or privacy implications.

Open Issues

• How should disputes be resolved when communities disagree?
• Should there be a formal steering committee, or is the OEP process sufficient?