Retro Funding 4: Voting Experience

Hey @alexcutlerdoteth! Appreciate your thoughts and feedback on this. Below is a response to some of your points

We fully heard your feedback on the lack of rewards for onchain builders in Retroactive Public Goods Funding 3. The feedback you and others provided heavily informed the design of Retro Funding 4.

The distinction between open source and a mixture of open and closed source licenses

It is suggested that there are should be no distinctions to be made between a 90% OS project and a 100% OS project

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. As flagged in the post, we’re very open to suggestions for how this could be achieved!

no distinctions to be made between the multitude of different types of licenses and their purposes, that simply if a builder is asking for permission for reusing any portion of their work, their impact may be systematically ignored - and that some builder who forked OS portions of their code should rewarded at 5x the value. This is frankly shocking and runs against the purpose of Retro Funding.

The definition of the Open Source Initiative is applied to classify licenses as open source. While this can be a controversial topic, the Open Source Initative’s classification is the most widely accepted and used framework.

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.

Allowing badgeholders to make informed decisions

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.

In our user testing, we have received strong feedback from badgeholders that they want this functionality. This functionality allows individual Badgeholders to express an important element of how they’ve previously rewarded impact. Each Badgeholders retains the agency not to use this option, and as described below, we’ve taken efforts to ensure they understand the implications of choosing this option.

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.

Fully understand the concern that badgeholders are not able to understand the implications of their choice, to mitigate that we’ve implemented some features to enable badgeholders to understand how their choices impact the allocation of OP among projects. Badgeholders are shown a table and graph with their OP allocation, which is based on the impact metrics they weighted and the open source multiplier. Within the table badgeholders can see the resulting allocation of OP to each project, filter based on the performance against specific impact metrics and the open source multipler and discover which projects are labeled as open source.
When badgeholders use the multiplier, they will see how the table and graph is updated to reflect that (see screenshot below). In addition, they’re able to filter the table to only show none open source projects.

On the advantages and drawbacks of Open Source

Building Open Source is one of the Collective values, which have been shaped by both Citizens’ House as well as Token House members. The Optimism Collective believes that building open source gives rise to rapid innovation, permissionless experimentation and open knowledge sharing. It is core to combatting the centralization of power and lowering the barriers to entry for builders within the Collective. This leads to increased competition, higher quality products for users and less value extraction. One of Retro Funding’s core goals is to reward open source contributions which benefit the Collective.

The notion that having even a single repository with some sort of license is enough to label the entire project closed-source is a bar that not even Optimism would clear.

The OP Stack is MIT licensed and has a large number of forks. The Optimism specs repo, which outlines the specs of the OP Stack, is currently under a Creative Commons 1.0 Universal license, which is not considered as open source by the Open Source Initiative, but is a public domain dedication which allows anyone to build upon, modify, incorporate in other works, reuse and redistribute.
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, not all repos which the organization owns need to fulfil that requirement. Thus, the OP Stack would pass the test.

Regarding concerns on the missing license on the OP-Atlas repo, we’re in the process of building this (you can see that the repo is only a few weeks old). We’ll add an open source license to it shortly.

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.

Thoughtful implementation

The team has invested lots of time into getting this feature to a state in which we feel confident. It’s been included in the spec for the voting experience from the very beginning.
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.

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?

Within the sign up experience, we’ve added a disclaimer to projects that they should attach a license to be classified as open source. 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!

Open source is important to the achievement of Ether’s Phoenix. Badgeholders have previously expressed a strong desire to reward open source projects and so we’ve thoughtfully, albeit imperfectly, designed an option that allows them to express this preference. Just as it’s important that Badgeholders be empowered to make their own decisions, it’s important that they understand the implications of the decisions they make. Inspired by this feedback we’ll take the following actions:

  1. Take special care to ensure that badgeholders understand the implications of using the open source multiplier and add a disclaimer on this to the feature.
  2. Dive deeper into the data to understand how many repos are missing licenses, who would be affected etc.
  3. During the curation of metrics, badgeholders will be asked to signal if they want this feature.
3 Likes