TSC criteria for new projects in the Hiero org

[Reccetech]

This discussion focuses on the criteria TSC should set out for the acceptance of new Application projects. The definition of an "Application Project" is any project which is built on top of the Hedera network. This is as opposed to a Core, Service, or Mirror project as outlined in the Hedera HIP process here.

Background:

The Hiero technical charter states:
"The Project encourages the development of applications and core platform features that support an enterprise-grade Hedera network. Additionally, the Project seeks to enable the development of applications such as wallets, exchanges, explorers, bridges, SDKs, private ledgers, and cryptography, which help maintain and enhance the network's capabilities."

There is a lot of potential Application projects that could be brought to Hiero. This includes applications currently on the hashgraph repo like metamask snaps, guardian, and stablecoin studio, There are also a lot of open source application repos outside of hashgraph like asset tokenization studio, hedera-vc-api, hcs-20-toolkit etc. We also see recent activities like the recent Hello Future 2.0 Hackathon that has created a large number of very interesting open source projects and associated code all over github. It should also be noted that over the years THF and THA have sponsored a large number of open source projects that reside in their respective builders github repos.

Given the above a continuing problem the Hedera community faces is that with these open source application projects spread all over the internet we lose opportunities for developers to discover the code and contribute in building the next amazing project on Hedera. In many cases they might not find code that would support what they are building - so they give up or have to start it from scratch.

Viewpoints

In discussions to date I have heard two different viewpoints regarding Application projects on Hiero:
Viewpoint 1. We should encourage developers to submit a wide range of application projects to Hiero that meet criteria around maturity, community, long-term maintenance, etc.
Viewpoint 2. Hiero should only be home to applications like SDKs and a select number of reference applications that enable developers to build downstream applications. We do not want too many application projects in Hiero.

Next Steps:

The acceptance or denial of Hiero projects should be based on two gates:
a) Adherence to the Hiero technical charter
b) Adherence to the criteria set forth by the TSC for new projects. That criteria can be constructed in a way that supports viewpoint 1 or viewpoint 2 above.

Because the charters language is open to interpretation then it really comes down to the criteria. When considering criteria for new projects we can first look to the criteria used by other LInux Foundation projects. Some examples:

• Open Wallet Foundation
• Automotive grade linux
  Within Hiero we could also introduce Project stages like Sandbox, Incubation, and Graduation. In this process we could take in a large number of application projects in the Sandbox phase, and then if a serious community grows around a project it can graduate to Incubation and graduation. The Cloud Native Computing foundation provides a good model for this here

Keith Opinion:

From my vantage I prefer viewpoint #1 as a tool to make it easier for developers to discover code that can support their efforts on Hiero/Hedera. I think we should initially have a two stage process for Application projects. A sandbox stage where we can accept a large number of application projects with lower criteria, and a mature stage for application projects that reach a higher threshold. The TSC criteria for new sandbox projects I would suggest includes:

• Alignment with Hiero technical charter
• Project maturity
• Adoption of Hiero code of conduct
• Committed Maintainers
• Developer Resources (i.e. time) and commitment to grow the project
  In addition each project should have a TSC member sponsor who has spent more time looking at the project.

In the TSC meetings we should review the application, ensure the criteria as set forth has been met, and then approve the creation of the Sandbox Hiero project.

Feedback, suggestions, and comments welcomed.

[hendrikebbers]

This discussion focuses on the criteria TSC should set out for the acceptance of new Application projects. The definition of an "Application Project" is any project which is built on top of the Hedera network. This is as opposed to a Core, Service, or Mirror project as outlined in the Hedera HIP process here.

For me "Application" is totally misleading word in this context. For me an Application is something like an app on a mobile device, a SAAS or an application that I install on my desktop. HIP-1 defines "Application Project" as everything that is build on top of the Hedera network / a Hiero based network. With that definition our SDK are Applications. From my point of view that is totally confusing if we use that definition for discussions about Hiero. Even the HIP process should be more specific here (adding @mgarbs ).

By doing so I will split what you call Applications in 3 categories:

• Libraries: something that can not be started own its own but should be integrated in any other application to bring support for Hiero to that application. Examples are our SDKs
• Tools: a tool can be executed. Normally a tool is something that helps a developer or technical person to interact/configure/debug/analyze any other project of the Hiero org. Examples are JSON-RCP-Relay or Mirror-Node-Explorer
• Applications: an application can be executed. I would use that word only for artifacts that bring any functionality to an enduser (mostly non-technical). Examples are https://calaxy.com or https://hbarsuite.app.

[hendrikebbers]

"The Project encourages the development of applications and core platform features that support an enterprise-grade Hedera network. Additionally, the Project seeks to enable the development of applications such as wallets, exchanges, explorers, bridges, SDKs, private ledgers, and cryptography, which help maintain and enhance the network's capabilities."

We interpret that in a different way. For me "... enable the development of ..." means that we provide everything that developers need to create any software (independent if it is a SaaS, a Library, a tool or an application) that can interact with an Hiero based network. This does not mean that all those software projects should be located at the Hiero org. If it is a tool or a library it can make sense to transfer that repo to Hiero. if it is an application for enduser I will disagree.

Even for Libraries and Tools (see my definition above) I would say that it depends if we suggest to transfer that repo to Hiero. I do not see the GitHub Hiero org as a place that will contain hundreds libraries that integrate Hiero "in everything". Let's assume 50 people start projects that provide the functionality to use HBAR for payment in Wordpress/WooCommerce. While that usecase makes sense in general I disagree to have all those 50 repositories at the Hiero org.

[Reccetech]

So as I mentioned there can be many interpretations of the language in the technical charter. I think it's ultimately up to the members of the TSC to determine some standard acceptance criteria that governs which projects submissions become Hiero and which are rejected.

[hendrikebbers]

To get to that point we first need to define those wording because otherwise we would again talk about different topics when the criteria mentions an "application"

[hendrikebbers]

Within Hiero we could also introduce Project stages like Sandbox, Incubation, and Graduation. In this process we could take in a large number of application projects in the Sandbox phase, and then if a serious community grows around a project it can graduate to Incubation and graduation.

That exists in the LFDT: https://github.com/lf-decentralized-trust-labs

The Hiero TSC can suggest to move a project that will not be created / transfered to the Hiero org to the LFDT Labs org. That is the kind of "sandbox" for the LFDT (including Hiero).

[Reccetech]

If the goal is to make the code more discoverable for the Hedera/Hiero community - then this seems like a sub-optimal option.

[hendrikebbers]

Having a "projects based on Hiero" on the hiero.org page would already solve that from my point of view. I do not want to search in all source code of any application that us using Hiero. That sounds to me like all application that use a specific database should be in the org of that database. That is wrong from my point of view. If you look at https://github.com/neo4j as an example you will find near to 100 repos (what is a lot) but non of them is an application (see my definition) that is using Neo4J. All those applications are somewhere else at Github. Those are not even listed at https://github.com/neueda/awesome-neo4j?tab=readme-ov-file - An example of an application would be https://github.com/jQAssistant

[hendrikebbers]

General information: Additional information for adding a project to Hiero (project proposal, TSC voting, ...) can be found here: https://github.com/hiero-ledger/hiero/blob/main/howto-transfer.md

[popowycz]

My perspective regarding the acceptance criteria is fairly similar to what Keith lays out and what I had mentioned previously (outside this thread):

• The contributed project/code (code) is aligned directly to Hiero's core mission (in this case, is linked or dependent to the services / consensus node code via HAPI). Contributors should be able to highlight the alignment/dependencies that demonstrate that aspect.
• The code meets the licensing and DCO requirements (as documented in )
• The code has an identified and committed maintainer(s). Not sure how we assess the commitment level, but may require that the named individuals confirm that committment via their github handle.
• The code has some minimal level of community support (it's not a dump and run and then it decays). We might look at the time and amount of commits on the repo being contributed as one of the metrics to review.

Of course, there are some broader aspects that should be assessed as well, but I think the above are the core criteria.

[edward-swirldslabs]

I think it makes sense for Hiero project membership to be focussed on curating and developing the tools and libraries that developers use to create Hiero compatible ledgers and applications. It might also make sense to include basic applications which have become more like OS level utilities, they show up on near every instance of the ledgers because they enable core use cases. Take for example Hashscan.io. This is not a library or a tool critical to the functioning of the ledger, but more of an application that provides utility to users of the ledger. The code that implements Hashscan.io as a web interface (or code that provides equivalent capability) should be in Hiero, imo.

That said I think there is a lot that Hiero can do to support the applications that are built on top of Hiero projects, including Awesome lists linking to community projects and providing tutorials with links to example projects that demonstrate how to use the tools and libraries that Hiero curates.

In this point of view, hcs-20-toolkit, stable coin studio, asset tokenization studio, etc all enable other use cases to be developed more easily and could be projects in Hiero. A barebones common wallet implementation would be admissible as a project and it would link to repositories for extensions that build on top of the common core.

Similar to how Hiero is not Hedera, the projects in Hiero would not be user facing brands. The branded repositories can be linked to as example instantiations of the base projects.

I see a dividing line along this way: Suppose the H-Combinator was a for profit incubator funding and helping launch other commercial enterprises. H-Combinator creates a new effort Project X as a for profit endeavor. Project X itself wouldn't belong in Hiero. But Project Y would where Y is the core capability of Project X. This allows for other commercial projects such as Project Z (extending Y) to emerge as a competitor.

[hendrikebbers]

Mirror Node Explorer is the non branded code of hashscan.io and I really want that in Hiero :)

[theekrystallee]

In this point of view, hcs-20-toolkit, stable coin studio, asset tokenization studio, etc all enable other use cases to be developed more easily and could be projects in Hiero.
... the projects in Hiero would not be user facing brands

so would the guardian library repo belong in hiero as a non-branded?

[theekrystallee]

hashio as well

[theekrystallee]

if we don’t want to clutter the hiero org with full individual repos for community-submitted projects but still want them to be discoverable within the org, can we create a community-projects or hiero-community repo and add projects as submodules instead of full repos? this, along with a webpage listing on hiero.org

[theekrystallee]

oh, didn’t know we had that repo, so we can go that route for community submitted projects. another idea is if we had a repo like awesome-contributions where each project gets its own dedicated README instead of just being listed on one page? projects could submit PRs with detailed descriptions and links. this makes it more discoverable and gives it more detailed visibility into each project. just a thought

[Reccetech]

So I think this is a great proposal, and we should do it for all the projects that have no interest to be in Hiero.
However for the purposes of this conversation I think we need to consider that for a project that goes through the moderate effort of submitting their project to Hiero TSC it is probably doing so because they wish to build a community of developers around their project for support and growth. As such they want to take advantage of Hiero infrastructure, codes of conduct, developer awareness, linux foundation brand etc to encourage contributors to join them. In contrast it is very hard to build a community for your project if it lives on a personal or private company github.

[hendrikebbers]

Agree on all that. But that is still not a reason to add each and every project (that might all be great) to add to Hiero if they do not match the scope of projects we (TSC + community) see in Hiero. Having technical / formal criteria (DCO, licenses, ...) is not enough from my point of view. We need to define what kind / type of projects should belong to Hiero and what projects should be supported by mention them on our pages / awesome-contributions repos / what-ever. That is the point we need to discuss. The formal criteria are not a big deal or problem but they are not enough from my point of view.

[edward-swirldslabs]

I assume at minimum the following holds:

• Governance: The entity submitting the project to Hiero is releasing the governance and direction of the project to Hiero and whatever community forms around the project. That community could make decisions and take the project in a direction that the original submitters do not want.
• Utility: The project must have potential for widespread impact and use.
• Uniqueness/Distinctiveness: The project is not too similar to existing projects within Hiero, otherwise join forces with the existing project.
• Longevity: The current project developers have intention and commitment to continue participating in the development and governance of the project.
• IP Benefits: The name of the project is not branded or trademarked as owned by a specific company or entity that is not Hiero/LFDT.
• Versatility: The project is easily extensible for a variety of deployments or applications.
• Leadership: The project must be facilitated by people who are capable of facilitating and oriented to cultivating open collaborative community around the project.

[hendrikebbers]

I really like that list.

[hendrikebbers]

I created a diagramm that shows how I see the Hiero org and what kind of project belong to Hiero from my point of view. Everything that does not belong in a given category should be discussed very critical. I would like to see that in combination with the criteria that @edward-swirldslabs mentioned.

[hendrikebbers]

@nathanklick U assume it would be in Tools next to Solo, correct?

[theekrystallee]

what's the plan for smart contracts repos? the only SC related one in this diagram is the json-rpc relay. is there a plan to separate smart contract services and only moving over the other hedera services to hiero?

[hendrikebbers]

From my point of view json-rpc relay is not related to smart contracts. YOu can use it top call contracts by using the Ethereum API but our contract service (including EVM and so) is part of consensus node.

[hendrikebbers]

I assume https://github.com/hashgraph/hedera-smart-contracts makes sense to be transferred later.

[hendrikebbers]

Happy to add that to the next version of the diagram :)

[timo0]

I'd like to share why I think keeping Hiero focused and lean makes more sense:

Let's be real about governance - most community projects come from developers with their own vision and ideas. Even if they say they're willing to hand over control, they probably want to keep steering their project in their intended direction. That's totally fine, but it means bringing them into Hiero might create more friction than benefit.

Also, from a practical standpoint, trying to manage tons of projects under the Hiero umbrella would be quite challenging. Quality control would become harder, and the overhead of reviewing and governing all these projects would be massive.

I think Hiero works best when it focuses on what matters most: core infrastructure and essential components. Sure, having reference implementations for key pieces like wallets makes sense - they set standards and show best practices. And if member organizations want to sponsor specific projects, that's great because it comes with built-in support and maintenance.

Instead of trying to bring everything under the Hiero umbrella, why not:

• Create a well-curated list of community projects on hiero.org / awesome-contributions repo
• Keep a clear line between what's core Hiero and what's part of the wider ecosystem
• Focus our organizational resources on the fundamental pieces that everything else builds on

This way, we can maintain high standards for our core components while still supporting a vibrant ecosystem of projects that can develop independently. It's kind of like how successful open source projects like Neo4j handle it - they keep their core focused while fostering a broader community around it.

[popowycz]

I think this aligns fairly well with @theekrystallee 's comments where we effectively have two or three tracks under Hiero. This would, however, entail an expansion of the TSC's role to cover both scenarios with unique processes for each (i.e. we can provide some level of curation / oversight for the broader contributions, while not overly diluting our attention from the core). The potential third

One thought would be to have a permanent sub-comittee of the TSC which has that mandate to provide that curation responsibility over community projects while still having the connection to the TSC.

I'm in the camp of being more open to contributions to foster engagement with a broader community, but still ensure that this second track doesn't devolve into a dumping ground.

The potential third track is archived / deprecated projects. This falls out of the scope of any active governance, but projects/repos could be resurrected in the future with appropriate resource commitment.

[hendrikebbers]

I collected all informations regarding the criteria of projects that I have found at different places and tried to create a "pitch" for the TSC meeting today. That can be used as a starting point of discussion or in best case as a base for a TSC approved list of criteria:

Hiero Project Acceptance Criteria [DRAFT]

To ensure that projects added to the Hiero org align with our goals and technical standards, the following criteria must be met:

Hiero’s Mission and Technical Charter

• The project must align with Hiero’s technical charter and core mission.
• The project must be vendor-neutral and deployable/interoperatable to any Hiero-compatible network.
• The project should provide widespread impact and usability across Hiero networks.

Governance

• The project must adopt and adhere to the Hiero Code of Conduct.
• The entity submitting a project must release its governance to Hiero’s open community.
• The project’s name should not be trademarked or owned by an external entity that is not Hiero/LFDT.

Licensing & Compliance

• The project must meet Hiero’s licensing and Developer Certificate of Origin (DCO) requirements.
• The codebase of the project must be licensed and all its dependendencies under an approved open-source license.

Security & Quality

• The project must follow our best practices for security and repository setup.
• The project should have some level of community support (avoid "dump and run" projects that decay over time).
• A project that require significant additional work should outline a roadmap for completion and maintenance.

Maintenance Commitment & Sustainability

• The project must have identified maintainers willing to commit to ongoing development.
• The original developers should demonstrate a commitment to maintaining and growing the project.
• The project must not be short-lived or abandoned soon after being accepted.

Project Categories and Unique Selling Point

• The Project should fit in one of the given categories:
  • Core projects essential to Hiero network operations.
  • SDKs, libraries, and tools that can be used across all Hiero networks.
  • Specifications and documentation applicable to all Hiero networks.
• The project should not compete with or duplicate existing projects within Hiero; instead, it should complement or extend them.
• Projects with overlapping functionality should be merged or collaborate with existing initiatives.

Not allowed in Hiero

• The project must not be specific to a single Hiero deployment (e.g., Hedera-specific projects should be generalizable across Hiero networks).
• The project must not be short-lived or abandoned soon after being accepted.
• A project must be primarily related to the network (such as a wallet app) rather than only incidentally using the network (such as a game with a built-in wallet).

Project Categories

The following diagram gives an overview of the project categories by adding some description and examples for projects in those categories. The goal of the diagram is not to show all projects or define a fix list of projects.

[popowycz]

Some feedback but mostly questions regarding the framework diagram.

• Would test harnesses and similar be categorized under Tools?
• Is Hiero Mirror Node really Core? It sits outside the core API and there are various providers of this service today that are not managed by the network provider.
• Where do projects like the Guardian fit here, if at all?

There is a criteria that a project must not be specific to a specific Hiero network. I presume that this means it allows for configuration to be used with other deployments of the core? I would not want to exclude those that were originally written for a particular network (e.g. Hedera) but can be modified, without a complete rewrite, to work on different networks.

[popowycz]

I am re-echoing my comments elsewhere in this discussion that we need to find a home for actively managed projects that aren't in the foundational repos (I'm trying to avoid using Core given it's other use here). FWIW, I would add an additional category to the diagram, with some distinction that provides a place for additional contributions that don't fit into one of the existing categories. This would include accelerators (e.g. stablecoin-studio, asset-tokenization-studio to the extent they meet certain criteria.

[hendrikebbers]

@popowycz good points. Won't change the text before the meeting but I think you brought up important points