I just want to echo what @tromer said. But also to point out that even an entire year’s worth of the funding requested in this grant constitutes a small percentage of a single month’s worth of the ZOMG share of the dev fund.
Having been through various grant proposal processes, I’m sympathetic to the frustration that comes with putting in a lot of work to demonstrate a PoC, then having a grant committee withhold funding. Normally this is understandable because the number of fundable proposals is much greater than the funds available. Here we are kind of in the opposite situation. It would be a catastrophe to lose one of the best wallets in the ecosystem over what is basically a rounding error in ZOMG’s budget.
I am not urging ZOMG to spend profligately. But I would love to see better security achieved more through overspending (eg more security reviews, redundant competing projects) rather than withholding funds from projects with a track record.
@Matthewdgreen — I agree, but think there’s a misunderstanding here and I just want to make sure we don’t solidify the misunderstanding.
ZOMG’s intent was to approve funding immediately for Zecwallet, at whatever level made sense, while we asked the applicant questions about two interconnected proposals that each have a lot of moving parts.
Our meetings are short, we want to give responses fast, and questions were coming up, so we needed more time to discuss, but wanted to ensure ongoing work was funded.
2 months seemed like more than enough time to sort out any questions and arrive at a longer term proposal, so I proposed 2 months, we decided on that, and we asked our questions.
I think Aditya read this as us rejecting the proposal or not wanting to support his work with long-term grants, but I’m not sure how this happened, since Sarah explicitly said we did want to make sure projects like Zecwallet were funded long-term.
Also, I think we all need to recognize that there are some big challenges inherent in communicating about sensitive topics (like beloved projects, funding, and livelihoods) via an asynchronous written medium, as an ad hoc committee of 5 people.
It’s really easy in written online communication to perceive conflicts or assume the worst of each other.
I think if these things were communicated in a phone call with the group, we would have caught this misunderstanding in the flow of conversation before it became anything. But it’s important that communication with grantees is clear and auditable by the community. And the forum seems like the best way to do that for now.
So I think we all need to take a deep breath and really try to understand each other.
@ZOMG This is a very important point that needs to be considered going forward. Zcash development interests are still small at this stage compared with other chains with dev funding that have expanded programs for community efforts, meetups, Dapp ideas and a wide range of active funding hand outs with an understandably low success rate for each project.
With Zcash, the Dev fund allowed us to have a solid dev fund to attract new developers and businesses to apply for grants. I like that we are being extra careful with spending the future of private money by being very questioning of every grant, but we need to be able to identify and do what is required to build a solid base.
Aditya made a very important point of the challenge+work required for attracting developers to contribute to work on the bleeding edge of cryptographic applications. I second that and I’ve found it very challenging to set up a roadmap and attract capable devs and paying them a fair share for their work. Additionally, once these projects are out there, they need funding to be maintained with the ever-changing supported platforms, additional QA testing, responding to issues on GitHub and social media accounts. I’ve had my fair share of dealing with this, and I believe there needs to be enough incentives provided to enable the growth of the ecosystem at this stage.
Going forward, please consider funding these large maintenance of widely used projects as Zcash is still small. We might be in a different place in a few years, but a lot of groundwork needs to be laid out till then.
Again, I’m really sorry that my proposal for 2 months of funding upset you and I hope you get that we want to support your work on Zecwallet long term.
My reading on this was different. Four minutes before posting in this topic, Aditya posted the following in the related proposal, in response to that proposal being put on hold:
Of course, without the Zecwallet Lite SDK, Zecwallet also cannot exist, so this decision also makes Zecwallet’s other proposal moot.
In comparison to the Zecwallet Lite SDK being put on hold, the 2 month thing seemed to be less of an issue. Of course, that was just my interpretation after having read both threads (which, side-note, is a considerable chunk of time for all of us–perhaps there is a better way??)
And @holmesworcester after re-reading my note I want to emphasize that I’m not pointing fingers. Rather I want to empower the ZOMG. More concretely, I want to make it clear that, from my perspective as a community member, you should feel free to put the spending pedal to the metal on things that are even arguably worth it. If spending gets super out of control, in a few months the community will let you know to rein it in. But right now just go, go, go.
I regret not posting earlier, as soon as I saw Aditya’s reply, I realized he misunderstood the “hold” part. I meant to say that ZOMG was expecting answers to the questions about navigating the duplicate infra efforts etc. It didn’t seem like they were rejecting the proposal.
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.
Hey folks! I haven’t even had time to read most of this thread yet, and since nobody from my organization is on ZOMG, the choices of ZOMG are not something I need to express my opinion about.
The only thing I do want to say is that ZecWallet is great!
I ZecWallet, and I will always be grateful to Aditya for selflessly contributing such a great contribution to the Zcash community.
I’m a pretty danged heavy user of crypto wallets! Not counting occasional experiments just to test out a new one, I actively use five different Zcash wallets every week, and one or two of them every single day, multiple times a day! And ZecWallet-lite is one of those two. It’s the most reliable one of the five that I use.
My ability to see and feel Zcash in action and to learn from using it every day would be greatly diminished if Aditya hadn’t come along years ago and decided to pick up the zcashd command line and start building a wallet on top of it. And then most importantly, decided to keep going and going, and diligently improving it and supporting it and sharing it for free to everyone in the Zcash community, including me.
I’d be irritated too, if I was in your shoes, but the fact is, the ZOMG is trying to prototype a new process. To attribute some kind of formalized intention to their requests, i.e. to “how the ZOMG wants to fund the Zcash ecosystem”, is a bit of a stretch wouldn’t you say?
I cannot imagine someone in this community simultaneously believing that the ZOMG is both “doing it’s job well”, and failing to fund zecwallet. To me those seem mutually exclusive.
Don’t get me wrong… I was the first person (If I Recall Correctly) to assert that the requests the ZOMG made were both poorly framed, and In My Humble Opinion counterproductive. <–(Meaning that they would lead to a needlessly inefficient process if adhered to.) If my memory serves there’s been personal friction between you and Sarah Jamie Lewis.
I believe you Aditya that, your model has been very effective so far (as far as I can tell), and I depend on your app for my daily financial transactions.
But, since we all know that the ZOMG’s process is nascent and evolving, let’s not pretend otherwise.
You mention that your own development process involves running many (sometimes costly) experiments. You say (and I completely agree with you) that that model is inconsistent with the proposed funding model the ZOMG offered. But don’t you think it’s a reasonable thing to allow the ZOMG to run some experiments, i.e. make some proposals, some of which fail? Or rather do you expect them to produce a perfect process without trial-and-error?
So… now you’ve got most of the community kow-towing to you… or would you like to frame this thread in a different way? Personally I think it’s an apt description of how our little band of ape-like creatures is responding to the posturing among the Top Apes. It is after all, what our brains are evolved to do.
More to the point, I am afraid. I am afraid that you, or Sarah Jamie Lewis (or some other Top Alpha Apes) will carry out the threats your posturing implies. As a hapless Lower Ape… I mostly just have to beg that you Toppers higher up the pyramid won’t trample the Little Users whilst engaging in your none-too-pretty petty power struggles.
If this is where it’s left, then… too bad for the Users.
I primarily use Zecwallet products as well and, personally, am also disappointed that Aditya did not accept the grant though I am very hopeful that a new proposal will be accepted and this can be reconciled and soon put behind us. Its been echoed by many here about the newness of the model and “ironing out the kinks” so I think saying that the ZOMG is incompatible with Zecwallet is, at least, premature. This is the brand new funding model we have committed to, deliberated on for months, voted on, and subsequently voted for the ZOMG chairs to handle it. While we may not agree with this particular decision, there is no evidence to support any kind of ill-will or that this decision was made purposefully erroneous, but, just the opposite. They defend their decision for proposing the 2 month grant as a means to request more evaluation time for finding a more suitable modeling (which itself implies the importance of Zecwallet) and I support this. Otherwise we’re asking them to make decisions they may not be comfortable with and, as the ones being assigned to create this new template for grant allocation, I believe it was not an unwise path to take.
Let’s not focus on ZOMG. Let’s get funding for Zecwallet. I think everyone supports it whether its ZOMG or ZF. It would be a huge blowback to Zcash if @adityapk00 does a rage quit. I certainly don’t want that to happen (and nobody does). We already have one rage quit in 2021. We had one last year (Josh C). I wish only one thing — choose mission over a conflict