Re: Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

Jonathan Levi (HACERA)

Hi Vipin,

I tried to start and end the email without taking sides. See the ending paragraph below:

Sounds like having a clear criteria from the TSC and evaluating whether Iroha meets it, will be the most simple, fair and straight-forward way to go. "Active" or back to "Incubation", please all keep in mind that not too far down the line, the TSC will need to use the same criteria for Grid and other projects. 

No, I am not a believer of making rules on the fly, just as much as I didn't believe in the suggestion to erase the git commit history.

I believe that the TSC should be clear as possible, about the criteria and apply it across the board. The definition for what "active" is pretty well written IMHO. Seems like the "1.0" isn't as clear.

On the contrary, I, too, suggest(ed), just like Dave and Arnaud to clarify the requirements, so that we don't need to have such threads for each project "on the fly".

I don't believe we (Jonathan and you Vipin) are in disagreement... unless my email below wasn't clear. If the latter, then I'd be happy to clarify.

Thanks, Jonathan

On Sat, Mar 16, 2019, 8:35 PM VIPIN BHARATHAN <vip@...> wrote:

I started the thread; so that we can have objective criteria when visiting 1.0, to compare with other projects that were given the nod to 1.0; not about active vs. incubation. The vote that was up before the TSC on Thursday was 1.0 for Iroha. According to what I read in the emails everyone agrees that Iroha is ready for 1.0.  

If you are for changing the rules on the fly and pushing Iroha back into incubation; I certainly would not support it (I know it does not matter since I am not on the TSC). Dave's Grand Unified Theory of project readiness, which is still being worked on and which is not agreed on by the TSC yet, cannot be used as criteria post-facto.  I also hear Hart's POV that it does not matter as no-one outside HL really cares about this.

The DGUTPR is a good thing to have, for the future. Let us be very clear in our project lifecycle document. Governance is good when the rules are not arbitrary and consistent.


Vipin Bharathan
Enterprise Blockchain Consultant

From: tsc@... <tsc@...> on behalf of Jonathan Levi (HACERA) via Lists.Hyperledger.Org <>
Sent: Saturday, March 16, 2019 1:09 PM
To: vipin bharathan
Cc: tsc@...
Subject: Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
One moment pls. I thought that the whole argument/discussion was/is regarding whether the "active" status was justified... or whether the project should get back to "incubation".

That's what Dave, Chris, Arnaud have brought up (Mic commented on, etc.), having taken a second look at the diversity criteria.

If you guys recall, back in the day Dan Middleton and I (Jonathan) have been extremely lenient last year when most people on the TSC felt that there isn't enough community engagement using the tools that HL provides/provided. Please don't ask me to find the link to the recording. But I felt the same as Vipin, that we should not be that hard on Iroha...

It is very difficult to compare the level of attention a project gets when people have Intel Corp  or IBM Corp. behind it. But ultimately, it is up to the TSC to decide/vote based on the criteria that we all "shook on". If people deem that things need revisiting, then all the power to the changers.


Not taking sides, just trying to make sure that I can follow. Am I correct in understanding that Makoto suggests that companies don't want to (or are less happy to) contribute to a project that is in Beta (or, pre-1.0), while Chris, Arnaud and others are concerned that declaring a "1.0" before a project - including its community, developers, users, commerical and non-commercial supporters - make the Technical Steering Committee feel that it's ready?

If that's the case, then the steps that Arnaud and Dave are taking in terms of better clarifying and documenting what (measures) the TSC will use to evaluate such "1.0" readiness, in case people feel that these are not well defined... so that we don't spend weekends on such a long email threads, every so often (as thankfully Hart pointed out).

Unless, Vipin, your argument/suggestion is that they should not re-visit the "active" status at all?

My 2 (or 3) cents:

1. It is very difficult to build a community around a  layer 1 blockhain. We know all about it, that we even worked to create the free and open Unbounded Network, to help small projects as much as big ones to get more people around them, etc. (

2. From my familiarity with the people
Involved and having worked with them now for several years: I don't believe that the people mentioned have an "inner" agenda to harm Iroha.

3. Going 1.0 too early doesn't always help. Hyperledger Fabric 1.0 is an exception. And even then, it wasn't pain-free. As the release manager, there were many things that didn't get into the release, weren't at the right maturity level, I couldn't get others to confirm why they are needed, or didn't fit the overall flow of Fabric 1.0 architecture. Remember, a lot of.code was contributed from research labs across the globe.

I made many friends and a few "enemies" (who I helped later on to get some of these missing feature into Fabric 1.2, 1.3 and 1.4). Other than Arnaud (who was always a pain when it comes to running Fabric on Windows ;-)) - I believe that everybody else forgave me or at least understood why we couldn't get everything in. I hope.

But we see several (too many, to be precise) ICOs who have finally released a "1.0" in the form of a "mainnet", and they have no users, no token utility and no traction. Some are even paying others to publish fake trades on their systems (the founders will probably end up sitting in jail as they are paying others to to post wash trades, manipulate prices, etc.). But we aren't there. Just saying, that going 1.0 is not everything or the final thing - it is just the beginning.


Since this is not the case and we are far from such cases, not only because we know Makoto, who is a fine gentleman by all means, a hard working team, highly ambitious  and the Iroha team has been allocating people to address some of the issues (since Amsterdam's Hackathon at ABN Amro and Consensus 2018) and on several other occasions - they keep asking around to see how and what they can improve... so instead of "buying fake trades" Makoto spells it out very clearly without sugar-coating: they can't get (more/enough) external contributions while in beta, etc.

While it isn't easy to favor "inclusion" and remember that not all of us work for huge companies, at the same time, let's keep the discussion technical and evaluate based on the the set criteria. Reminding you that I was "vehemently" against letting Composer reach 1.0, due to the radical changes that they made in 0.16, such days before the vote. I didn't feel it was "1.0", and that project came straight from IBM itself. To me, it didn't feel ready, and only months later other agreed with my vote (not without giving me a lot of grief until they changed their minds). BTW, I still think that Composer is a nice development tool and it helped us to explain visually what's a distributed system or a ledger to hundreds if not thousands of newcomers, but it wasn't ready at the time.


To summarize, while putting down my request for clarification in writing, I have semi-formed an opinion:

Sounds like having a clear criteria from the TSC and evaluating whether Iroha meets it, will be the most simple, fair and straight-forward way to go. "Active" or back to "Incubation", please all keep in mind that not too far down the line, the TSC will need to use the same criteria for Grid and other projects. 

Comments, questions, poisoned arrows welcome ;-)



Jonathan Levi

     To Blockchain with Confidence

On Sat, Mar 16, 2019, 5:50 PM Vipin Bharathan <vipinsun@...> wrote:
Iroha is already active. So the only question before the TSC is whether they can go to 1.0 at this point. Seems like the answer is yes based on the exchanges that I have seen.

On Mar 16, 2019, at 5:42 AM, Baohua Yang <yangbaohua@...> wrote:

I tend to feel that we may use version number only to measure code maturity, while using status to measure project itself, which certainly includes code maturity and more metrics.

Hence how about we give the active criteria as:

* released v1.0;
* have active commit activities;
* have good diversity in contributors.
* And more.

On Sat, Mar 16, 2019 at 11:16 AM Vipin Bharathan <vipinsun@...> wrote:
Hi all,

Ursa/Grid or any other project that becomes active or goes into 1.0 will have similar issues, if the rules are not clear/arbitrary. It behooves us to have more active full dlt projects in 1.0 status. Especially if the project is sound and has passed most of the criteria for maturity/security etc. If you listened to the Iroha peoples experience in the bootcamp; most participants in HK were not even aware of the existence of Iroha.

Many people when referring to Hyperledger actually mean Hyperledger Fabric; an impression that I have had to correct many times over. Not to take away from Fabric's popularity and adoption rates; I am a fan; but we all will (including Fabric) benefit if Iroha achieves 1.0 status. This means that the Hyperledger ecosystem is a level playing field and even small companies can make a difference.


On Fri, Mar 15, 2019 at 6:13 PM hmontgomery@... <hmontgomery@...> wrote:

Hi Everyone,


Sorry for causing controversy here.  I’ll attempt to clarify my points.


I understand Fabric-Java-SDK doesn’t function as a top-level project, and it is not being marketed as such.  But we approved it for incubation as its own (completely independent) project two and a half years ago.  If you go through the old TSC email archives, you can find where we did this (Ex.,,,20,0,0,0::relevance,,Fabric+java+sdk,20,2,0,17551816 is the first email when I search for Fabric-Java-SDK).


We had a discussion on tiers of projects (Ex.,,,20,0,0,0::relevance,,RFC+1149,20,2,0,17551967) but this eventually got shot down and we went with a flat project hierarchy.  So, formally speaking, we don’t have project tiers, and every project under incubation technically is a top-level project under our governance structure.  To my knowledge (please correct me if I’m wrong), we haven’t formally folded projects like the Fabric-Java-SDK into their “parent” projects, so I believe these are de jure top-level projects, even if they are not top-level in practice.


As Arnaud points out, this may be something we want to discuss going forward as the number of projects continues to proliferate. 


I hope this has explained the thought process from my previous email.  Sorry for the confusion, and I’d be happy to clarify further if necessary.





From: Arnaud Le Hors [mailto:lehors@...]
Sent: Friday, March 15, 2019 1:26 PM
To: Montgomery, Hart <hmontgomery@...>
Cc: Dave Huseby <dhuseby@...>; Mic Bowman <mic.bowman@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?


Wait, what?? The Fabric-Java-SDK is a top level project?? Where is this being said? It's not on

For what it's worth, the answer to your question is a big NO for me. Although I got slammed for saying it in the context of the proposal to what's now called Grid project I think we should have fewer top level projects and let platform specific projects live within the platform project they are tied to.
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM

From:        "hmontgomery@..." <hmontgomery@...>
To:        Dave Huseby <dhuseby@...>, Mic Bowman <mic.bowman@...>
Cc:        Hyperledger List <tsc@...>
Date:        03/15/2019 09:08 PM
Subject:        Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Sent by:        tsc@...

Hi Everyone,
A question:  do people outside of Hyperledger notice or care about the “active” vs “incubation” status?  I haven’t seen much press about this, and the writing I have seen typically gets it wrong and views active status as “production ready.”
Do we have more (non-marketing) resources for active projects (as compared to projects with incubation status)?  I’m not aware of any.
If we are going to measure project diversity, are we going to require (major) contributors to use their real names?  For instance, if we wanted to fast-track Ursa’s move to active status, we could have some of the core contributors make every Ursa commit with a new LF ID under a pseudonymous email.  Our contribution statistics would look fantastic, and we would have the added bonus of being able to completely derail the TSC elections (maybe we could run 6 winning candidates entirely on dunking booth platforms).  I realize this isn’t currently a problem, but it is probably something we should consider as we move forward.
In addition, if we are going to revise (and potentially roll back) the status of projects, then there are probably a bunch of things to look at.  For instance, at this point in time, do we think that the Fabric-Java-SDK should be its own incubated project?  This is obviously a useful and worthwhile coding effort, but by our “modern” standards, we never would have approved this as a top level project, and I suspect the new documentation will reflect this.
From: tsc@... [mailto:tsc@...] On Behalf Of Dave Huseby
Friday, March 15, 2019 12:37 PM
Mic Bowman <mic.bowman@...>
Hyperledger List <tsc@...>
Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

So to answer everybody's question about where the 1.0 criteria come from. It is a list that I have put together for the Grand Unified Theory of Project Readiness that I am putting together for the April 11th TSC call (see "future items"--formerly the "backlog"--in the TSC agenda doc).
I see 1.0 as purely a technical maturity measure. I see the "status" of a project as orthogonal to that. The reason I included documentation as a 1.0 criteria is because I don't see software as "ready for real work" if it isn't documented. From a purely technical standpoint, I have a rule: "all bugs live in the gap between the documentation and the implementation." It is impossible to know correct behavior from incorrect behavior if the correct behavior is undocumented. Shawn is right that the documentation also serves Hyperledger events as well. Documentation is dual purpose in this case and I'd still like to see it as a 1.0 criteria.
David Huseby
Security Maven, Hyperledger
The Linux Foundation

On Fri, Mar 15, 2019 at 11:26 AM Mic Bowman <mic.bowman@...> wrote:
Comments embedded below…
From:tsc@...[mailto:tsc@...] On Behalf Of Dave Huseby
Thursday, March 14, 2019 9:17 PM
Vipin Bharathan <vipinsun@...>; Hyperledger List <tsc@...>
Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

Here's my 2p on this:
I think the "status" of a project (e.g. "inactive", "incubation", "active", etc) is about the status of the community. A project in the incubation phase is one that has a small core of developers working on a minimum viable product. Typically this is a group of students at the same university or a group of employees at the same company. Moving from incubation to active happens when the project's community outgrows that initial core group and has enough critical mass that the original creators could leave the project and it would keep going.
The authorization to release a 1.0 major release is based on all of the technical aspects of the project. Off the top of my head, that list includes the CII badge, public code repo, public mailing list, some form of CI/CD, public bug tracker, public roadmap, an outside security audit, and some form of change management system (e.g. 2+2 reviews) full DCO compliance, training/educational materials for bootcamps and webinars as well as online documentation.
[Mic:] I like this list. Given that we don’t seem to have (or at least I cannot find it) a list of criteria for 1.0 release, would it make sense to start a “release criteria” doc we could use to focus the discussion? I’m happy to contribute/comment. We should also pull in some of our previous discussions on the topic.  Question: why is the 1.0 designation is important to Hyperledger TSC? My assumption is that we care because it reflects a commitment of resources for security analysis, marketing, etc and because it reflects on the “credibility” of the organization?
By applying these standards, I think the appropriate position for the Iroha project is to be in "incubation" but to approve a 1.0. I think Chris demonstrated that the contributions are still 99.9% Soramitsu. I would push back a little and also look for the stats over the last quarter and last two quarters as a more accurate measure of their community diversification. I agree with Chris that a plan is good but actually diversification should be demonstrated.
[Mic:] As Vipin suggested… it would be good to run the same queries over the other projects to get a baseline for what constitutes “normal” diversity in a community. Specifically… it would be interesting to compare overall contributor diversity, change in diversity post-1.0 release, and diversity over the last quarter (or some short, recent time period).
I also believe that the Iroha team has met all of the technical standards for a 1.0. The code base is solid and real projects are being built.
If we flag Iroha as in "incubation" while releasing a 1.0, not only will it more closely reflect reality, but it also mirrors the status of other Hyperledger projects such as Indy. Indy has been diversifying their contributor and maintainers considerably over the last few quarters and is about to move out of incubation even though Indy node is nearing its 2.0 release.
I disagree that it will harm Iroha diversification efforts to move back to "incubation" status. What is more important is to put out a solid 1.0 release and building relationships with people and organizations that can now take an enterprise-ready Iroha and build things with it. In many ways, I would expect that most projects will reach 1.0 before they have enough critical mass to move out of incubation. In fact, I think that the critical mass actually happens as a result of putting out a solid 1.0.
David Huseby
Security Maven, Hyperledger
The Linux Foundation

On Thu, Mar 14, 2019 at 10:41 AM hmontgomery@...<hmontgomery@...> wrote:
Hi Everyone,
Thanks for the suggestion Vipin.  Could we define more rigorous metrics for this (or at least suggestions, with perhaps some gray area)?
Putting on my Ursa hat, at some point in the hopefully not too distant future we’ll want to push forward with these things.  Having the knowledge of specific requirements (and whether we’ve met them or not, or whether it is borderline) would be immensely useful.  Putting on my TSC hat, I really want to avoid having to repeat this discussion again and again (a la the “improving the hackfests” discussions over the years), so coming up with something solid and writing it down is really appealing.
From: tsc@...[mailto:tsc@...] On Behalf Of Vipin Bharathan
Thursday, March 14, 2019 9:04 AM
Hyperledger List <
[Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

Hi all,
As suggested in today's tsc meeting I am raising the question Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Are numbers like the number of lines of code (or equivalent measures) from companies available at time of 1.0 (in active) available for other frameworks that already passed this milestone?
Another interesting statistic would be increase in contributor diversity SINCE 1.0.
Just to ensure that criteria are applied fairly for all projects in 1.0. And to see whether adoption is linked to 1.0 announcement.
Please put this on next week's agenda.
Also added as comment on the Agenda.

Best wishes!

Baohua Yang



You receive all messages sent to this group.

View/Reply Online (#2094) | Reply To Sender | Reply To Group | Mute This Topic | New Topic

Your Subscription | Contact Group Owner | Unsubscribe [vip@...]


Join to automatically receive all group messages.