Modularizing the Program

[owocki]

@connor

I still think there’s a lot of overlap between the 3 core rounds.

IIRC we agreed to stop calling them core rounds and instead decided to call them program rounds, no?

@connor

I’ve seen you say this in a few places now - I would not be surprised at all if it’s true, but I’m curious as to how you’re coming to that conclusion / what data you’re looking at

This is admittedly a hard to quantify exercise, but where’s where I’d start: Look at the impression counts of the tweets complaining about us, the news coverage of it, the decrease in donations to the matching pools in the last couple rounds, and the drop in Gitcoin’s treasury value during the controversies.

@connor

We do already do this (although they do share a multisig, funds are earmarked for specific rounds)

So people have to trust that someone is tracking it correctly? Socialware only goes so far (especially when there is poor or opaque record keeping) Seems like a more trustware based approached where one could see on chain the funds going to the correct places is more inline with ecosystem values.

@connor

I am open to experimenting and agree we really need to avoid or at least minimize the polarizing controversies of prior rounds going forward

@connor

I don’t really see the need to brand each one uniquely

I think the controversies are inevitable, as the world is polarized and public goods are relative to the communities they serve. Just like an experienced skiier doesnt focus so much on not falling, but on bouncing back after a fall… We should focus on bouncing back from the controversies when they happen, and on limiting damage to the main brand. Modularizing the ecosystem and building up subbrands accomplishes this bc it educates the community on the diff between the credibly neutral protocols, gitcoin (which is an ecosystem now), and the opinionated programs that occur within/around that ecosystem.

@connor

Having 3 unique teams doing the same work but in a silo could end up redundant and a waste of resources

I don’t think this is proposed anywhere in my OP.

@connor

Does each round’s team need to hire their own marketing team, designers, and support personnel?

IMO this line of questioning just shows how bloated Gitcoin workstreams have gotten. We’re just assuming giant monolithic teams, and that it should cost $1m in net-new staffing to run a round, when it’s just not true. You can run a team self-service for 10x, 100x, or 1000x less. We’ve invested tens of millions of $$ in making a product that can be more self-service and less resource intensive, let’s start adopting that mindset.

Yes, the program contains major rounds, and bc each is larger than the median round, it will cost more than the median round. So to directly answer your question, each program can rely on shared resources. The point of Unix-philosophy style modularity is that each team does one thing and does it well, and is made to be interoperable with other teams… To say that teams work in silos just bc they have seperate brands is to misinterpret modularity.

@connor

2. start to build aqueducts of long term sustainable funding into specific pools.

We do already *try to do this, when there is demand

Given protocol guild’s ability to raise tens of millions of $$$ for eth infra public goods funding, I think there is clearly demand here. I’m happy for protocol guild’s impact on eth core infra, but I’m saddened that it seems to me that our offering is not as competitive anymore.