Profile of alexcutlerdoteth in Optimism
Posts by alexcutlerdoteth
-
Code of Conduct Council Communication Thread
by alexcutlerdoteth - No Role
Posted on: May 21, 2024, 6:43 p.m.
Content: It was not received. I just sent a follow up via email.
Likes: 0
Replies: 0
No likes yet.
No replies yet.
-
Retro Funding 4: Voting Experience
by alexcutlerdoteth - No Role
Posted on: May 19, 2024, 11:57 a.m.
Content: Attempted to better distill some thoughts here: x.com 9
Likes: 1
Replies: 0
No replies yet.
-
Retro Funding 4: Voting Experience
by alexcutlerdoteth - No Role
Posted on: May 19, 2024, 11:57 a.m.
Content: Attempted to better distill some thoughts here: x.com
Likes: 1
Replies: 0
No replies yet.
-
Retro Funding 4: Voting Experience
by alexcutlerdoteth - No Role
Posted on: May 15, 2024, 5:16 p.m.
Content: 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 5 x 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 $ 1 M in TVL
Project B: Sroject combining 90 % OS code and 10 % non with $ 700 M 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 700 x. 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?
Likes: 4
Replies: 0
No replies yet.
-
Code of Conduct Council Communication Thread
by alexcutlerdoteth - No Role
Posted on: May 15, 2024, 11:51 a.m.
Content: Are you guys planning on bringing any final resolution to the NFTEarth matter?
They are still trying to extract value, even after shuttering the project on 24 h vote that included just a single voter 1 . Being able to point to this committees conclusions would help prevent further damage.
https://commonwealth.im/layerzero/discussion/ 17264 -nftearth-rfp
Likes: 0
Replies: 0
No likes yet.
No replies yet.
-
Retro Funding 4: Voting Experience
by alexcutlerdoteth - No Role
Posted on: May 14, 2024, 1:50 p.m.
Content: Summary
Retro Funding has the potential to be highly impactful to the growth of the Superchain, but to date it doesn’t have as much mindshare as it rightly should amongst application layer builders due to sub-optimal distributions in previous rounds that uniquely impacted the largest drivers of demand for blockspace. While this new round of Retro Funding made some promising changes, I am very concerned about some of the suggestions made above.
At issue is adding an overly-simplistic binary choice for Badgeholders to penalize projects that have even one line of code contained within them that requires some sort of permission to reuse. This choice may seem intuitive, but delves into an incredibly complex area that deserves careful consideration not a rushed last-minute addition under an imprecise classification methodology. If not done right, we risk repeating the mistakes of past rounds and under rewarding the impact we desperately need once again.
Retro Funding (formerly Retroactive Public Goods Funding) is core to Optimism’s Economics. It is designed to fuel a flywheel effect whereby builders/users create demand for block space, that demand drives sequencer revenues, those revenues are shared as rewards to those creating the most impact, which incentivizes more impact, more demand, more rewards, etc etc.
Screenshot% 202024 - 05 - 13 % 20 at% 201 . 27 . 58 %E 2 % 80 %AFPM 1450 × 906 84 . 7 KB
To distill this down, on Optimism, “impact = profit” or, in a more focused setting, “Build on Base”, be Rewarded”. A clear value prop to attract world-class builders to the Superchain. No qualifiers, no asterisks; just build impactful stuff here, and you’ll be rewarded. Simple and effective.
“Retro Funding is not merely a charitable endeavor; it’s building an impact system where contributions are valued and rewarded.” - RetroFunding Announcement
The two biggest issues with Retro Funding to date are:
We need orders of magnitude more demand for blockspace as the program is not even close to being sustainable on sequencer revenues alone
Projects creating the most demand for blockspace have been dramatically under rewarded proportional to their impact due to design decisions made in previous rounds
So far, for the most impactful onchain builders, the type we most need to attract and support for Retro Funding to be successful, impact ≠ profit.
Last round, just 5 % of the rewards in the went to the top 20 % of projects in terms of sequencer fee generation. Straight forks of OS codebases were rewarded at rates comparable to projects with 100 x their impact. The message to builders was this: the fastest path to reward is not impact but simply deploying forked OS code. Individuals could make more by launching simple forks or participating in governance than contributing to the most impactful and innovative projects.
This has created a flywheel working against the intention, as reflected in the fact that OP Mainnet’s ETH-denominated TVL continues to go down 30 % YoY. You can see it in that we’ve seen some of the biggest Optimism projects shift their focus to other ecosystems. Despite multiple large RPGF rounds and considerable business development efforts, there remain such large gaps in builder representation that the hope appears now to be that new chains will pick up the slack from OP Mainnet’s lackluster expansion.
The fact is that the perception amongst application layer builders, a group woefully underrepresented in the current Badgeholder community as demonstrated by the lack of votes for leading OP protocols, that it simply is not designed to reward them, and they’re acting accordingly to determinant of the growth of the Collective.
This is a recipe for less impact, not more. And less impact means less Retro Funding.
Many of the design decisions in overhauling this round seem to oriented towards correcting for this, including more focused rounds, data-based voting, and a focus on onchain builders.
“This category will reward onchain builders who contribute to the success of Optimism. This round seeks to expand the reach and impact of the network by rewarding those building across the Superchain, increasing demand for blockspace, and driving value to the Collective. This includes builders who bring new users to the Superchain, drive network effects and protocol usage.” - RetroFunding Announcement
The desire with the changes this round seemed oriented toward ensuring that Retro Funding delivered on its core promise of impact = profit to reinvigorate the growth flywheel it is designed to create. The program shift even went so far as to drop the “Public Goods” portion in an attempt to convey that the focus was rewarding a project’s impact regardless of whether it came from original code or copy pasted code, from VC-funded projects or self-bootstrapped projects, from those delivering back to the Collective all of the value they create or privatizing it for a few.
The message here: we need more impact, and we don’t care what you are or how you get there. Please come create demand for OP Stack blockspace however you see fit, and we’ll reward it.
In the announcement of the overhaul and its subsequent communication, there was zero indication that certain code repositories would be privileged over others. However, the above post is now suggesting that there is exactly one type of impact that should be excludable: impact that comes from any project with so much as a single line of code that requires any kind of permission to reuse. It is suggested that there are should be no distinctions to be made between a 90 % OS project and a 100 % OS project, 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 5 x the value. This is frankly shocking and runs against the purpose of Retro Funding.
This suggestion will likely take us right back to the results of RPGF 3 , creating the conditions where impact is arbitrarily qualified and simple forks of existing OS codebases, whose code creates no additional value beyond that of the original and whose creators take on little legal or regulatory risk, will have the opportunity to be funded at rates much higher than those creating the most demand for OP Stack blockspace, generating substantial novel OS work, and do so at great personal risk given the profile of their projects.
It is also confounding as there was no lack of funding for OSS projects in the last round as they represented 80 % of the total distribution. The reputational issue we need to fix in this round of Retro Funding is with high impact builders who have largely written off the promise of Retro Funding — OS has been and will continue to be well rewarded.
Let’s explore some of issues here in more detail.
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 5 x 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 $ 1 M in TVL
Project B: Sroject combining 90 % OS code and 10 % non with $ 700 M 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 700 x. 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.
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.
Optimism itself would be filtered out by the blunt, rushed criteria proposed
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. What this tells me is that adding this filter seems rushed, as confirmed by Jonas’ own communication.
And this raises a question: why are we rushing an implementation to create binary filters for OS in a round focused on onchain builders when we haven’t even taken time to assess what exactly here is desirable? If Optimism itself is failing the proposed standard, maybe there’s a need to more fully consider that standard.
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.
In my opinion, the most important thing for Retro Funding to do this cycle is provide a strong signal to application-layer builders that the promise of impact = profit is more than a platitude. It is to make building on the Superchain such a no-brainer that we cannot keep up with the demand of projects flooding out of other ecosystems and into ours with the goal of creating impact. It is to make any shifting of investment to other L 2 s seem foolhardy. This is how we get new and existing projects to invest in building on the Superchain. Be the best at what you do, work to meet ecosystem demand, and seek impact even if there’s no immediate profit to see from it—because we’ve got you covered.
Any design or policy choices that could result in complicating the simple and eloquent message that impact = profit on Optimism risks perpetuating the failures of the last round and reinforcing the perceptions among application layer builders that this program is not designed for them. If we do want to go this route, we need to do so extremely carefully and not in a haphazard way.
My suggestion would be to remove the filters and multipliers from this round and instead use it as an opportunity to test and learn what kind of impact they could have if implemented in future rounds.
Something along the lines of:
Include a button to flag a desire to filter non-OS projects this round, but do not let it impact distributions; instead use the data to understand and model the potential impact of the design choice if used in future rounds
After the round, audit projects labeled as OS using the current methodology, and determine whether this labeling accurately captured truly 100 % OS projects or whether the live contracts look different in application and are not truly OS, use this to refine things
After the round, analyze how many OS projects represent novel interactions versus straight copy-paste jobs—and develop mechanisms to reward progenitors of the original code in these cases so that we actually reward the multiples of impact OS can create
In the mean time, design a round focused exclusively on rewarding OSS. Build in methodology to that round to parse the complexities of license types, find ways to attribute the origin of the codebases to reward their progenitors and contributors not the copiers. Keep the focus on impact = profit, but find ways to measure and reward the network effects of OS independently.
Likes: 11
Replies: 3
Likers:
joseebasanta,
abmis,
0x_Danw,
rrigo,
stas,
jackanorak,
Michael,
MSilb7,
Eagle_Cloak,
0x666,
dmars300
Replies:
- jackanorak: not much to add that alex hasn’t already outlined
other than to say that if this implementation goes as planned i’m going to have to spend, just like last time, about three months explaining to people, don’t worry, next time will be better, we’re always improving
and i really don’t want to have to do that when there’s a chance just to get it right now because each time the argument gets weaker when the outcomes are way off - and the audience is now not just partner protocols but partner chains
the downside of not implementing this at all isn’t anywhere near the downside of getting this wrong
- Jonas: 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:
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.
Dive deeper into the data to understand how many repos are missing licenses, who would be affected etc.
During the curation of metrics, badgeholders will be asked to signal if they want this feature.
- 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?
-
Retro Funding 4: Voting Experience
by alexcutlerdoteth - No Role
Posted on: May 14, 2024, 1:50 p.m.
Content: Summary
Retro Funding has the potential to be highly impactful to the growth of the Superchain, but to date it doesn’t have as much mindshare as it rightly should amongst application layer builders due to sub-optimal distributions in previous rounds that uniquely impacted the largest drivers of demand for blockspace. While this new round of Retro Funding made some promising changes, I am very concerned about some of the suggestions made above.
At issue is adding an overly-simplistic binary choice for Badgeholders to penalize projects that have even one line of code contained within them that requires some sort of permission to reuse. This choice may seem intuitive, but delves into an incredibly complex area that deserves careful consideration not a rushed last-minute addition under an imprecise classification methodology. If not done right, we risk repeating the mistakes of past rounds and under rewarding the impact we desperately need once again.
Retro Funding (formerly Retroactive Public Goods Funding) is core to Optimism’s Economics. It is designed to fuel a flywheel effect whereby builders/users create demand for block space, that demand drives sequencer revenues, those revenues are shared as rewards to those creating the most impact, which incentivizes more impact, more demand, more rewards, etc etc.
Screenshot% 202024 - 05 - 13 % 20 at% 201 . 27 . 58 %E 2 % 80 %AFPM 1450 × 906 84 . 7 KB
To distill this down, on Optimism, “impact = profit” or, in a more focused setting, “Build on Base”, be Rewarded”. A clear value prop to attract world-class builders to the Superchain. No qualifiers, no asterisks; just build impactful stuff here, and you’ll be rewarded. Simple and effective.
“Retro Funding is not merely a charitable endeavor; it’s building an impact system where contributions are valued and rewarded.” - RetroFunding Announcement 1
The two biggest issues with Retro Funding to date are:
We need orders of magnitude more demand for blockspace as the program is not even close to being sustainable 1 on sequencer revenues alone
Projects creating the most demand for blockspace have been dramatically under rewarded proportional to their impact due to design decisions made in previous rounds
So far, for the most impactful onchain builders, the type we most need to attract and support for Retro Funding to be successful, impact ≠ profit.
Last round, just 5 % of the rewards in the went to the top 20 % of projects 2 in terms of sequencer fee generation. Straight forks of OS codebases were rewarded at rates comparable to projects with 100 x their impact. The message to builders was this: the fastest path to reward is not impact but simply deploying forked OS code. Individuals could make more by launching simple forks or participating in governance than contributing to the most impactful and innovative projects.
This has created a flywheel working against the intention, as reflected in the fact that OP Mainnet’s ETH-denominated TVL continues to go down 30 % YoY. You can see it in that we’ve seen some of the biggest Optimism projects shift their focus to other ecosystems 7 . Despite multiple large RPGF rounds and considerable business development efforts, there remain such large gaps in builder representation that the hope appears now to be that new chains will pick up the slack from OP Mainnet’s lackluster expansion.
The fact is that the perception amongst application layer builders, a group woefully underrepresented in the current Badgeholder community as demonstrated by the lack of votes for leading OP protocols 2 , that it simply is not designed to reward them, and they’re acting accordingly to determinant of the growth of the Collective.
This is a recipe for less impact, not more. And less impact means less Retro Funding.
Many of the design decisions in overhauling this round seem to oriented towards correcting for this, including more focused rounds, data-based voting, and a focus on onchain builders.
“This category will reward onchain builders who contribute to the success of Optimism. This round seeks to expand the reach and impact of the network by rewarding those building across the Superchain, increasing demand for blockspace, and driving value to the Collective. This includes builders who bring new users to the Superchain, drive network effects and protocol usage.” - RetroFunding Announcement 1
The desire with the changes this round seemed oriented toward ensuring that Retro Funding delivered on its core promise of impact = profit to reinvigorate the growth flywheel it is designed to create. The program shift even went so far as to drop the “Public Goods” portion in an attempt to convey that the focus was rewarding a project’s impact regardless of whether it came from original code or copy pasted code, from VC-funded projects or self-bootstrapped projects, from those delivering back to the Collective all of the value they create or privatizing it for a few.
The message here: we need more impact, and we don’t care what you are or how you get there. Please come create demand for OP Stack blockspace however you see fit, and we’ll reward it.
In the announcement of the overhaul and its subsequent communication, there was zero indication that certain code repositories would be privileged over others. However, the above post is now suggesting that there is exactly one type of impact that should be excludable: impact that comes from any project with so much as a single line of code that requires any kind of permission to reuse. It is suggested that there are should be no distinctions to be made between a 90 % OS project and a 100 % OS project, 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 5 x the value. This is frankly shocking and runs against the purpose of Retro Funding.
This suggestion will likely take us right back to the results of RPGF 3 , creating the conditions where impact is arbitrarily qualified and simple forks of existing OS codebases, whose code creates no additional value beyond that of the original and whose creators take on little legal or regulatory risk, will have the opportunity to be funded at rates much higher than those creating the most demand for OP Stack blockspace, generating substantial novel OS work, and do so at great personal risk given the profile of their projects.
It is also confounding as there was no lack of funding for OSS projects in the last round as they represented 80 % of the total distribution. The reputational issue we need to fix in this round of Retro Funding is with high impact builders who have largely written off the promise of Retro Funding — OS has been and will continue to be well rewarded.
Let’s explore some of issues here in more detail.
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 5 x 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 $ 1 M in TVL
Project B: Sroject combining 90 % OS code and 10 % non with $ 700 M 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 700 x. 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.
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. 2 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.
Optimism itself would be filtered out by the blunt, rushed criteria proposed
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 2 . What this tells me is that adding this filter seems rushed, as confirmed by Jonas’ own communication 7 .
And this raises a question: why are we rushing an implementation to create binary filters for OS in a round focused on onchain builders when we haven’t even taken time to assess what exactly here is desirable? If Optimism itself is failing the proposed standard, maybe there’s a need to more fully consider that standard.
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 1 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.
In my opinion, the most important thing for Retro Funding to do this cycle is provide a strong signal to application-layer builders that the promise of impact = profit is more than a platitude. It is to make building on the Superchain such a no-brainer that we cannot keep up with the demand of projects flooding out of other ecosystems and into ours with the goal of creating impact. It is to make any shifting of investment to other L 2 s seem foolhardy. This is how we get new and existing projects to invest in building on the Superchain. Be the best at what you do, work to meet ecosystem demand, and seek impact even if there’s no immediate profit to see from it—because we’ve got you covered.
Any design or policy choices that could result in complicating the simple and eloquent message that impact = profit on Optimism risks perpetuating the failures of the last round and reinforcing the perceptions among application layer builders that this program is not designed for them. If we do want to go this route, we need to do so extremely carefully and not in a haphazard way.
My suggestion would be to remove the filters and multipliers from this round and instead use it as an opportunity to test and learn what kind of impact they could have if implemented in future rounds.
Something along the lines of:
Include a button to flag a desire to filter non-OS projects this round, but do not let it impact distributions; instead use the data to understand and model the potential impact of the design choice if used in future rounds
After the round, audit projects labeled as OS using the current methodology, and determine whether this labeling accurately captured truly 100 % OS projects or whether the live contracts look different in application and are not truly OS, use this to refine things
After the round, analyze how many OS projects represent novel interactions versus straight copy-paste jobs—and develop mechanisms to reward progenitors of the original code in these cases so that we actually reward the multiples of impact OS can create
In the mean time, design a round focused exclusively on rewarding OSS. Build in methodology to that round to parse the complexities of license types, find ways to attribute the origin of the codebases to reward their progenitors and contributors not the copiers. Keep the focus on impact = profit, but find ways to measure and reward the network effects of OS independently.
Likes: 11
Replies: 3
Likers:
joseebasanta,
abmis,
0x_Danw,
rrigo,
stas,
jackanorak,
Michael,
MSilb7,
Eagle_Cloak,
0x666,
dmars300
Replies:
- jackanorak: not much to add that alex hasn’t already outlined
other than to say that if this implementation goes as planned i’m going to have to spend, just like last time, about three months explaining to people, don’t worry, next time will be better, we’re always improving
and i really don’t want to have to do that when there’s a chance just to get it right now because each time the argument gets weaker when the outcomes are way off - and the audience is now not just partner protocols but partner chains
the downside of not implementing this at all isn’t anywhere near the downside of getting this wrong
- Jonas: 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:
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.
Dive deeper into the data to understand how many repos are missing licenses, who would be affected etc.
During the curation of metrics, badgeholders will be asked to signal if they want this feature.
- 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?
-
Code of Conduct Council Communication Thread
by alexcutlerdoteth - No Role
Posted on: Feb. 23, 2024, 8:42 p.m.
Content: Also incase there is any doubt left about his intentions, Weston just held a 24 h vote to disband NFTEarth without even posting an announcement in his Discord that the vote was happening. He claimed that lack of funds was core to his rationale, but didn’t mention the ~$ 24 , 000 he just made from the Optimism airdrop which should’ve gone to either the L 2 DAO or NFTEarth multisigs and been subject to community governance. https://snapshot.org/#/nftearthl 2 .eth/proposal/ 0 xe 240 a 0828 c 293 f 494 b 84774 c 2 f 483301380 ed 79 d 823 ef 05 b 7760 acde 273 b 4 b 60 9
Likes: 1
Replies: 0
No replies yet.
-
Code of Conduct Council Communication Thread
by alexcutlerdoteth - No Role
Posted on: Feb. 23, 2024, 7:08 p.m.
Content: The responsiveness of the committee here is commendable. To put some additional context around Weston’s attacks on the committee and process, I will just note that he took the same tact on Arbitrum after DisruptionJoe and Plurality Labs surfaced his wrong doing there. He repeatedly made unsubstantiated allegations of corruption, personally attacked Arbtrium DAO members, and even used alt accounts to imply he would inflict physical harm on the individuals in question if given the opportunity. Of note, he never appealed the decision on Arbitrum or followed up on any of the legal threats he has made. Given his track record, I believe it is reasonable to read Weston’s responses as just further attempts at obfuscation in an attempt to avoid personal accountability. And after two warnings his continued willingness to make false allegations against the CoC Committee is just all the more evidence that he will never be willing to abide by the Rules of Engagement. I wouldn’t waste too much time on him, by this point the Collective is more than able to see through his bad faith attacks. I look forward to the Committee conclusions. Arbitrum – 17 Oct 23 Delegate Violations: Investigation Into disruptionjoe.eth to Determine... 2 Grants Discussions delegation proposal governance Abstract This AIP proposes an immediate investigation into the actions of @DisruptionJoe - AKA disruptionjoe.eth, a Delegate involved in managing grants distributions for Arbitrum and operating through Plurality Labs as well as his documented... Reading time: 5 mins ? Likes: 95 ❤
Likes: 1
Replies: 0
No replies yet.
-
Code of Conduct Council Communication Thread
by alexcutlerdoteth - No Role
Posted on: Feb. 23, 2024, 3:42 p.m.
Content: Also incase there is any doubt left about his intentions, Weston just held a 24 h vote to disband NFTEarth without even posting an announcement in his Discord that the vote was happening.
He claimed that lack of funds was core to his rationale, but didn’t mention the ~$ 24 , 000 he just made from the Optimism airdrop which should’ve gone to either the L 2 DAO or NFTEarth multisigs and been subject to community governance.
https://snapshot.org/#/nftearthl 2 .eth/proposal/ 0 xe 240 a 0828 c 293 f 494 b 84774 c 2 f 483301380 ed 79 d 823 ef 05 b 7760 acde 273 b 4 b 60 11
Likes: 1
Replies: 0
No replies yet.
