Fabric Ecosystem Coexistence Model #64
Conversation
Signed-off-by: senthil <[email protected]>
|
@yacovm @denyeart @manish-sethi @tock-ibm @ale-linux @C0rWin @andrew-coleman @bestbeforetoday @satota2 @pfi79 This proposal presents fundamental changes to the Hyperledger Fabric Charter, introducing a new governance model and a coexistence model for multiple Fabric implementations. Please review and provide your feedback. If you are satisfied with this proposal, kindly approve it. |
|
Thank you for submitting this proposal in response to the concerns raised on PR #63. While I appreciate the effort to address the governance questions through a coexistence framework, this proposal still lacks the comprehensive governance model required for such a significant structural change to the Hyperledger Fabric ecosystem. Critical Governance Elements MissingA viable "Ecosystem Coexistence Model" would require detailed specifications for:
Missing Compatibility SpecificationFor a coexistence model to work, there must be a clear specification defining what qualifies an implementation as "Fabric":
Without these clearly defined specifications, it becomes impossible to determine what qualifies as a "Fabric implementation" versus a completely new project that simply shares some conceptual similarities. Ecosystem Fragmentation ConcernsThis proposal would create significant fragmentation that poses real risks to the Fabric ecosystem:
This new PR represents a tactical pivot rather than addressing the fundamental governance concern. Instead of acknowledging that Fabric-X should follow proper incubation as a new project, it attempts to redefine the Fabric project itself to accommodate fundamentally different implementations. The approach of creating a "coexistence model" after concerns were raised appears to be an attempt to retroactively justify the inappropriate use of the RFC process rather than properly engaging with the established project lifecycle governance. |
|
Thanks, @C0rWin, for providing a quick feedback. Some of the concerns are already addressed in the RFC. Anyway, i will address these concerns and update the RFC with more clarity. |
|
@cendhu Thank you for this proposal. About Release Cycles and LTS Support
In this section, it says that each recognized implementation will have its own release cycle.
If each implementation handles LTS very differently, it may confuse users. Therefore, I believe it would be better to have a common LTS strategy across multiple implementations — at least for core repositories — to provide clarity and consistency for users. About How It Looks from Outside (LFDT Website, Landscape, etc.)
In earlier versions, this was listed under Unresolved Questions. I believe that — from a user perspective — this point is very important and deserves further discussion. Some questions to consider:
This is just one example, clear guidelines for how these implementations are presented within LFDT are also essential to avoid user confusion. |
|
Thank you @satota2 for your constructive feedback. Does the following proposed approach address your concern? If so, I can add it to the RFC. Regarding Release Cycles and Long-Term Support (LTS) StrategyCommunity Question/Concern:
Proposed Approach: To address the concern for consistency and user clarity, this RFC proposes that:
Regarding External Presentation (LFDT Website, Landscape, etc.)Community Question/Concern:
Proposed Approach:
The principles for these communication and branding strategies are established by this RFC, with the Expanded Fabric TSC tasked with their detailed definition and consistent enforcement. |
I honestly cannot understand why create an independent, self-governed structure that replicates the already existing and well-established process of new project acceptance under Hyperledger - https://toc.hyperledger.org/guidelines/project-incubation-entry-considerations.html. It's here to have structured control and to warrant proper segregation of responsibilities between graduated Hyperledger projects and those that require proof of their technical maturity and community engagement. |
|
I’ve been fairly quiet in this discussion because I wanted to hear the discussion at the May 21st contributor meeting and verify some facts, which I have now done. Since this comment applies to both RFC63 and RFC64 I am posting to both RFCs. I have confirmed with LFDT staff that the introduction of project technical charters last year was in part motivated to enable projects to grow and evolve autonomously including the management and addition of sub-projects. A key aspect of that was the establishment of project-specific TSCs that can govern a project beyond the scope of a single repository and even beyond a single family of repositories. The authority is granted to the project-specific TSC to determine the criteria for bringing in new sub-projects. Since RFC63 is the first major proposed addition since adopting the new charter and establishing the Fabric TSC, there is understandably going to be some friction as that criteria is defined. RFC64 goes a long way towards defining the criteria for new sub-projects. I don’t see this as changing the rules on the fly, I see it as evolving the Fabric ecosystem and TSC given new realities in the manner intended and as defined in the Fabric Technical Charter. Concerning starting Fabric-X as a lab, my opinion is that Fabric-X is well beyond the state of most labs. Labs are an area to explore new ideas and to get code aligned with open source standards. From what I have seen of the Fabric-X repositories this is already the case (I appreciate that not all Fabric TSC members have seen the repositories). The code has been evolving for at least 5 years and in that time it has withstood scrutiny in pilot projects at large institutions and has likely been performance tested more than any project in the LFDT ecosystem, certainly it has been performance tested more than Fabric itself. The next steps in my opinion are as follows:
Note that Fabric Technical Charter updates require two-thirds majority of Fabric TSC, and Fabric TSC votes such as new sub-projects require simple majority. This is a higher threshold than RFCs that simply propose code updates. |
There was a problem hiding this comment.
Pull Request Overview
This PR introduces the “Fabric Ecosystem Coexistence Model” RFC, outlining a framework for recognizing and governing multiple specialized Hyperledger Fabric implementations under one ecosystem.
- Adds a new RFC document defining core Fabric principles, governance processes, and the lifecycle for coexisting implementations.
- Describes the motivation, reference-level details, governance model, and examples from other ecosystems.
- Includes sections on testing indicators, dependencies, and unresolved questions to guide charter amendments.
Comments suppressed due to low confidence (2)
text/0000-fabric-coexistence-model.md:4
- Inline comments in the YAML frontmatter may break parsing. Consider removing or relocating the
# Assuming this is a new RFC in a sequencecomment outside the frontmatter.
nav_order: 4 # Assuming this is a new RFC in a sequence
text/0000-fabric-coexistence-model.md:40
- [nitpick] The naming for implementations varies (e.g., "Fabric (Classic)", "Fabric-Alpha"). Standardize to a single pattern (e.g., "Fabric Classic", "Fabric X") to improve consistency.
* **Fabric (Classic)**: The established, general-purpose Fabric implementation,
Signed-off-by: senthil <[email protected]>
|
Thank you, @denyeart The PR for changing the Hyperledger Fabric Technical Charter can be found at hyperledger/fabric#5223 and is also linked with this RFC. |
|
Thanks for the update @denyeart, that's really useful.
I'm certainly not opposed to Fabric becoming an umbrella for related blockchain implementations however there may still be value in starting "Fabric-X" as a lab, even a short-lived one. In this case – the first additional implementation – it would give time to solidify the new governance model and build wider community support, as well as the more mundane administrivia* of potential new GitHub orgs, landing pages, and so on, while giving all Fabric TSC members access to the repositories to guide discussions. I also think it would be reasonable precedent to set for future candidate projects to follow:– there are likely to be similar concerns for any additional projects, and it feels like a natural progression to me. As for the maturity of Fabric-X compared to existing labs, there is at least one lab project that has withstood production deployment. *one such administrivia is naming. Is "Fabric-X" a placeholder for discussion, or is it really the final name? "Fabric Classic" and "Fabric-X" both seem... well... naming is hard! :) |
There was a problem hiding this comment.
I agree with including alternative or specialised implementations of the Fabric (permissioned, execute-order-validate) blockchain approach within a Fabric ecosystem, governed by a Fabric ecosystem TSC. Exact charter wording to be refined and agreed subsequently.
|
I strongly support innovative approaches that advance Fabric's capabilities and address emerging market needs. However, I have concerns about the process and timing of these governance changes. The emergence of RFC #64 immediately after governance concerns were raised about RFC #63 creates an impression that the framework is being retrofitted to accommodate a specific pending proposal rather than addressing genuine community-identified needs. This reactive approach raises questions about whether these fundamental changes reflect collective priorities or are primarily driven by particular stakeholder interests and timelines. The Fabric community benefits most when governance evolution emerges from demonstrated community needs rather than accommodation of predetermined technical directions. |
|
@cendhu Thank you very much for your continued consideration.
I wasn’t able to explain it well during the Contributor Meeting, but @jt-nti ’s comment closely reflects my intention, so I’d like to build on it here. I also believe that starting Fabric-X as a short-term Labs project could be a valid and pragmatic approach.
In addition, like @jt-nti, I share some concerns about the naming.
Personally, I’m very excited about the Fabric-X initiative itself. |
Concerning the suggestion to incubate Fabric-X in Hyperledger Labs, I acknowledge the valuable role Labs plays and the benefits you've highlighted, such as signaling a project's developmental stage and fostering focused community evaluation. However, for Fabric-X, we believe development directly within the Hyperledger Fabric ecosystem is the more appropriate and effective path for several key reasons:
I understand the concerns regarding the name 'Fabric-X' and its potential to create misleading impressions if the project were highly specialized. Naming is indeed crucial for setting the right expectations. We are committed to ensuring clarity. Through comprehensive documentation, dedicated webinars, technical workshops, and ongoing community calls, we will clearly articulate Fabric-X's capabilities, its relationship to Fabric, its intended use cases, and any differences in compatibility or scope. While we aim for Fabric-X to be a natural and high-performance extension suitable for a broad range of demanding applications, we will ensure our messaging prevents user confusion. We believe these communication efforts will effectively manage perceptions and therefore do not see the name itself as a showstopper at this stage. |
@cendhu In particular, regarding naming — while I appreciate the plan to provide clarity through documentation, webinars, and community calls, I’m also concerned that this may place a burden on users to actively seek out that information. Would it be possible to leave open the possibility of a name change depending on how the community understands and receives the project?
I think that with a name like this, the project could be more clearly positioned and differentiated — reducing the risk of confusion while highlighting its intended focus. What are your thoughts? |
@satota2, thanks for your thoughts on naming. I see 'X' in Fabric-X as clearly signifying acceleration and eXtreme performance. Ultimately, irrespective of the name, proactive and clear marketing will be crucial to differentiate this significant advancement from 'Fabric Classic' and educate all users. We are committed to this effort to ensure clarity. |
|
@cendhu I must respectfully disargree with provided points and here is why:
You state that Fabric-X is "conceptualized as a significant evolution and an integral component within the existing Hyperledger Fabric ecosystem." However, this characterization is contradicted by the facts: Private Development: Fabric-X has been developed privately and in a closed manner for years, without any gradual community involvement or transparent evolution. This is fundamentally different from how Fabric features have historically evolved through open discussion and incremental changes. Distinct Product Focus: The RFC clearly states that Fabric-X is specifically targeted at CBDCs and high-throughput asset management use cases, with significant architectural changes that make it a distinct product rather than an evolution. Shared Heritage ≠ Same Project: Having the same group of developers working on two products that share some conceptual principles does not justify fusing them together. By this logic, any blockchain project developed by former Fabric contributors could claim to be part of Fabric. The fact remains that Fabric-X is architecturally, operationally, and programmatically distinct from Fabric - making it a new project, not an evolution.
The claim of "significant support from Fabric maintainers (7 out of 10 approvals)" requires critical examination: Conflict of Interest: The 7 maintainers supporting this proposal are co-authors of the RFC itself and work at the same organization. This represents a clear conflict of interest that undermines the claim of broad community support. Lack of Technical Details: The "maturity" of Fabric-X cannot be properly assessed from this RFC, which lacks sufficient technical details. Claims of 100k+ TPS and production readiness cannot be verified without access to the code, architecture details, and independent benchmarks. Closed Development: A project developed in private without community visibility or input cannot claim the same maturity as one that has evolved through open collaboration.
The comparison to fabric-gateway and other enhancements is fundamentally flawed: Direct Integration: Previous sub-projects like fabric-gateway were directly integrated with Fabric's existing architecture, APIs, and operational model. They enhanced Fabric rather than replacing it. Backward Compatibility: All previous major additions maintained some level of compatibility or clear migration paths. Fabric-X explicitly has zero interoperability with existing Fabric deployments. Same Programming Model: Previous additions worked with existing chaincode and client applications. Fabric-X introduces an entirely new programming paradigm ("Flows" vs chaincode). This is not an "apples to apples" comparison - you're attempting to use precedent from incremental improvements to justify introducing a completely incompatible system.
While community feedback is valuable, hosting Fabric-X directly under Fabric sends problematic signals: Eclipse Effect: Given the evident shift in focus and resources toward Fabric-X, there's a real risk that it will eclipse the original Fabric, creating confusion about which platform represents the future of the project. Mixed Messages: Presenting two incompatible systems under the same project name will confuse users, fragment the community, and dilute the meaning of "Hyperledger Fabric" as a graduated, production-ready platform. Resource Competition: Having two distinct platforms compete for maintainer attention, documentation resources, and community support within the same project structure is a recipe for conflict and inefficiency.
Your commitment to "comprehensive documentation, dedicated webinars, technical workshops, and ongoing community calls" actually reinforces the fundamental concern rather than addressing it: The Communication Burden ParadoxThe very fact that you acknowledge needing such extensive communication efforts to prevent user confusion is a clear admission of the fundamental incompatibility and difference between Fabric and Fabric-X. Consider:
The scale of communication effort you're proposing is typically reserved for launching entirely new products, not evolving existing ones. This inadvertently proves that Fabric-X is indeed a separate project that requires its own identity and positioning. The Resource Allocation QuestionThis extensive communication plan raises a critical question that remains unanswered: What happens to Hyperledger Fabric itself? Fabric has seen minimal feature contributions over the past two years. The maintainer team's focus has clearly shifted to Fabric-X development. Now you're proposing to dedicate significant resources to Fabric-X documentation, webinars, and workshops Where does this leave the existing Fabric community and users? Will there be:
Or is this communication effort essentially a soft transition plan to gradually shift the community from Fabric to Fabric-X? |
|
@C0rWin Artem, I understand and acknowledge your strong opposition to RFCs #63 and #64, and PR #5223 regarding the fabric charter changes. I also recognize that differing opinions are normal in the open source community. Given that our discussions on this are becoming repetitive, I suggest we agree to disagree on our opinions. |
Absolutely. Nothing says 'open source collaboration' quite like noting community concerns as 'repetitive discussions' and suggesting we move past them. But yes, let's agree to disagree—it's much tidier than actually resolving the issues. |
...and in the parallel RFC...
I understand that you're keen to develop the new version of Fabric as a fully fledged project however I'm not sure why there seems to be resistance to just getting the code out there as early as possible for the community to review as part of these discussions. A short-term lab would be a simple way to do that quickly, and would hopefully help the community reach a consensus on quickly promoting it to a peer project to the existing Fabric implementation. |
@jt-nti The topic of using a lab was addressed during the community call by certain maintainers who approved this RFC. I have also detailed in previous comments. To ensure the discussion remains productive, let's avoid revisiting points that have already been covered. |
|
While such coexistence model is a good to have for Fabric's future, this seems like a cover for the #63 RFC to get through. It affects the confidence in the project, when the degree of sensitivity to accommodate non-maintainers comments are none. |
I appreciate your support for the co-existence model. However, I see a potential contradiction in your comment that I hope you can clarify. You've expressed support for the idea of co-existence, but you also seem to oppose the Fabric-X proposal. Given that Fabric-X is being presented as the key component for that co-existence, could you explain how you envision a co-existence model working without a proposal like this one? To add more context, it's important to acknowledge there are two views here, even among the maintainers. A significant majority supports this RFC and the co-existence model with Fabric-X. While a smaller group has voiced opposition, the process must move forward. This isn't a case where someone has found a serious flaw in the document that we have refused to address. Ultimately, in open source, when consensus isn't possible, the formal governance process, such as a vote, decides the outcome. This ensures the project can evolve and doesn't get stalled by disagreement. |
Coexistence would make sense for minor differences, use case tuned versions, some possible facelifts to address throughput, security, resilience etc. But NOT for a redesigned architecture which essentially changes the crux of the original solution.
While this proposal may have majority support from the dedicated maintainers, governance isn’t just about checking procedural boxes. The fact that a majority of maintainers belong to a single organization always raised a serious concern about concentration of influence. On top of it, when such major RFCs are pushed through, it forces us - as practitioners and advocates of Hyperledger Fabric - to reevaluate our trust in the project’s neutrality and suitability for enterprise grade solution. |
|
Thank you for raising these critical points and sharing your perspective as a dedicated practitioner and advocate. You are right that trust in the project’s neutrality is paramount, and your concerns about the concentration of influence are taken seriously. We want to assure you that our governance process is designed to be open and transparent, with all major architectural decisions debated publicly via RFCs. While the current maintainer group has evolved from those who contribute most consistently, we recognize that the perception of influence is a serious issue. The project's health depends on a wide range of perspectives. Our commitment to welcoming new contributors is precisely to address this. We genuinely seek more diverse viewpoints to strengthen the project's direction. Your voice is valuable, and we encourage you to continue engaging in these discussions and consider contributing to the areas you feel strongly about. A stronger, more diverse set of maintainers is a goal we all share. |
Just for the sake of clarity, none of these major architectural decision was ever debated or disclosed in public. |
Apologies if you think I was revisiting points that had already been covered. I realise that there have been discussions regarding using a lab instead of a new top-level Fabric project,— I was simply addressing the desire to see the new Fabric X repositories as soon as possible, to assist with the discussions in this RFC and #63. There are obviously alternatives for making the code available early, to aid openness and transparency, but if the maintainers are happy to decide on these RFCs without seeing the code, that's absolute fine too. |
|
Hi @cendhu, thank you for your responses and continued engagement.
I appreciate that each comment has been addressed. However, to be honest, I feel that some replies may not fully speak to the core concerns. That might be why similar points keep coming up.
That’s one valid interpretation. But as you know, “X” can mean many different things.
I understand your point that this is not a Labs project. However, what I really want to emphasize is the value of publishing the code early, so the community can review it and engage in deeper discussion. |
@jt-nti To add some context, the design and initial development of Fabric-X have been led by a group of individuals with deep roots in the Fabric ecosystem. This team includes several current and former maintainers, along with long-time contributors who have a thorough understanding of Fabric's architecture and evolution. The principles that made Fabric successful are being carried forward by this experienced team in Fabric-X. We hope this shared history and expertise provide confidence in the proposed RFCs. |
@satota2 I appreciate you sharing your team's experience. It's a perfect example of the potential for misunderstanding that we need to address proactively. I agree that any name choice could lead to some initial confusion, simply because the ecosystem is undergoing such a significant change. We believe that this is a temporary issue that can be solved with clear branding and documentation. Once the community becomes familiar with the new structure—where the "Fabric" project umbrella contains distinct sub-projects—the confusion around specific names like "Fabric-X" should resolve naturally. We see this as a managed transition rather than a permanent problem.
Thank you for pushing on this—you're right that early access to the code is key for meaningful feedback. The great news is that a significant portion is already available for review. For anyone interested in the new programming model, which is the successor to chaincode, the fabric-token-sdk and fabric-smart-client repositories are the perfect place to start. They work with both fabric and fabric-x. As for the core components like the orderer and committer, the code is ready and we're eager to share it. The updated charter is currently with the Linux Foundation legal team, who are finalizing it to ensure a proper open-governance launch. This is the final step before we can make the repositories public. As current maintainers, past maintainers, long-term contributors are involved, we have been meticulous in applying lessons from the original Fabric, with a deep focus on improving code maintainability and readability. We are confident you will see the benefits of this approach and welcome all contributions once the legal review is complete. |
@cendhu, I think that one of the main points here is that none of the suggested changes has ever been publicly articulated, proposed, or delivered to the community to the extent that it will be clear what is happening here. This is why having the code available before pulling it into the Fabric ecosystem is essential. While obviously, people working on that have very intimate knowledge about Fabric, the whole process of design, building, and coming up with ideas has never received any community feedback. Currently, it appears and is perceived as a drop-off, privately backed solution, where the only appealing advocacy in favour of acceptance is based on reputation and trust, which is a positive aspect. Still, this is not enough if you wish to treat the community with respect. Take, for example, evolution, which was done by moving from v0.6 to v1.0. Besides endless internal discussions, there was considerable communication and public debate about the new architecture before the final decision was made. Here it's the opposite. For instance, I carefully read both Fabric-X and Arma papers, and I have quite a few technical questions; moreover, I understand that these are currently only white papers yet to be submitted for peer review. The suggestions from @satota2 and @jt-nti to release the code under the IBM GitHub repository will be constructive in making an informed decision. |
@C0rWin Thank you for sharing your perspective. The RFC for Fabric-X was opened 27 days ago precisely to facilitate the kind of technical discussion you're looking for. While there has been debate on process, the technical questions have been minimal. The purpose of an RFC is to allow the community to engage and provide feedback, and our team remains ready to answer any specific technical questions you or others may have. As per the Linux Foundation's governance, a peer-reviewed paper is not a prerequisite. The formal RFC process, including a vote, was completed. To that end, please share your technical questions. We are eager to address them. |
I knew about the fabric acceleration work before the 63 64 pr rfcs came out. And was very happy about it. But then pr 63 in rfcs came along. And discussions started about it. I read the proposals. And immediately realized that such a system in production can be pulled by only a few people. Then I read the discussions. And it came to me, and you didn't hide it much, that you already have a customer for this system “Fabric-X”. But it seems that this customer has set some conditions for you: fabric-x must be open source, and it must be in the hyperledger community (which is easier to do by inheriting it from Fabric). Who can blame you for that, for wanting to implement your product faster? And make money? But I really ask you to consider another name for Fabric-X. Already now the “community”, which is not represented here but is actively using Fabric, is coming up with “obscene synonyms” for Fabric-X. Of the decent ones, it's “Fabric-XXX.” Now I have to disclose my interest. The possible reputational loss of Fabric-X will definitely hit Fabric Classic. And I really don't want that to happen. P.S. Everything written above, all the assumptions and conclusions, is a game of my mind. |
It's important to clarify that IBM's decision to open source Fabric, and similarly Fabric-X, stems from a long-standing commitment to open source principles and the belief that open collaboration fosters innovation and wider adoption. IBM has historically been a pioneer in contributing to and leading open source projects. The goal with Fabric-X is to leverage the benefits of open source development to build a robust and widely adopted system, just as was done with Hyperledger Fabric. We appreciate your recognition of the hard work put in by those involved in Fabric-X's creation. There is indeed a significant amount of work ahead to bring Fabric-X to fruition. We genuinely encourage your contributions once Fabric-X is open-sourced, as community involvement is crucial for its success and evolution.
In any large open-source project, reaching a consensus among all maintainers can be challenging, and we understand that several have their reasons for not supporting this proposal. We also believe there is nothing inherently wrong for a sub-project in the Fabric ecosystem to have the "Fabric" prefix in its name. We see the current naming friction as a temporary hurdle, much like the adjustment period seen when a feature is deprecated. Our view is that as users become more familiar with the capabilities of Fabric-X, the name will become a standard identifier and the initial confusion will fade. We are committed to managing this transition carefully to protect the standing of the entire Fabric ecosystem. |
|
The final comment period had ended, and there were no additional comments in the last two weeks. As we have a super majority of 7 out of 10 maintainers, it looks like we are good to merge this one. Discussions with the LFDT team indicate that they are OK with the coexistence model proposed here and a new charter that includes measures that will regulate the governance of such a model are in the final stage of preparation. |
13 participants
This RFC proposes the "Fabric Ecosystem Coexistence Model," a strategic framework designed to enhance the adaptability and future relevance of Hyperledger Fabric.
The model outlines a structure where multiple, distinct Fabric-derived implementations (e.g., the current "Fabric Classic" alongside new specialized versions like a potential "Fabric-X") can coexist under the unified Hyperledger Fabric project umbrella.
Key Goals & Proposals:
This RFC argues that such a model is crucial for Fabric's continued growth, preventing stagnation and allowing it to effectively meet next-generation DLT challenges. It draws parallels from other successful technology ecosystems like Java, Python, .NET, and Windows, where similar models of specialized implementations thriving under a common umbrella have proven effective and are popular.