What if we merge existing non-profit organizations & also create new kind of on-chain organization, that funds devs in ZEC. (So, Zcash Bootstrap — US non-profit + Zcash DAO — can be registered with Wyoming & become legal DAO in US) . This way if there is an attack on Zcash in US, there will be one organization (Zcash DAO) left to continue Zcash mission. Zcash devs can be directly funded via DAO if there is ever an attack.
ZF & ECC existence means each one will keep the other one in check but I feel it is not necessary for success of Zcash. Whatever ZF and ECC individually does, can be done faster with single centralized entity. There are definitely some things that are redundant amongst two organizations. Internal conflicts are faster to resolve, there is clear decision maker for each issue. No reason to communicate every single issue with community. New decentralized entity (DAO?) will ensure any dev in the world can contribute to Zcash & earn ZEC.
If anyone is interested in being part of Zcash DAO please DM me on forums. I hope to see leaders showing interest in funding Zcash goods. I have a few candidates in mind.
Zcash DAO — we are in 2021 & this is the way to run organizations. So a committee to research & come up with best setup is needed (I know there are few candidates already started looking into this on forums).
I was told that due to a previous SEC battle, the word DAO is now a legal red flag. It’s advisable to call it anything else. I’ve been referring to “outposts”: decentralized stores of value for Zcash operations and governance. Summer homes?
This is one area of concern. Another is understanding token issuance, how to mitigate Sybil attacks, and ensuring that cooperating malicious actors do not have a majority of voting control.
has this been considered again? not exactly the DAO part but merging ECC and ZF into 1 org.
having 2 orgs might have made sense back in the day, but at current time imo it could be changed.
also since most will work on Zebra instead of Zcashd it would make more sense to have the teams even more under same management etc.
it would be more efficient and less management costs and also funds to run 1 org merged would make it more efficient. right?
also less drama and arguing about stuff that slows development down probably?
would it be centralizing? core development in a way, but actually not. most devs and things would stay same imo.
other orgs like quedit etc could still develop for Zcash and that would be where decentralization would come in more.
Back then you had one for-profit (Zcash Co.) and after 2017 also non-profit Zcash Foundation… now we have two non-profits. It doesn’t make much sense to have both non-profit Bootstrap (fully owning ECC) and non-profit ZF, the people have to cooperate anyway.
More lean orgs are more effective and money can be saved on running these orgs.
It’s like if Ethereum had Ethereum Foundation and also ConsenSys as official companies, which is not true. ConsenSys is a for-profit spin-off by Joseph Lubin, but it’s never seen as official ethereum’s for-profit company.
In my opinion, the two organisations are very different in terms of leadership culture and strategy. One example is how our boards are constituted. The majority of ZF’s board is appointed based on input from the community. That is not the case with Bootstrap’s board.
Those two examples are emblematic of key differences between the two organisations that permeate the entire culture. I think it would be interesting (in the “May you live in interesting times” sense of the word) to try to merge those two cultures.
That would certainly make sense for the core engineering function. Just having the same engineering priorities would be a huge step forward.
And I mean huge.
Yes.
It would be centralizing unless executive authority over things like priorities were devolved in some way. We (ZF) took a small step in that direction with the priorities poll back in August 2021, which has influenced our priorities ever since.
In theory that’s correct but there’s a risk that whoever leads a merged Bootstrap/ZF organisation could effectively prevent an organisation like QEDIT from deploying a feature that they don’t like, even if the community is strongly supportive of it.
For example, they could prohibit the B/ZF engineers from supporting the work directly (e.g. reviewing PRs) and drag their heels on resolving deployment blockers (e.g. deprecating zcashd) by prioritizing other work.
However, if there was a commitment to soliciting (and respecting) the community’s input when setting priorities, that wouldn’t necessarily be an issue but, like I said, it would require a change in culture.
