In my opinion, the first two tasks (“Depend directly on ECC’s librustzcash” and “LightwalletD compatibility”) are very clearly worthy of doing and funding. They are about reducing duplicated effort, resolving incompatibilities between forked codebases, and improving interoperability between two already-deployed, in-use software products. If the choice is between (a) keeping the incompatible forks, (b) killing one of the products, or (c) harmonizing the codebases, then (c) is obviously the best, and it’s what @adityapk00 is proposing.
Regarding “Security Review of the Zecwallet Lite SDK”, there’s much to say about the desired scope of full security reviews and improvements, but starting anywhere is a good start. That said, I’d love to see a long-term plan drawn by @adityapk00 about future planned security reviews and improvements. Both for perspective, and to see where the currently proposed work fits in.
I’m a bit fuzzy on where ECC’s code ends and Aditya’s SDK starts (after the first two harmonization tasks), and thus on the extent of overlap between the two SDKs. Aditya, can you clarify this? But regardless of the precise split, I see nothing wrong with having multiple high-level SDKs that are compatible in their communication protocols. It’s perfectly fine for different app developers to have different needs or tastes, and a plurality of (interoperable) SDKs is healthy for the ecosystem as well as for exercising and stress-testing the underlying libraries and protocols.
Well-thought-out redundancy may be a luxury we’d forego if we were cash-strapped and barely able to get one SDK going; but our situation is the opposite: we need to encourage a vibrant developer ecosystem and multiple independent implementations, and the Dev Fund lets us afford this. As @Matthewdgreen put it: ZOMG Spending: go, go, go!