Follow up: GitHub organization split. Scenarios to consider.

[jwagantall]

Today, we have the hiero-ledger GitHub organization which hosts all projects. We believe that it will be graduated by LFDT in near future (Aug 2025). The projects hosted in this org require very high security standards (like hiero-consensus-node) that involve extensive CI, configuration management and token protection rules. Additionally, these projects are carefully following the best practices and security standards to be in compliance with the LFDT TAC mandates for keeping a graduated status.

With that, the discussion came up to create a second org (hiero-ledger-eco) that can contain incubation projects and more general community projects that do not need the high security standards or TAC compliance.

This scenario is creating the following pros and cons which need to be discussed:

• Having 2 orgs, could affect the way we quantify (in metrics) the effort and growth of the hiero project. This is particularly important for tracking maintainer diversity. Having 2 orgs, affects the way the diversity in the community is represented as a whole which could eventually affect our graduated status.
• On the security front, we can't extend security coverage (StepSecuirty, Snyk, Bounty...) to less standardized repositories.
  • I understand that changing the configuration in StepSecurity, for example, is complex if we want to adopt these repos and not cover them?
  • Can we have these repos join hiero-ledger instead and explain in the README the lack of coverage? Can this affect our project status if we graduate?
• From the community call discussion, there is a strong preference on having maintainers of the new repos work on their maturity and workflows to get up to standards with hiero-ledger and then migrate. Rather than migrating these repos into hiero-ledger-eco.
• We need to create a task force of recurring sessions where we include maintainers, security experts and release managers to get to a conclusion on this process and present it to the TSC for approval.

[jsync-swirlds]

This seems like a lot of overhead for a small gain, to me.
In other contexts I have seen it work very well to have new community driven projects start as completely independent repositories. When those projects express an intent to join the more restricted organization, they conduct the necessary reviews, audits, updates, and upgrades in-place before migrating to the restricted organization via a fork.

This minimizes the amount of extra structure needed in general, avoids confusion about project status and/or affiliation, and only imposes added time and effort when that expenditure is most likely to be necessary and effective.

[andrewb1269hg]

I propose we go with a setup of two organizations instead of a single hiero-ledger organization. I propose we have hiero-ledger-eco as a second organization.

1. Security - Security around the hiero-ledger organization is very serious. We've put in an extensive amount of effort to ensure all CI workflows inside the hiero-ledger org are up to high standards. Having a second org (hiero-ledger-eco) allows maintainers to move their repo to a hiero organization while not requiring the stringent security standards. It also allows maintainers for the hiero-ledger org a single location to review all repos before moving to the higher security org.

2. Diversity of the community - While having multiple organizations may make the metrics more challenging, a lower bar to entry for the community means we will have a more diverse community.

3. Speed to incorporate new repos - A lower bar to move repos from separate orgs into the hiero-ledger-eco org means we grow the community faster. It also allows us to see community projects being actively developed in the wider hiero ecosystem.

4. Flexibility - Some repos may choose to graduate to the hiero-ledger org while others may choose to exist in the lower security hiero-ledger-eco org. A single, high-security org (hiero-ledger) would not allow us to track community projects that are lower security in a single location.

[rbarker-dev]

I concur

[jwagantall]

@andrewb1269hg , in case we went for a single org, ( i am not saying this is necessarily the preferred path, but instead still evaluating the pros and cons) would it be feasible to include repositories with less stringent security requirements under the hiero-ledger org, accompanied by a clear disclaimer (in the README.md?) outlining which security standards are or aren't enforced for those specific repositories?

Additionally, is it possible to configure tools like StepSecurity, Snyk, or others to exclude certain repositories from enforcement or scanning? If so, are there any inherent risks in maintaining this kind of mixed-security setup within a single organization?

This question came up from my conversation with Diane, Keith and Michael and would like your POV to communicate to them.

[dr20240304]

Currently, we are not enforcing comprehensive security measures such as Snyk and other security tools organization-wide. These tools are currently only implemented for our critical code repositories. However, there is a possibility that in the future, we may need to adopt more comprehensive security tools or controls across the entire organization to address critical threats or risks effectively.

[dr20240304]

to create a second org (hiero-ledger-eco) that can contain incubation projects and more general community projects that do not need the high security standards or TAC compliance.

I agree with this perspective. Hiero-ledger org plays a critical role in ensuring security, especially given that it hosts several critical repositories. As such, it might be necessary to implement robust organization-wide security measures in the future to mitigate growing threats and attacks. Additionally, I believe separating these general community projects from the main organization's core activities could be a prudent step.

[topdevStar1126]

Hi, Sorry for interruping. I really look forward assistance of you experts.

I am developing dApp on Hedera testnet. Also I have deployed test network using Solo. Is api list same between Hedera testnet and testnet deployed by using solo? Also how can I develope Faucet api on testnet deployed by using solo.

Thank you. 🙏

[jwagantall]

@topdevStar1126 , please open a new inquiry under https://github.com/hiero-ledger/solo/issues

[jwagantall]

Closing this for now as we have decided to continue hosting all repos under hiero-ledger