Just after that term I provided an explicit example of work that was listed as part of the grant request which I would term at risk of unnecessary duplication across the ecosystem:
For example, you mention that " zcashd is officially only supported on Linux, so Zecwallet needs to build and test its own binaries for Windows and MacOS" - this is obviously work that doesn’t only apply to Zecwallet, and as such the ZOMG would like to understand what it would take to make these builds official so that all ecosystem projects can benefit from this work."
i.e. It makes very little sense for every single wallet team and other zcash integration to be building their own zcashd from source for common platforms like Windows and MaxOS every single month. If ZOMG is going to be funding things like that then we want to make sure that everyone can benefit from the work, and that the work is being done by the appropriate teams - so that the funding that we do dedicated to specific projects is focused on new features and improvements to that specific project and not on masking holes in other parts of the ecosystem.
Thats for the clarification, that does make it clear you are only specifically concerned with those issues.
It seems your objection isn’t to funding in general, just that some of it might be duplicated.
So maybe we can avoid this whole conflict by giving zec-wallet funding on a longer term basis for the non duplicate expenses (devs, some amount of hosting) and then ongoing funding for the other things until the time when they are no longer duplicated?
Also, @aditya I just wanted to say I feel really bad about this, and I’m sorry if you’re upset.
The “2 months” thing was my idea, since I thought you were feeling some urgency to get funded and get to work. I completely understand that it would be super disappointing and upsetting, given all the work you’ve done, to think ZOMG wasn’t going to support your work long term.
I’m really sorry it gave you this impression! That wasn’t at all my intent in suggesting the 2 months.
Again, and I know you know this, but partly for everyone else here, my project Zbay uses zecwallet’s SDK, so like all your many users here I’m a stakeholder in your work and want it to go really well.
Yes, this! The 2 months thing was my idea for buying us a little time to figure all of this out, without aditya having to shoulder these bills in the meantime for infrastructure he’s providing to everyone, or pause his ongoing work on Zecwallet.
This proposal has way more moving parts than the others we’ve discussed so far, and it combines a lot of different things into one proposal, and it’s right at the center of many users’ (and developers’) use of Zcash so all these details matter a lot.
But whether we do this bridge/short-term funding or not, we should be able to figure this out in the course of 1-2 meetings.
To chime in: I too think that Zecwallet is of paramount importance, to both Zcash users and developers. @adityapk00 wrote and maintains two out of the three usable GUI shielded wallets, and his is one of the very few projects that truly exercise and stress-test the Zcash protocol and codebase.
I’m glad that @adityapk00’s work is recognized by @ZOMG as crucial enough for immediate funding. I think it’s reasonable for the committee to sync up to learn more about the specifics before committing to long-term funding, in order for example to identify opportunities for pooling of efforts. That said, I hope the committee will recognize Aditya’s excellent discretion in the past in managing collaborations and facilitating code reuse, and thus will provide the requisite leeway, promptness and long-term stability.
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.