Beyond Hedera: How Hiero Sets a New Standard for Decentralized Open-Source Development

Introduction

In September, 2024 Hedera announced that it is donating its entire codebase, including all Hedera services, development accelerators, and SDKs to the Linux Foundation Decentralized Trust (LF Decentralized Trust) as project “Hiero.” With this groundbreaking move, Hedera became the first Layer 1 public distributed ledger to donate its code to an independent entity, fully embracing a vendor-neutral governance model. The Hedera public ledger now operates as an instance of the Hiero codebase, paving the way for a new era of decentralization.

By transferring the source code to LF Decentralized Trust, Hedera guarantees that the code remains open and independent, free from reliance on a single entity for maintenance. This move also integrates the project into a broader ecosystem of developers at LFDT, encouraging cross-industry collaboration and innovation.

This blog explores the technical and strategic implications of Hedera’s source code donation, including shifts in governance, contribution models, and the broader impact on the Hedera ecosystem.

Why Did Hedera Contribute its Code to the Linux Foundation Decentralized Trust?

The LF Decentralized Trust (LFDT) is the leading force in open-source standards and decentralized technology innovation. As the premier open-source foundation for decentralized infrastructure, LFDT provides a vendor-neutral, collaborative environment where organizations and developers shape the future of distributed ledger technology (DLT), blockchain, and trust systems

By setting industry standards and driving the evolution of decentralized technologies, LFDT accelerates adoption across industries while ensuring interoperability, transparency, and security. Hedera’s contribution to LFDT aligns with its vision of fostering a global, community-driven ecosystem where decentralized networks thrive under open governance and cutting-edge development.

Vendor-Neutral Governance
Hedera will continue to manage and maintain its own instance of the codebase, but the Hiero codebase itself is now governed by the Linux Foundation Decentralized Trust (LFDT). This shift ensures that no single entity—including the select set of entities that participate in Hedera’s decentralised governing council—has exclusive control over future development.

By adopting a vendor-neutral governance model, Hiero opens the door for contributors from diverse industries and communities to participate. This inclusive approach fosters collaboration, innovation, and long-term sustainability, allowing all stakeholders to shape the project’s evolution on equal footing.

Transparent and Open Contribution Model
Hiero will adopt the Linux Foundation’s transparent contribution model, so anyone—whether an independent developer or a major enterprise—can contribute to the codebase and be present at the TSC meetings. See section on Project Hiero Technical Steering Committee (TSC). This inclusivity ensures that diverse input and innovations will form the foundation for increased contributions from various developers, researchers, and organizations interested in decentralized trust systems.

The Linux Foundation’s Collaborative, Global Ecosystem
In 2024, the Linux Foundation achieved significant milestones, reflecting its ongoing commitment to open-source innovation and has reported that over 71,000 developers collaborated globally across more than 1,300 projects, driving advancements in areas such as artificial intelligence, cloud computing, and edge computing.

By joining LF Decentralized Trust, Hiero will tap into a global network of developers and enterprises already engaged with Linux Foundation projects. This open environment fosters faster problem-solving, encourages creative solutions, and eliminates the bottlenecks created by isolated development.

Furthermore, the Linux Foundation’s standardized practices and interoperable tools promote scalability and reuse of technology blocks, ensuring that advances in one project can readily contribute to improvements in another. By breaking down these barriers, Hiero can innovate more freely and efficiently, rapidly integrating advancements across the ecosystem, while also accelerating development and the potential for technological breakthroughs.

Enterprise Support and Credibility
Hiero inherits the Linux Foundation’s credibility, which is supported by the foundation’s globally respected standards and backing from major enterprises. This support will help Hiero attract enterprises and institutions and encourage them to participate in its development and trust the project’s integrity.

Resource Accessibility
The Linux Foundation’s robust infrastructure will make it easier for developers to contribute to Hiero. Tools, documentation, and testing environments will be readily available, reducing the friction for onboarding new developers. By lowering the barriers to entry, Hiero should attract a larger pool of contributors, especially those who may not have otherwise considered participating in a blockchain project.

Setting a New Standard: LF Decentralized Trust as a Model for Decentralized Open-Source Development

Hiero’s integration into the LF Decentralized Trust sets a precedent for other decentralized protocols in the crypto world that are grappling with governance issues, siloed operational structures, and a lack of industry standards. Through LF Decentralized Trust vendor-neutral governance, Hiero ensures that project development is guided collectively.

LF Decentralized Trust’s focus on interoperability and standardized practices sets a regulatory-ready framework, offering other crypto protocols a clear route to achieve scalability, compliance, and industry credibility. Hiero’s journey showcases how aligning with the LF Decentralized Trust can empower decentralized projects to overcome common obstacles, paving the way for sustainable, community-driven growth within a cohesive and innovative ecosystem.

How Will Hiero’s Codebase Be Maintained?

Projects under the LF Decentralized Trust are expected to promote the establishment of a Technical Steering Committee (TSC) according to specific governance guidelines. The TSC plays a vital role in overseeing each project's technical aspects, including setting the project’s technical direction, managing contributions, and ensuring code quality.

The Linux Foundation emphasizes that open-source projects should adhere to governance structures like TSCs to ensure transparency, collaboration, and technical excellence.

Project Hiero Technical Steering Committee (TSC)
The TSC is the governing body that oversees all of Project Hiero’s technical aspects. It ensures the project's integrity and alignment with its open-source community. The TSC facilitates collaboration among contributors, committers, and maintainers, helping to ensure the project's quality, security, and evolution.

Open Governance and Meetings
The TSC operates transparently, with all meetings open to the public. These meetings will be conducted and recorded on Zoom. Anyone is welcome to attend. This openness ensures that the community can actively engage with the TSC’s discussions, provide insights or feedback, and reinforce the project's open-source ethos. Furthermore, the meeting minutes will be available to everyone in this GitHub repository.

The composition of the TSC is documented in the Hiero-ledger/tsc repository, allowing anyone to see the individuals who are responsible for leading Project Hiero.

Election of TSC Members
The TSC will consists of nine (9) members who are selected from various groups within the community:

1. Dr. Leemon Baird holds a permanent seat as the inventor of the hashgraph algorithm.
2. Hedera Hashgraph, LLC will hold a transitional seat during the project’s initial three years.
3. Maintainers from the project and its sub-projects collectively elect three members.
4. Contributors who have been active in the past year elect one representative.
5. An End User, defined as someone primarily using the project’s software, is elected by a process defined by the TSC.

During the project’s early startup period, the initial TCS members elect additional seats, helping to ensure a balance of interests and technical expertise. The current members of the TSC include Dr. Leemon Baird, Richard Bair, Hendrik Ebbers, Stoyan Panayotov, Alex Popowycz, and George Spasov.

Responsibilities of the TSC
The TSC’s responsibilities encompass a broad range of governance and operational tasks that guide the development of Project Hiero. These include:

• Technical oversight: Ensuring the health and security of the project by reviewing and approving system or project proposals.
• Project organization: The TSC may create, promote, or deprecate sub-projects as necessary, ensuring a flexible and scalable project structure.
• Workflow management: Establishing and enforcing procedures for submissions, reviews, and archiving projects or contributions.
• Representation: The TSC appoints representatives to collaborate with other open-source communities or standards bodies.
• Community building: The TSC’s responsibilities include establishing norms, managing release cycles, and implementing security policies to ensure the project’s long-term success.

TSC Voting and Decision-Making
Although the TSC operates primarily on a consensus basis, formal votes are sometimes necessary to move the project forward if consensus cannot be reached. In these cases, each active TSC voting member casts one vote. A quorum for TSC meetings is defined as two-thirds of the voting members. If the votes don’t resolve the issue, any member can escalate the issue to the Series Manager for assistance.

This structured yet flexible governance ensures that the project remains adaptable, transparent, and community-driven. The TSC provides the necessary technical leadership to guide Project Hiero forward.

The New Contribution Model

The Hiero Improvement Proposal process replaces the original Hedera Improvement Proposal (HIP) process, though the mechanics remain largely the same. Anyone in the community can submit proposals for features, bug fixes, or optimizations. These submissions undergo a rigorous review process involving contributors, committers, and maintainers.

The Process Remains the Same
Anyone in the community can create, discuss, and submit a proposal for review. When Hedera previously owned the codebase, the Technical Committee (a subcommittee of the Hedera governing council) was responsible for reviewing and approving the HIPs. Moving forward, the TSC will oversee the approval process and create a roadmap based on the proposals. Contributions and collaboration from the entire community, including Hedera, are welcome. Hedera’s Technical Committee will accept HIPs for implementation on the Hedera instance which will now be separate from the Hiero instance.

There are various contributor roles, each with specific responsibilities.

Contributor:

• Responsibilities: Any individual who submits code, documentation, or other improvements to the project. Contributors typically don’t have direct commit access to the project’s repositories.
• Access: Submit changes through pull requests or patches, which are reviewed by higher-level roles.
• Involvement: Contributors can propose new features, fix bugs, or enhance documentation that improves the project, without decision-making authority.

Committer:

• Responsibilities: Review contributions and merge accepted changes to the project’s repository, ensuring quality and standard compliance.
• Access: Committers have direct write access to the repositories and review pull requests.
• Involvement: Trusted contributors who consistently improve the project and follow its guidelines, serving as gatekeepers for integrated code.

Maintainer:

• Responsibilities: Oversee the project’s health and direction, make high-level governance decisions, and contribute to strategic development.
• Access: Have the highest level of authority, including the power to approve major changes, assign tasks, manage releases, and resolve disputes.
• Involvement: Guide project evolution, set priorities, and ensure alignment with broader ecosystem goals, overseeing contributors and committers.

Flow of a Proposal Through These Roles
Here’s how a proposal flows through the different roles at LFDT:

1. Proposal Submission by a Contributor - A contributor proposes a feature, bug fix, or improvement by opening a pull request or issue, including necessary documentation, code changes, or ideas.
2. Review by a Committer - A committer reviews the proposal with the purpose of checking code quality, documentation, project standards, and alignment with goals. The committer may request changes, improvements, or clarifications before approval.
3. Oversight by a Maintainer - Maintainers review significant proposals, especially those affecting the project’s direction, and may provide input before final approval. For major changes, maintainers need to give explicit approval.

Hedera's Autonomy
Hedera TechComm is a **subcommittee of the Hedera Governing Council **responsible for overseeing the technical roadmap, reviewing proposals, and ensuring the development of the Hedera network aligns with its strategic goals.

Before Hedera donated its codebase to the Linux Foundation Decentralized Trust (LFDT) as Project Hiero, TechComm played a key role in evaluating and approving HIPs, which introduced new features, optimizations, or protocol changes to the network.

With the transition to Hiero, the governance of the core codebase now falls under the Hiero Technical Steering Committee (TSC). However, Hedera TechComm remains active—it still reviews and approves HIPs that impact the Hedera network specifically, ensuring that updates to its instance of the Hiero codebase meet the network’s operational and security standards.

Key Responsibilities of Hedera TechComm:

• Reviewing and approving Hiero Improvement Proposals for implementation to the Hedera instance of the Hiero codebase.
• Maintaining Hedera’s instance of the Hiero codebase.
• Ensuring network security, stability, and scalability.
• Overseeing testing and deployment of approved changes to Hedera’s network (testnet, previewnet, and mainnet).
• Collaborating with the Hiero TSC to align development efforts while maintaining autonomy over Hedera’s implementation.

Essentially, Hedera TechComm continues to govern Hedera's version of the Hiero codebase, ensuring it evolves in alignment with the network’s needs while benefiting from contributions made to Hiero under LFDT governance.

Forking and Compatibility
In rare cases, Hiero may implement code that doesn't work with Hedera, requiring a separate version (fork) of the codebase. However, this is unlikely, as Hiero's main goal is to support the growth of the Hedera network and ecosystem.

Build and Release Process
The TSC will have its own build, testing, and release processes, but Hedera will continue to maintain its independent systems for testing and deployment. Hedera will manage deployments to its testnet, previewnet, and mainnet, ensuring each build meets Hedera’s requirements. As a community member, Hedera participates in the TSC along with others.

Developer Contributions

First-Time Code Contributors
For those who are new to contributing to Hiero or any open-source project, Hedera designated certain issues with the label “good first issue,” which are specifically reserved for first-time contributors. Hedera understands that creating the first pull request can feel daunting, so these labeled issues are intentionally less complex, making them ideal for new developers and those who are exploring open source for the first time.

Developer Certificate of Origin
To have contributions considered and to adhere to the Linux Foundation’s standards, each code commit must include a Developer Certificate of Origin (DCO). This certifies that the contributor has the legal right to submit the code—either as the original author or with permission from the original author—and grants the project permission to use the contribution under the project's license. Refer to the CONTRIBUTIONS.md file in the project’s repository for detailed contribution guidelines. The committer must also have GPG keys set up on their account.

GPG Keys
Each contributor must also have a GPG key associated with their GitHub account. A GPG key is a cryptographic key pair that is used to sign and verify digital communications, ensuring authenticity and data integrity. At the Linux Foundation, GPG keys are necessary for verifying contributors' identities, protecting code integrity, and fostering trust in open-source projects by preventing unauthorized changes.

Contributors can maintain anonymity by using pseudonyms or alternate email addresses, but they must associate their GPG key with their GitHub account. This ensures that contributions are securely signed and verified without revealing personal information.

Conclusion

The migration of Hedera’s codebase to the LF Decentralized Trust Hiero project represents a forward-thinking step toward open, collaborative development in decentralized technology. By adopting the LF Decentralized Trust vendor-neutral, transparent governance, Hiero empowers contributors from all backgrounds to drive the project forward, fostering a thriving ecosystem around hashgraph technology. This move sets a new standard for decentralized open-source development and aligns with the growing need for interoperable, community-driven solutions in the blockchain and DLT spaces. As contributors, organizations, and developers continue to shape Hiero, we’re witnessing the dawn of a more inclusive, impactful open-source future. Join us as we build it together.