IMHO:
ZF and MGRC work together to create network effects among third party developers and end users, respectively. This can be seen in active userbase + functional codebase.
Unlike MGRC, ZF enables grants that work inside the protocol. MGRC should not make protocol level change.
Responsibilities :
Red = ECC (for-profit, created privacy protocol)
Yellow = ZF (non-profit, maintains protocol for public good)
Blue = MGRC (creates useful applications to grow community)
Areas of Operation :
I (+ IV) = ECC
II (+ III) = ZF
IV (+ III) = MGRC
Zeal :
A = developers
B = users
Areas of overlap present opportunities to create checks and balances and further decentralize the Zcash Network Flywheel. See Part 4 of my agenda: Trust Badges.
The MGRC Engine
I added an arrow to Ali’s representation of Network Flywheel to reveal the MGRC Engine that fuels the Zcash Network Flywheel:
- ZCAP select MGRC candidates
- MGRC candidates inspire useful applications with help from the community.
- Useful applications attract more Zcash users (and leave code for more developers to adopt)
- A growing Zcash userbase begets a larger Zcash community (network effect).
Further discussion: https://hackmd.io/@jmsjsph/4MGRC#The-Zcash-Network-Flywheel
More so than marketing, I’d like to set up a two-way communication system with the community, gain their consent, hold their hand, walk them into the zecosystem, and see how long they stay.
This requires user research, one of the four pillars I propose
@lawzec, did you notice any conflict with ZIP1014?