Decentralizing the Dev Fee

@mhluongo, thanks for your replies! Some further comments:

So the Foundation is at liberty to continue in-house development, it just won’t be allowed to use the Dev Fund to pay for it?

To be clear, the capabilities go unfunded by default – the founder’s reward expires, and there is no replacement

We agree, the default would be to defund and thereby destroy (even more of) the existing development capabilities. That’s bad and is why we’re even discussing a new Dev Fund. My point is that your proposal would cause much of the same harm.

I see preservation of existing capabilities as a crucial consideration, given the difficulty and uncertainty of rebuilding them anew. So proposals that would preserve existing capabilities are IMO vastly preferable.

I’m intentionally holding off my own development proposals for a little while so we can discuss the merits of this structure – I figure this proposal shouldn’t be primarily about me or my team, and I’d rather not get into a situation where we’re designing for our needs versus the ECC or similar 0-sum thinking. I’d rather get this governance piece right.

I see your reasoning. However, for me it’s hard to speak of governance/funding in idealized hypothetical, without a solid grasp of the concrete issues that this governance/funding would resolve. Concretely, we would be trading off the loss of existing capabilities for… what? Are there enough projects and teams waiting in the wings to productively consume 75% or more of the Dev Fund, with better results than the existing teams? Or conversely, perhaps those hypothetical projects would actually fit nicely, in scope and nature, into the Foundation’s current granting system?

2 Likes