Re: Hyperledger Labs versus Project incubation status

Danno Ferrin

My read is that a lot is hinging on the pre-existing code base.  Besu came in with pre-existing code but it had been open sourced for over 6 months prior to our proposal.  I don't know all the backstory of each project but I think we should look at how much pre-existing code seeded the incubation of each project and where it came from.  Cactus was the most recent and they came out of Labs.  Even fabric and sawtooth came in with notable code, but as they were early in the life of hyperledger and basically bootstrapped the project they may not be good measures of what we want going forward.

Another standard we should look at (that I think Firefly passes to be clear) is the total number of maintainers.  Not in terms of corporate decentralization like we look at for active status but the raw count of people committing code.  Solang proposed entering incubation but it was rejected as there was only one core contributor. If we are collecting incubation requirements then we should add one that requires the population of consistent contributors to be greater than one.  Possibly three as the minimum.

On Sun, Jun 6, 2021 at 7:01 PM Brian Behlendorf <bbehlendorf@...> wrote:
Hi all,

The project lifecycle document at which is published here:

Pull requests might be a good way to suggest edits, though every TSC member can edit that as well.

On 6/6/21 3:08 PM, Hart Montgomery wrote:
Even if there are not "hard and fast" guidelines, an explanation of things that are likely to make people favor a proposal versus things that are likely to get a proposal rejected would be immensely useful.  For instance, even though it appears to have never been written down anywhere, it has always been an unstated rule that projects without maintainers from at least two distinct companies are not approved.  We've never approved a project without contributions from two different entities, but we've also never put this down on paper either.  So just explaining stuff like this would be very useful.

And that's something we've always advised inbound projects. That was the case here - the proposal specifically mentioned that there was a contributor from Atato and another from Consensys Health "committed to contributing as of this proposal" and I believe would have been part of the initial set of maintainers on the repo. I think that got lost in the conversation as someone who was simply being supportive or was slapped on at the last minute, but the developer from Atato was there on v0.2 of the proposal and had worked with the code before.

I would also suggest that we add text encouraging project proposers to ask individual TSC members for feedback before sending the proposal to the whole group. 

This was also done with a majority of the TSC members, which was very helpful to the proposal, actually. Some signed on as co-sponsors as a result. Some with whom the proposal was shared, though, didn't engage until the very end. It's OK, people get busy.

David wrote:

As a new TSC member who didn't have the benefit of precedent with respect to project proposal evaluations, it was a difficult decision for me whether to speak my mind or not when the process was moving faster than I was comfortable with given a number of unknowns. I've been trying to think about what might have improved the experience for all. I liked Hart's suggestion in RocketChat about project incubation guidelines. For example, for projects that have not been open source previously, perhaps they should be required to start as a lab for a short time so that they can contribute their code in a welcoming environment and get familiar with open source licenses and processes prior to the public scrutiny of a project proposal evaluation.

That has typically been what the Incubation status has been for:

It's one reason we caution projects that have not been open source to not even propose to come in as an Active Status project because that's a pretty high bar. Besu wanted to be Active upon acceptance and had an arguable case to be one, but it was the right thing to not award that out of the chute.

Labs was not started to be the pre-Incubation incubator. It was started as the place for projects that were still finding their footing as a product - perhaps they were just a library, an experiment or hackathon result, an add-on or way of configuring some other project, something presented humbly and not really seeking to build a larger community from the get-go but to get something out there. Labs is also useful for something an exiting HL project comes up with that could be, or is even intended to be, used well beyond that project, which is why I'm guessing there's been some good Fabric components landing there recently. The fact that there have been some Labs which have found each other, combined, and gone on to become projects like Cactus, shouldn't be interpreted as this being either a requirement for a project or a goal of the Labs. Firefly didn't seem to be anything like the other things in Labs, and seemed to be a lot more mature (and in wider production use) than many of the things accepted as a Project over the years.


Brian Behlendorf
General Manager for Blockchain, Healthcare and Identity
Twitter: @brianbehlendorf

Join to automatically receive all group messages.