ZEP 11 — Updates to Zarr Project Governance

Authors:

  • Ryan Abernathey (@rabernat), Earthmover PBC
  • Alistair Miles (@alimanfoo), Ellison Institute of Technology
  • Josh Moore (@joshmoore), Open Microscopy Environment
  • Norman Rzepka (@normanrz), scalable minds

Status: Draft

Type: Process

Created: 05-Mar-2026

Discussion: (link to zarr-developers post for discussion)

Abstract

This ZEP proposes updates to the Zarr Project governance framework to better reflect the multi-project reality of the Zarr ecosystem today. It introduces a three-tier governance structure that distinguishes between (1) the overall Zarr Project governed by the Zarr Steering Council (ZSC), (2) the Zarr Specification governed by a new Spec Committee, and (3) Affiliated Software Projects governed independently by their own Core Developers Groups. It also introduces a transparent process for welcoming new Affiliated Software Projects, dissolves the Zarr Implementation Council (ZIC), and clarifies the relationship between governance roles and GitHub platform capabilities.

Motivation and Scope

In the ten years since its inception, Zarr has grown from a single-project, single-repo effort into a multi-project ecosystem comprising a core specification, multiple implementations across programming languages, extensions, conventions, and domain-specific tools. Zarr is in production use at organizations such as NASA, NOAA, ESA, EMBL-EBI, Allen Institutes, Biohub, RIKEN, NVIDIA, Google, and Microsoft.

The current governance framework, established in 2020 when the project moved under the umbrella of NumFocus, has not fully evolved to match this multi-project reality. The existing governance document lives at the zarr-developers GitHub organization level, and it is unclear whether it applies to all repos within the org or to zarr-affiliated projects under other orgs. This ambiguity has led to several concrete challenges:

  • Slow extension and convention development due to an ambiguous approval process.
  • Constrained agency for individual projects (e.g. zarr-python) within the zarr-developers GitHub org due to permissions limitations.
  • Ambiguity around committee membership processes, particularly around the Zarr Implementation Council (ZIC), which did not function as intended due to lack of clear time commitments, meeting expectations, and decision deadlines.
  • Fragmentation of Zarr-related projects across many different GitHub organizations and repositories.

The root cause is an overloading of the authority of the ZSC and incomplete disambiguation between the different entities that make up the Zarr ecosystem. This ZEP proposes governance updates that clarify roles and responsibilities via more precise definitions, streamline the development process, and encourage new contributors to get involved, while maintaining stability and continuity.

Scope

This ZEP applies to the governance of the Zarr Project as a whole, the Zarr Specification, and all Affiliated Software Projects. It does not prescribe governance for non-affiliated projects.

Usage and Impact

These governance changes will impact the following stakeholders:

  • ZSC members — Responsibilities are clarified and narrowed to project-level concerns; specification decisions are delegated to the Spec Committee.
  • ZIC members — The ZIC is dissolved. Current ZIC members are invited to join the new Spec Committee.
  • Core developers of affiliated projects — Each project gains formal autonomy through its own Core Developers Group, with a standard governance template as a starting point.
  • Contributors and potential contributors — A clearer governance structure lowers barriers to participation and makes decision-making processes more transparent.
  • Users and adopters — Organizational clarity builds confidence in Zarr as reliable, well-governed infrastructure.

Backward Compatibility

This ZEP supersedes the current governance document (zarr-governance/GOVERNANCE.md) and the ZIC-related provisions of ZEP0 (specifically the specification approval process requiring unanimous ZSC and majority ZIC approval). All other aspects of ZEP0 remain in effect unless explicitly modified by this ZEP.

Existing core developers, contributors, and community members retain their roles. No individual’s standing is diminished by these changes.

Detailed Description

The Zarr Ecosystem

The Zarr ecosystem consists of the following entities:

  1. The Zarr Project — The umbrella entity fiscally sponsored by NumFocus. NumFocus-sponsored projects are required to have a formal governance process and may receive financial donations via the NumFocus 501(c)(3).
  2. The Zarr Specification — A collection of documents defining the on-disk Zarr format.
  3. Affiliated Software Projects — Individual software projects (including the specification itself, as well as implementations, tools, and conventions projects) which are part of the Zarr Project. These projects are eligible to receive funds via NumFocus and are subject to the overarching Project governance framework.
  4. Non-Affiliated Software Projects — Other software projects which implement Zarr or interact with it in some way, but are not under the umbrella of the Zarr Project. Non-affiliated projects are not eligible for direct funding via NumFocus.

Tier 1: The Zarr Project (Governed by the ZSC)

The Zarr Project as a whole remains governed by the Zarr Steering Council (ZSC). Going forward, the ZSC’s responsibilities are:

  1. Interface between the Project and its fiscal sponsor (NumFocus).
  2. Manage the copyrights and trademarks associated with the Project.
  3. Manage the list of Affiliated Software Projects, including decisions about new affiliations and removal of affiliations.
  4. Manage responsibilities which do not belong to a specific Affiliated Software Project (e.g. the Zarr website, the zarr-developers GitHub organization, social media accounts, and similar Zarr-owned resources) in order to ensure smooth operations and effective collaboration.
  5. Serve as the final escalation point for disputes that cannot be resolved within an individual Affiliated Software Project or the Spec Committee.

The ZSC does not have authority over the day-to-day decisions of individual Affiliated Software Projects or the Spec Committee, except as explicitly stated above.

ZSC membership continues to be determined by nomination from existing members, discussion (no more than one month), and admission by consensus, as described in the existing governance document.

Tier 2: The Zarr Specification (Governed by the Spec Committee)

The Zarr Specification is the focal point that brings together all Zarr implementations. Because it addresses the on-disk format, decisions about the spec will persist for decades. Ensuring responsible and careful evolution of the spec, balancing the need for innovation with the need for stability, is the mandate of the Spec Committee.

Responsibilities

The Spec Committee is responsible for:

  1. Managing changes to the Zarr core Specification.
  2. Maintaining the list of Zarr Extensions.
  3. Overseeing the ZEP process for specification changes.

Initial Formation

To provide continuity with the current system, initial membership of the Spec Committee will be drawn from the current members of both the ZSC and the ZIC. These individuals are encouraged to resign from the Spec Committee if they do not plan to actively participate. It is expected that the Spec Committee will contain members of the most active Zarr implementations, including both Affiliated and Non-affiliated Software Projects.

Self-Governance

The Spec Committee’s first task will be to establish and document its own operational governance model, including:

  • Decision-making procedures (e.g. voting mechanisms, quorum requirements, and use of lazy consensus)
  • Membership criteria and review processes
  • Meeting cadence and participation expectations

This new governance model will supersede the unanimous ZSC / majority ZIC approval process currently defined in ZEP0 for all future core specification changes.

Dissolution of the ZIC

The Zarr Implementation Council (ZIC) is dissolved upon acceptance of this ZEP. Its functions are absorbed by the Spec Committee. The ZIC did not take shape in the way originally hoped: as implementations appeared and became inactive, the council’s membership adapted too slowly; members frequently did not have the time needed to follow ongoing GitHub conversations; and the ZSC never set expectations around meetings or time limits on decisions. Moving to a single Spec Committee, modeled after successful formats like Apache Parquet, addresses these issues.

Tier 3: Affiliated Software Projects (Governed by Core Developers Groups)

Each Affiliated Software Project is governed independently by its own Core Developers Group (CDG), following a standard governance template. The CDG is self-governing and its membership is not overseen by the ZSC.

A default governance template for Affiliated Software Projects is provided as a separate document. This template establishes a meritocratic, consensus-based process akin to the Apache model. Key elements include:

  • Each project has a Core Developers Group (CDG) which makes decisions. A group of one is acceptable for small projects.
  • Projects aim for consensus, falling back on majority vote of Core Developers when necessary.
  • Day-to-day decisions follow a lazy consensus process.
  • Any contributor is eligible to join the CDG. Existing Core Developers can nominate new members based on evidence of sustained, quality contribution. Nominations are accepted by majority vote.
  • Core Developers who become inactive can and should be removed via majority vote.
  • Larger groups should have a Chair who acts as a coordinator and facilitator.
  • All Affiliated Software Projects must adhere to the Zarr Project’s Code of Conduct, which is a requirement for NumFocus fiscal sponsorship.

Projects are free to evolve and change their governance as they see fit, provided it remains within the accepted norms of community open-source projects. If an Affiliated Software Project abandons open and transparent governance, the ZSC reserves the right to remove its affiliation.

Criteria for Affiliation

To be considered for affiliation with the Zarr Project, a project must:

  1. Be open source.
  2. Be directly related to Zarr (e.g. an implementation, tool, extension, or convention).
  3. Demonstrate a critical mass of sustained development activity.

The ZSC will make decisions about affiliation based on these criteria and the overall strategic direction of the Project. We welcome and encourage all Zarr-related projects to become affiliated.

Non-affiliated projects may of course continue to operate however they wish, outside the boundaries of this framework, with whatever governance (or lack thereof) they choose.

The Role of GitHub

The use of GitHub by the Zarr Project is an implementation detail. GitHub roles, groups, and repos do not have any formal status within the Zarr governance framework.

In practice, the Zarr Project is heavily reliant on GitHub for day-to-day operations. The following principles guide how governance maps to GitHub:

  • Principle of least privilege: Different actors should have only the minimal privileges required to perform their function, minimizing the blast radius of any potential security threat.
  • Centralized organization: All Affiliated Software Projects live within the zarr-developers GitHub organization, providing a central entry point and allowing projects to share resources.
  • Project-level autonomy: Each Affiliated Software Project manages its own repos and GitHub team membership. Ownership of the GitHub org as a whole (including creation of new repos and teams) is managed by the ZSC.
  • Automated membership management: To avoid the ZSC becoming a bottleneck on project autonomy, a GitHub bot or similar automation will be used to allow each Affiliated Software Project to manage its own team membership independently.
  • Apache Software Foundation: Uses a Project Management Committee (PMC) model with merit-based membership and lazy consensus. The Zarr affiliated project governance template is inspired by this model.
  • Apache Parquet: A widely adopted file format governed by a single PMC, providing a precedent for managing a specification through a unified committee rather than a two-body (council + implementation council) approach.
  • NumFocus: As Zarr’s fiscal sponsor, NumFocus requires formal governance. The changes in this ZEP are consistent with NumFocus requirements.

Implementation

Implementation of this ZEP requires the following steps:

  1. Update zarr-governance/GOVERNANCE.md to reflect the three-tier structure, clarify ZSC responsibilities, remove ZIC provisions, and reference the Spec Committee and affiliated project governance.
  2. Add zarr-governance/AFFILIATED_PROJECT_GOVERNANCE.md containing the default governance template for Affiliated Software Projects.
  3. Form the Spec Committee by inviting current ZSC and ZIC members. The Spec Committee then establishes its own governance model as its first order of business.
  4. Update ZEP0 to reflect that specification changes are now governed by the Spec Committee rather than the unanimous ZSC / majority ZIC process.
  5. Set up GitHub automation (bot or equivalent) to enable affiliated projects to manage their own team membership within the zarr-developers organization.
  6. Establish initial list of Affiliated Software Projects and ensure each has a governance document (using the template as a starting point).

Steps 1 and 2 are included as part of this ZEP’s accompanying pull request. Steps 3–6 are follow-up actions to be completed after acceptance.

Alternatives

Maintain the status quo

The current governance could be kept as-is, with informal workarounds for the challenges described above. This was rejected because the ambiguity is actively impeding development and contributor engagement.

Merge Spec Committee into ZSC

Rather than creating a separate Spec Committee, specification governance could remain with the ZSC. This was rejected because the spec requires a different kind of governance — focused on long-term stability and cross-implementation consensus — than the administrative and strategic concerns of the ZSC. Separating these roles also avoids overloading the ZSC.

Prescribe detailed Spec Committee governance in this ZEP

This ZEP could fully specify the Spec Committee’s governance model. This was rejected in favor of allowing the committee to establish its own model as its first task, which gives the committee ownership over its own processes and allows it to adapt based on experience.

Require uniform governance across all affiliated projects

All affiliated projects could be required to follow the same governance model. This was rejected because projects vary significantly in size, maturity, and community structure. The template serves as a recommended starting point, but projects are free to adapt.

Discussion

This ZEP is based on the blog post “Evolving Zarr’s Governance” and accompanying draft governance documents, which were discussed and refined during ZSC meetings in January and March 2026.

References and Footnotes

CC0
To the extent possible under law, the authors have waived all copyright and related or neighboring rights to ZEP 11.

This site uses Just the Docs, a documentation theme for Jekyll.