Thanks for the comment!

Can you elaborate on what you think is necessary for the BIF to be ready to become an incubated project, or why the BIF is not ready?  Currently there aren't really any guidelines for what projects need to become an incubated project other than what is stated in the project proposal document, which is relatively minimal.  We don't want to waste both our time and the TSC's time if there are unwritten readiness guidelines of which we aren't aware that haven't been met, but it's difficult for us to make a decision based on information we don't know.  So, would you mind outlining some principles for us?  This would be useful to not only us but to any other people coming along looking for project incubation status.

For the record, most of the projects that have been approved for incubation status in the recent past have not been feature-complete (Besu was obviously a notable exception).  Here are some examples that we used for precedent:

Transact proposal:  

Avalon proposal:  Hyperledger Avalon Proposal

Aries proposal:  Hyperledger Aries Proposal

Historically, the judgement for project incubation status has been based on whether there is an appropriate community in place to start a successful project rather than a metric on how close the codebase is to production readiness.  We actually do have TWO production-ready blockchain integration/interoperability solutions (from Fujitsu and Accenture), so we feel that our team is up to the challenge and meets this metric of "community in place."  However, if you (and others on the TSC) feel this is no longer the correct metric, we'd love to hear your thoughts.

In addition, since we have had a number of proposals recently where the proposers thought they were ready but where at least some of the TSC disagreed, it might be time for a task force to write up a more detailed document detailing criteria for achieving project incubation status.  Otherwise there will probably be a lot of continued frustration on all sides.

To further elaborate:  our motivation for "getting attention" was to make sure that others in Hyperledger weren't working on a blockchain interoperability solution that would substantially overlap with ours, and if they were, that we could collaborate in the future.  We don't want to increase fragmentation.  If there were other solutions out there, we wanted to make sure we could architect in a way that made future collaboration easy. 

That being said, we think our current community and contributor base is more than enough to successfully build a production-grade BIF.  As we mentioned before, we already have 2 different interoperability solutions (one from Accenture, one from Fujitsu) that are being used in the wild.  So this really isn't a chicken and egg problem for us of getting more contributors, it's more of a "speak now or forever hold your peace."

So, in summary, our purpose in this was not to gain new contributors (although we would welcome them).  We recognize that most of the development work done in Hyperledger is company-based and recruiting true independent contributors through interest in a project is very rare.  Instead, we wanted to make the company-based developers aware of our solution and give the big business folks a chance to look through our architecture before we committed to something that would be difficult to move away from.  We're already working on a large codebase refactoring to merge the Accenture and Fujitsu solutions, and we don't want to have to do another one if another big contributor (most likely in the form of a company dev team) comes along in the future.

Does this clarify things?  Sorry if it wasn't clear from the proposal document.

Hi Haissam - it might not be clear, but the BIF project graduated out of Labs and became the Cactus project - see https://wiki.hyperledger.org/display/cactus They are meeting regularly and have early code out. I suggest you look there and follow up with the Cactus developers on your question.