First off, I’d like to say that I understand that the committee is doing a difficult job with unusual constraints in a brand new area, so I appreciate and respect the work that everyone on the committee is doing. It can’t be easy, and I want to sincerely thank all of you.
I wanted to write this post in the spirit of “Agreeing to Disagree” and explain the perspective of an App developer on Zcash. There is some notion on the forum that I misunderstood the committee’s position or that there’s been miscommunication, but I don’t think that’s the case here. (And @holmesworcester / @Shawn there is absolutely no need to apologize - You guys are awesome and the communication from the ZOMG was clear)
From my perspective, this is the entire point of Zecwallet. An independent, community-owned, third party implementation of a lite wallet, which is the primary way most people will interact with the Zcash ecosystem. It’s why Zecwallet exists.
I understand and appreciate that the committee wants to be cautious and judicious in granting funds, making sure that the eco system grants are used efficiently, that there is a high level of co-ordination among grantees and there is that little (or none) duplication of effort. This is a perfectly valid position.
However, Zecwallet was built differently. It was built from the product philosophy that grantees should optimize for usefulness and utility. That is, grant recipients take product risks, iterate quickly on several ideas, and bear the cost of inefficiencies and duplicated effort in an attempt to discover what works, what kinds of wallets/apps/usecases Zcash users value and figure out what will get people to use and care about ZEC. And when some ideas/techniques/code proves itself out in the real world, grantees will come back and submit it upstream, so that Zcash as a whole makes progress.
For example, when Zecwallet Lite was being built, it was not clear whether t-address support was important. Instead of trying to figure out the answers via form posts and polls, Zecwallet implemented t-address support in Zecwallet and shipped it, allowing users to “vote” by using or not using the feature. Turns out, t-address support in light client is important, at least right now, so this worked out, and I ended up submitting some PRs to the upstream librustzcash.
Some ideas don’t work - I thought users care about having multiple z addresses, so I added support for multiple addresses in Zecwallet. Turns out users don’t care, so I ended up removing it from the mobile wallets.
One way to look at this is that all this effort was wasted, and it was obvious that users don’t care about multiple z addresses, and that Zecwallet wasted ~$10,000 implementing this feature. Another way to look at it was that it was worth spending the money to discover what users care about, and double down on the features that users do care about. Both viewpoints are perfectly valid.
I know it seems like I’m defending waste and duplication, and I guess I am. My product world-view depends on it, and I think Zecwallet has achieved some success in the Zcash ecosystem because of this approach. Build fast, iterate, double down on things that work, fix things that don’t. Accept some costs of duplication, rework and inefficiencies, as long as the overall product continuously improves.
I also understand that this is probably NOT what the committee wants, and values efficient use of funds and de-duplication higher. I also understand that this means the ZOMG probably wasn’t going to fund Zecwallet, and that’s OK.
This is another area where I would respectfully disagree. Again, I understand this is important to the committee and I’m probably in the wrong here, but I don’t want to submit Zecwallets server expense receipts to the committee for approval.
Zecwallet was and remains a fluid project, experimenting with a bunch of different ideas to see what works. Having to seek the committee’s approval for infrastructure and architecture decisions will dramatically slow down Zecwallet, and Zecwallet was not built for that. Now I understand there are 100s of successful open source projects that work fine with this model, but I think Zecwallet cannot work with this model. It’s important for Zecwallet to have the freedom to make infrastructure and architecture decisions quickly and locally.
I will readily admit that my expertise is in writing code and building products and I’m terrible at writing grant applications and forum posts (hence this wall of text 
), explaining infrastructure & architectural decisions and getting buy-in & approval from an overseeing committee.
As an example, Zecwallet built and shipped the entire lite client - The light wallet SDK, CLI and desktop apps, the caching lightwalletD server and t-address support - all in 10 weeks, because the Zcash Foundation was generous enough to let me have full control over the product, architecture and infrastructure decisions. However, if I had to write proposals, convince the committee of major infrastructure and architecture decisions and to seek approval with a 2-week turnaround time, I don’t think it would have worked.
Again, I realize this sounds like a #HumbleBrag, but I want to be clear that it couldn’t have worked for me and Zecwallet. I’m sure there are several other experienced developers who are well versed with how Open Source operates that could have matched and even exceeded Zecwallet’s timeline. I’m just saying Zecwallet (which is my first open source project) was not built for that and cannot operate under the model.
I also recognize that this is primarily my fault. That I was probably naive, and didn’t understand what the ZOMG was looking for. For that, I apologize.
I think the ZOMG has done it’s job well, but I can’t help but think Zecwallet is incompatible with how the ZOMG wants to fund the Zcash ecosystem.