Amendments to Hyperledger Fabric Technical Charter

[cendhu]

Type of change

• Updates to Hyperledger Fabric Technical Charter

Description

The proposed amendments aim to restructure the governance to support an ecosystem of multiple "Sub-Projects" under the Hyperledger Fabric umbrella.

Additional details

The "Fabric Ecosystem Coexistence Model" RFC, which provides the detailed rationale for these charter changes, can be found at: hyperledger/fabric-rfcs#64. The deliberation and voting process for these proposed charter amendments will be conducted in conjunction with the review and approval of this RFC.

[C0rWin]

While charter amendments require supermajority, the definition is incomplete. With enough Sub-Projects, even this protection could be overcome.

[C0rWin]

@cendhu, thanks for the update, charter. I think we need to have a little more rigorous formulations and definitions.

The proposed governance structure has a significant vulnerability that could enable a small coordinated group to gain control of the ecosystem through Sub-Project proliferation.

The Attack Vector

Step 1: Initial Foothold

• A coordinated group gains influence in 1-2 existing Sub-Projects or gets their members appointed as maintainers
• They now have representation in the TSC and voting power

Step 2: Sub-Project Proliferation

• They create multiple new "Sub-Projects" with minimal functionality (e.g., simple tools, utilities, documentation projects)
• Each new Sub-Project only needs simple majority approval from existing Sub-Project maintainer groups
• As they create more Sub-Projects, they gain more votes to approve subsequent ones

Step 3: Equal Voting Power Exploitation

• Critical flaw: Each Sub-Project gets exactly one vote regardless of:
  • Size of codebase
  • Number of contributors
  • Community activity
  • Strategic importance
• A trivial utility project has the same voting power as the core Fabric blockchain

Step 4: Ecosystem Control

• Once they control the majority of Sub-Project votes, they can:
  • Block any ecosystem-wide decisions they oppose
  • Approve new policies that benefit their interests
  • Control the approval/rejection of future Sub-Projects
  • Even amend the charter itself (requires supermajority, but achievable with enough Sub-Projects)

Mitigation Strategies the Charter Should Include

1. Weighted Voting: Base voting power on metrics like:

   • Number of active contributors
   • Commit activity
   • Community size
   • Strategic importance

2. Higher Approval Thresholds: Require supermajority or TSC approval for new Sub-Projects

3. Activity Requirements: Define clear metrics for "active" status and regular reviews

4. Minimum Viability Standards: Require substantial codebases, community engagement, or strategic value

5. Sunset Mechanisms: Automatic removal of inactive Sub-Projects from voting

[cendhu]

@cendhu, thanks for the update, charter. I think we need to have a little more rigorous formulations and definitions.

The proposed governance structure has a significant vulnerability that could enable a small coordinated group to gain control of the ecosystem through Sub-Project proliferation.

The Attack Vector

Step 1: Initial Foothold

• A coordinated group gains influence in 1-2 existing Sub-Projects or gets their members appointed as maintainers
• They now have representation in the TSC and voting power

For now, each sub-project has only one vote, irrespective of its size. Once the number of sub-projects increases, we can evolve to an election model to form a TSC, similar to how it is done in LFDT.

Step 2: Sub-Project Proliferation

• They create multiple new "Sub-Projects" with minimal functionality (e.g., simple tools, utilities, documentation projects)
• Each new Sub-Project only needs simple majority approval from existing Sub-Project maintainer groups
• As they create more Sub-Projects, they gain more votes to approve subsequent ones

A sub-project can have a family of repositories. Creating documentation, tools, or utilities for Fabric-Classic or Fabric-X would not constitute a sub-project. This will be decided on a case-by-case basis with votes.

Are you suggesting a supermajority vote for approving a new sub-project?

Step 3: Equal Voting Power Exploitation

• Critical flaw: Each Sub-Project gets exactly one vote regardless of:

  • Size of codebase
  • Number of contributors
  • Community activity
  • Strategic importance

• A trivial utility project has the same voting power as the core Fabric blockchain

The method followed in LFDT is good. They consider all contributors as voters, and they choose the TSC to manage the LFDT ecosystem. We can do that when we have three or more sub-projects. For now, it is too early and would be too much overhead for just two sub-projects.

Step 4: Ecosystem Control

• Once they control the majority of Sub-Project votes, they can:

  • Block any ecosystem-wide decisions they oppose
  • Approve new policies that benefit their interests
  • Control the approval/rejection of future Sub-Projects
  • Even amend the charter itself (requires supermajority, but achievable with enough Sub-Projects)

Mitigation Strategies the Charter Should Include

1. Weighted Voting: Base voting power on metrics like:

   • Number of active contributors
   • Commit activity
   • Community size
   • Strategic importance

2. Higher Approval Thresholds: Require supermajority or TSC approval for new Sub-Projects

3. Activity Requirements: Define clear metrics for "active" status and regular reviews

4. Minimum Viability Standards: Require substantial codebases, community engagement, or strategic value

5. Sunset Mechanisms: Automatic removal of inactive Sub-Projects from voting

We will have to change this charter once the number of sub-projects increases so that we can conduct elections to choose the TSC.

[C0rWin]

@cendhu thanks, I think we are converging, though, would you agree to define the archiving procedure for the inactive project? Currently, there's no mechanism to remove inactive or abandoned Sub-Projects from voting eligibility, allowing dead projects to maintain voting power indefinitely.

[cendhu]

@cendhu thanks, I think we are converging, though, would you agree to define the archiving procedure for the inactive project? Currently, there's no mechanism to remove inactive or abandoned Sub-Projects from voting eligibility, allowing dead projects to maintain voting power indefinitely.

@C0rWin @denyeart @manish-sethi @tock-ibm @yacovm @andrew-coleman @bestbeforetoday @pfi79 @satota2 @ale-linux

A charter should not be overly specific or restrictive. I have read the LFDT charter (https://lf-decentralized-trust.github.io/governance/governing-documents/charter.html) and tried to follow a similar pattern. Hence, defining criteria for inactive projects, inactive maintainers, the number of contributors in sub-projects, the number of maintainers, the number of lines of code, and similar aspects would not be mentioned in the charter. We will have to decide these on a case-by-case basis.

[C0rWin]

@cendhu thanks, I think we are converging, though, would you agree to define the archiving procedure for the inactive project? Currently, there's no mechanism to remove inactive or abandoned Sub-Projects from voting eligibility, allowing dead projects to maintain voting power indefinitely.

@C0rWin @denyeart @manish-sethi @tock-ibm @yacovm @andrew-coleman @bestbeforetoday @pfi79 @satota2 @ale-linux

A charter should not be overly specific or restrictive. I have read the LFDT charter (https://lf-decentralized-trust.github.io/governance/governing-documents/charter.html) and tried to follow a similar pattern. Hence, defining criteria for inactive projects, inactive maintainers, the number of contributors in sub-projects, the number of maintainers, the number of lines of code, and similar aspects would not be mentioned in the charter. We will have to decide these on a case-by-case basis.

I agree, yet, but it least we can make it well-defined without room for interpretation.

[denyeart]

Some of the comments here are getting very detailed. My suggestion is to keep the Charter flexible and high-level. Addition of sub-projects and repositories is a rare event and each one is unique. The TSC should have the freedom to make decisions as they see fit.

[cendhu]

Some of the comments here are getting very detailed. My suggestion is to keep the Charter flexible and high-level. Addition of sub-projects and repositories is a rare event and each one is unique. The TSC should have the freedom to make decisions as they see fit.

I completely agree with this.

[C0rWin]

Some of the comments here are getting very detailed. My suggestion is to keep the Charter flexible and high-level. Addition of sub-projects and repositories is a rare event and each one is unique. The TSC should have the freedom to make decisions as they see fit.

Ok, I can see the point where you might introduce some loosely defined claims open to interpretation, while I do not think this should remain too open or vague. I believe I will be fine if we can agree at very least on the following:

3. Decision-Making on Significant Ecosystem-Wide Matters: Decisions on significant ecosystem-wide matters shall require approval from a simple majority of the distinct Maintainer groups of currently recognized and active Sub-Projects. The process is as follows:

and to make a super majority-based decision.

[jt-nti]

Just an observation but if the new charter is agreed, it should probably move to a new location, rather than live in one of the specific implementation projects. Is https://github.com/hyperledger/governance/tree/main/project-charters the right place? Alternatively, maybe the Fabric expansion would make it worth creating a new "LFDT-Fabric" organisation, with an associated "governance" repo?

[denyeart]

I agree with the updates in general and will therefore approve. Charter updates will need to be reviewed by LFDT, and when they do that it will be interesting to see if they can point to other projects with similar sub-project structures for comparison.

[denyeart]

Some of the comments here are getting very detailed. My suggestion is to keep the Charter flexible and high-level. Addition of sub-projects and repositories is a rare event and each one is unique. The TSC should have the freedom to make decisions as they see fit.

Ok, I can see the point where you might introduce some loosely defined claims open to interpretation, while I do not think this should remain too open or vague. I believe I will be fine if we can agree at very least on the following:

3. Decision-Making on Significant Ecosystem-Wide Matters: Decisions on significant ecosystem-wide matters shall require approval from a simple majority of the distinct Maintainer groups of currently recognized and active Sub-Projects. The process is as follows:

and to make a super majority-based decision.

For the parent Hyperledger/LFDT organization, the addition of new projects has always required a simple majority of TOC. It seems following their precedent of simple majority would make sense.

[denyeart]

Just an observation but if the new charter is agreed, it should probably move to a new location, rather than live in one of the specific implementation projects. Is https://github.com/hyperledger/governance/tree/main/project-charters the right place? Alternatively, maybe the Fabric expansion would make it worth creating a new "LFDT-Fabric" organisation, with an associated "governance" repo?

Yeah, there will be many considerations such as this, let's see if LFDT can provide any guidance.

[bestbeforetoday]

I fundamentally agree with the intent of this change. Some minor points I think must be corrected. Other areas, I think the text is becoming convoluted and unclear.

I wonder if, for now, we can keep the changes just to the essentials required to acknowledge the concept of sub-projects (or alternative implementations / specializations of the fundamental Fabric model) within the Fabric ecosystem overseen by the TSC. Avoid too much detail and excessive prose so that we can implement the change more quickly. We already have a framework for adding and refining this detail in the future with updated charters. What do you think?

[denyeart]

I agree with Mark @bestbeforetoday that the focus on sub-projects is a bit forced in some places and makes the Charter somewhat more difficult to understand. I'll give a few more examples in this review comment.

I had approved because I assumed that the LFDT review would improve some of this wordsmithing. If we can improve it before that step, all the better.

[bestbeforetoday]

Although I wish some of the content was clearer and more concise, I think I generally agree with this proposed charter.

A few key points that I really would like to see changed are:

1. Remove Definitions section.
2. In section 5, point 3, replace simple majority with at least fifty percent.
3. Remove section 5, point 4. (The Amendments section describes charter changes)
4. Replace simple majority with majority. (Particularly so that activities such as maintainer nomination within sub-projects or repositories remain majority as in the current charter)
5. Word section 11 (Amendments) similar to:

   This charter may be amended by a TSC vote as described in section 5, but requiring a two-thirds majority of collective sub-project votes, and is subject to approval by LF Projects.

[bestbeforetoday]

Thank you for the updates.

[cendhu]

@denyeart @bestbeforetoday Thank you for the detailed reviews. Based on your comments, I realised that TSC formation and the voting process were confusing part. Hence, I have rewritten both of them to make it clear. Further, I have address a other comments too.

[denyeart]

Thank you for making the updates.

[C0rWin]

While I understand the precedent of simple majority in parent organizations, the unique Sub-Project structure here creates different risk dynamics that warrant consideration. However, I recognize the value of proceeding with appropriate oversight.

I will reserve my final vote pending:

• LFDT review and official position on both this charter amendment and the associated RFC64 "Fabric Ecosystem Coexistence Model"
• LFDT's assessment of the governance model's alignment with broader Hyperledger ecosystem practices

The proposed structure still allows for potential ecosystem manipulation through Sub-Project proliferation, where:

• Each Sub-Project, regardless of scope, contributors, or strategic importance, receives equal voting power
• New Sub-Projects require only simple majority approval, creating a recursive approval mechanism
• No clear safeguards exist against coordinated groups creating multiple minimal projects to gain voting control