Retro Funding 4: Voting Experience

[alexcutlerdoteth]

Hey @Jonas -

I appreciate the response. Since it sounds like mostly you are suggesting you’ll (more or less) move ahead as planned, I wonder if you’d willing to address some of the other points and clarify some points in your post before I respond further? Some specific follow-ups below.

I don’t think you addressed this example directly, so I’d like to understand your take on the implications of facilitating the rewarding Project A over Project B? What sort of distribution of rewards relative to impact do you expect to see and why is this more optimal to simply not adding the filter and multiplier and letting Badgeholders choose? If you were a developer focused on making as much as you could with the least amount of effort, would you build Project A or Project B?

@alexcutlerdoteth

OS status alone is a flawed proxy for greater impact

It is tempting to enable a single filter for what appears on the surface to many Badgeholders—many of whom aren’t familiar with the nuances of different licensing practices—to be unequivocally a desirable things. But in making a design choice to allow voters a one-click exclusion or 5x boost exclusively for OS—and ignore other important characteristics, such as VC funding or open tokenomics—the Collective seems to be implying that 100% OSS is necessarily more impactful than even 99.99% OSS, which is, frankly, indefensible.

Let’s look at a hypothetical example:

• Project A: Straight fork of OS code from Pancakeswap with $1M in TVL
• Project B: Sroject combining 90% OS code and 10% non with $700M in TVL

Under the current proposal, we are suggesting that we should empower Badgeholders to fully exclude Project B to the benefit of Project A, even if an impact measure of Project B is 700x. There is no additional positive externalities created by privileging Project A over Project B. A copy-paste of an existing codebase doesn’t result in larger downstream impact by virtue of it being OS. There is no reason why the impact of Project A should be rewarded over the impact of Project B.

And, more crucially, enabling this filter means that Badgeholders will never even have the opportunity to observe the enormous disparity in outcomes between the two. There is no way for them to see that there is currently a far more impactful alternative to what they see on the market. They merely shift the weight of the rewards from higher impact to lower impact.

OSS can create powerful network effects, but it does not always do so in every vertical. And creating binary filters just incentivizes “spray and pray” forking of existing OS software—not innovation or impact—which can have obvious adverse ecosystem consequences extending well beyond a simple misallocation of resources.

I’d also be interested in your perspective on other dimensions of the open vs closed as the Collective Values you cite do not seem to just be singling out OSS and thus I’m curious why you’d prioritize build tooling to enable the filtering based on one dimension of openness while ignoring others? Are there other features that have been requested by Badgeholders or ecosystems builders are not being incorporated into this round? Has the survey data been made public so we can see how it was constructed? Did you also survey application layer builders?

@alexcutlerdoteth

This prioritizes one dimension of a project’s status as a public good, while ignoring others

Creating a filter that allows for the privileging of impact of one kind of project over another is valid, but focusing it exclusively on the usage rights of code is arbitrary and myopic. Open versus closed is bigger than just whether or not there is a line of code that requires permission to reuse. Projects can be open-source while building eight-figure war chests from private interests. These private interests do not do it out of the goodness of their own hearts, but because they believe that have ways other than code usage to privately extract value from the project or protocol.

Open token distributions and value accrual mechanisms are just as important in creating positive network effects as open sourcing code but are completely ignored here. No multipliers, no filters exist for other dimensions of openness. Instead, developers are asked that every single line of code they developed can be used freely by every VC who could dedicate millions of dollars to undercutting and destroying their projects while ensuring they get a larger slice of the pie.

Surely, this is not what Retro Funding is designed to do.

Can you address specifically how you intend to address the ways in which this process could easily gamed such as?

• Submitting a repo that doesn’t contain all of the code on which a projects depends
• Submitting a repo that points to OS contracts, but those contracts rely on proxy contracts that are not public, unverified, upgradable, and/or ever changing

@alexcutlerdoteth

The proposed implementation misses the mark and will cause confusion

The lack of detail on how specifically this will be implemented is a major cause for concern here, as it will likely allow for proposals to be miscategorized at the voting level and once votes are cast there will be no way to retroactively to reweight or fix anything.

A review of many of the top prior recipients indicates they have no licenses in place in their repos; are we asking every project applying to Retro Funding to engage lawyers to draw these things up to avoid being filtered? Even the code used to identify which project is OSS is closed source (no license). The Optimism dev console is recommending a bunch of projects that are not open source, in that there’s no code publicly available, but claim to be under an OSI license. Plenty of projects could appear to be OS via their repos but use private proxy or unverified contracts in their actual implementation; there will in effect be no viable way to systematically verify things. Bad actors will game it, and well-meaning badgeholders will never look into it. Once again, impact will be diluted.

A few other points to clarify from your post:

@Jonas

As the post flags, this is something we’d love to iterate on in the future, to get to a more granular method of allowing badgeholders to reward open source work. In its current form, it’s not practical to make claims on the “open source percentage of a project”, as this requires to judge the importance of each piece of code of a project.

If a more robust solution is not currently practical currently, what is rationale in shipping this now knowing the potential for penalizing high impact projects that are even 99% OS or don’t have the means to engage the legal resources required to add a license ahead of the round? What does the collective gain by doing this and what are the risks in your eyes? If we again see high impact projects going unrewarded, how long would it be before there was another round focused on onchain builders that would include any iterations?

@Jonas

As we’re implementing this as a multiplier, this means that using an open source license in isolation is not rewarded, but that instead badgeholders can add this as an additional consideration to reward impact.

So are you implementing it as a filter or multiplier or both? How is the net effect of this not rewarding an open source license in isolation if in effect a reward for OS in isolation? Can you give some examples of how this would affect the distribution in practice? Also, have you modeled out the multiplier to support that? How did you arrive on the multiplier range you’ll allow?

@Jonas

In our user testing, we have received strong feedback from badgeholders that they want this functionality.

Can you tell me what % of Badgeholders are currently application layer builders building on OP Stack chains? Only ~50 out of 130 voters even cast ballots for leading Optimism protocols last round, so I’m curious how many are steeped in the challenges and nuances of this issue? Did you consider increasing builder representation prior this round?

@Jonas

In Retro Funding 4, for a project to be considered open source, only the repo which contains their contract code needs to be under an open source license,

Why specifically is contract code being specified here and no other kind IP is being subjected to the same requirement? The Collective Values are no specific here so why are we being specific? Was this distinction documented prior to pointing out the specs repo or is this a new qualifier only after my post pointing out the incurrence?

@Jonas

Allowing badgeholders to reward the use of open source licenses also does not imply that the Optimism Foundation or OP Labs team requires all partners that it references, or uses to build products, to be open source.

Is there a distinction between “allowing badgeholders” and “enabling badgeholders” that you acknowledge here? How would one not allow them to do so?

@Jonas

An export from the previous retro round shows that most projects have a license on their contract repo, we will run this query again and report back!

Can you break this out in more detail? What % have one and what % don’t? And what type?

@Jonas

The OP Stack is MIT licensed and has a large number of forks.

Can you share at what point the OP Stack and any other OP Labs smart contracts became fully opensource and what other liscence types were used prior to their being fully open sourced and why those decisions were made?

Can you detail any other cases where OP IP is not fully open sourced and the liscence types used and the rationale?

@Jonas

The “Open Source license of contract code” has been shared as one of the areas of impact that will be rewarded from the very beginning in the Retro Funding 4 announcement . This was not a rushed decision.

Are there any other areas of impact that can be filtered or multiplied by the voting tool? If not, why not? Are some values more important than others?