[Formal Review][RGP-20] - Grants Org Proposal 2024

Grants Org Proposal 2024

Author(s): bordumb, abbey
Type: Org
Created: 2024-11-06
Discussion Post: [Discussion][RGP-20] - Grants Org Proposal 2024
Status: active

:memo: This is the official Formal Review draft for RGP-20. Please formally review the proposal and vote in the Snapshot poll by :rotating_light:17:00 CET - Monday, November 27th :rotating_light:!

Purpose

The purpose of this proposal is to elevate the scope of Grants as the main body that manages the technical funding behind Radworks’s broader mission:

Radworks is a community dedicated to cultivating internet freedom. In a world that almost entirely relies on software, maintaining the resilience and health of the free and open source ecosystem is more important than ever. We strive to demonstrate the viability — in cost, labor, quality, and resiliency — of open-source software and its development. (1)

The Radworks Grant Org’s (Grants) goal is to fund projects focused on censorship resistance, internet freedom, and permissionless technologies. This includes third-party integrations & tooling (IT) specific to Radworks technologies and general open-source projects.

Our Grants budget is 1,050,000 USDC.

64% of our budget is dedicated to Integration and Tooling (IT) Grants and 24% of our budget is dedicated to FOSS Grants. The remaining 11% will be allocated on an ad-hoc basis to fund any other projects that directly contribute to the Radworks ecosystem (Drips and/or Radicle).

Strategy & Roadmap

Previous Grant proposals have been specifically focused on supporting the development of Radicle and Drips. Now, in line with Radworks’ newly formed purpose, the Grants Org aims to expand and broaden its scope to FOSS funding, while setting clearer & more precise goals.

The 3 main areas of focus are below.

Integrations & Tooling

Integrations & Tooling Grants are born out of our long-standing relationship with Yorgos’s team – a community contributor who has worked on previous grants, such as IDE plug-ins for VSCode and JetBrains. Their focus has and will continue to be on integrating Radicle with external developer tools. The main goal is to lower friction for developers who want to integrate Radicle into their existing workflows.

The plans below are tentative, however, there are cases where any of these projects might be dropped in favor of more urgent ones. For example, in cases where we are onboarding a community, they may be blocked by some missing feature. The team will move plans around accordingly to help in these cases.

Note: The list of projects below are ranked based on importance and whether or not they have a technical dependency on Radicle v1.0, which is a risk we want to mitigate.

Budget

The total budget is estimated at 680,000 USDC

Note:
The budget is not necessarily guaranteed.

  • The grantees will still have to write up quarterly applications that provide specific milestones and updates on current progress.
  • Approval of these applications will still be at the discretion of the Grants committee.
  • The reason for earmarking this budget is to put this work in a solid position to allocate labor towards tools that we feel are essential for onboarding new users.

While we are allocating financial capital, we are also allocating human capital. Having this budget set aside will make sure that the people working on it have better confidence and ability to be full-time with the work, rather than haphazardly coming and going.

IDE Plugins

IDEs are where most developers start writing their code and locally, where they do most of their organization of work. It is crucial to have plug-ins with the most popular IDEs so that developers feel comfortable integrating their existing workflows into the Radicle ecosystem. Without this, Radicle becomes a tough sell.

Success Criteria:

  • Work with issues and patches within IDE
  • Integration with Radicle 1.0 across JetBrains and VSCode plug-ins

Stretch Goal:

  • Look into Neovim plugin (Cloudhead proposal)

Estimates:

  • IntelliJ: 5-6 months, 80K
  • VSCode: 6-9 months, 190K

We have already funded work on plugins for the 2 most popular IDEs (VS Code, Jetbrains IDEs), and in 2024 we want to reach a “1.0” version for each one. VSCode work was started significantly later than JetBrains, so needs more development to catch up, hence the larger budget.

:white_check_mark: V1.0 dependency: this project does not have any significant dependency on Radicle v1.0

IM tool integrations

Instant messaging tools are where developers spend most of their time collaborating in real-time, especially in remote, asynchronous teams. Whether they are open source tools like Zulip, or closed-source like Slack and Discord, they serve this same purpose. Integrating with IMs – with features like notifications on new Patches, comments, and @mentions – will allow teams to stay in-synch more easily. Without this, teams will continue having more friction staying on top of updates in their Radicle repositories.

Success Criteria:

  • Integrate with Zulip and dog-food
  • Integrate with Slack/Discord

Estimates

  • 6-8 weeks
  • 60K

:white_check_mark: V1.0 dependency: this project does not have any significant dependency on Radicle v1.0

Migration Tooling

Migrating an entire project from somewhere like GitHub introduces a significant hurdle. By creating migration tools, we can lower the overhead and make it that much easier for teams to migrate their projects. Without this, the task is daunting and may be too high a hurdle to convince teams to switch tooling to Radicle.

Success Criteria:

Estimates

  • 4-5 months
  • 160K

We have already funded basic research and development for GitHub issues.

:white_check_mark: V1.0 dependency: this project does not have any significant dependency on Radicle v1.0

CI Integrations

Continuous Integration (CI) is the go-to paradigm for ensuring that code is properly tested, verified, and built. By adding CI tooling, we will ensure that one of the most important steps in software development workflows is integrated with Radicle. Without this, migrating to Radicle is a harder sale.

Success Criteria:

Estimates

  • 5-6 months
  • 190K

We have already funded basic research and development for CI integrations.

:rotating_light: V1.0 dependency: this project does have a significant dependency on Radicle v1.0. Thus, we have listed it last. There may be nominal work in the beginning of the year, however, if there are any delays with v1.0, this project can and will be pushed out later.

Funding Analysis

The Integrations & Tooling team consists of 4 full-time, including 2 senior developers, and 3 part-time members. Comparing to our Core teams, this is roughly 3/5 the size, for 1/3 the cost. Comparing to industry, it is also a very reasonable (source: levels.fyi), where the budget would likely range between 650-750K.

Other Radworks

We are allocating 300,000 USDC for open applications for any projects that contribute to either:

  • Contribute direct improvements to Drips or Radicle

OR

  • Build 3rd party integrations with either Drips or Radicle

Contrasting with IT Grants, we do not have any specific projects in mind for this category.

The success and refined focus of the IT Grants is a testament of what can happen by setting aside budget for open applications.

We believe that having this budget set aside will allow us to be in a position to take open applications, as well as actively recruit teams for retroactive and proactive funding.

Funding

This funding may be retroactive funding (i.e. paid out after a product is already finished) or as proactive funding (i.e. paid out before work is started).

In the event that we fund something retroactively, we will pay out via Drips as a short-term drip for the amount paid out (e.g. 10,000 USDC streamed over a month).

In the event that we fund something up-front, we will follow the same payout method as previous Grant rounds (i.e. total amount of USDC dripped over the timeline, per milestone).

FOSS Grants

The primary goal for FOSS Grants is to fund projects focused on censorship resistance, internet freedom, and permissionless technologies. These will include projects that are outside of the Radworks ecosystem.

Funding

The focus on funding will be FOSS projects that enable censorship resistance, internet freedom, and permissionless technologies.

This will include projects that deliver enhancements to the broader FOSS ecosystem, including but not limited to programming language libraries, package management systems, open-standard communication protocols, and tooling for privacy. It is important to note that our funding is not allocated towards the initial proof of concepts (POCs).

This budget may be used for retroactive funding, such that funding is targeted to proven technologies. We will also allocate funding to brand new projects.

We will both actively seek out grantees (proactive) and passively welcome inbound requests for grant funding. However, our primary focus for 2024 will be to grow our muscle in actively searching for and nurturing software projects from the ground up.

As part of this, we will aim to onboard any project we fund to Drips so that we utilize that infrastructure for funding. Onboarding will include asking each project to setup their own Drip List. We will also work to onboard projects to Radicle.

We estimate this will require 70,000 or 7% of the budget.

Outreach

We will allocate some portion of this budget for outreach with open source communities. This may include going to open source conferences and meetups.

We estimate this will require 3,000 or 0.3% of the budget.

Organizational Structure

The Grants committee includes all members of our Gnosis Safe multi-sig, found here.

Current Members

In alphabetical order:

  • Abbey (Radworks)
  • Bordumb (Radworks Community; Lead)
  • Jenny (Exonumia cofounder; tentative, to be voted in)
  • Nader (Aave/Lens, DevDAO founder)
  • Nas (ex. Safe, ex. Radworks)

Member Responsibilities

  • Reviewing Applications: reviewing applications in detail. If a committee member does not understand something, they are expected to be resourceful in learning or finding outside council on a topic.
  • Reviewing Milestones/Completions: reviewing milestones/completed work in detail. If a committee member does not know something, they are expected to be resourceful in learning or finding outside council on a topic.
  • Multi-Sig voting: participate in voting on and funding grants.
  • Meetings: most work will be done asynchronously, but committee members are expected to actively participate on Discourse, community, and governance calls.

Membership Terms

If a member fails to actively participate in voting, they may be removed from the committee. As this is all on-chain, it will be a fairly straightforward process. For now, we will expect members to evaluate and vote on at least 1 grant per 3 months. If there is no grant to be voted on, this will not apply for the 3 month period. Members may abstain from a vote, but must publicly declare their abstention.

The rules above will apply retroactively for 2023 voting, and will effective immediately upon approval of this proposal.

If a member is found in violation of our community guidelines, they may be removed from the committee.

Communication

Applications

Grant applications are the primary documents that outline what is being worked on.

You can find more info on Discourse here: https://community.radworks.org/c/grants/24

Repos

All of our long-term documentation, including various templates (proposals, grant applications, RFPs, etc.), as well as organizational structure can be found in our repos below.

Reporting

The Grants lead (Bordumb) regularly gives updates in all Community Calls.

The Grants lead regularly gives written quarterly updates. The latest can be found here.

Stand Ups

Bi-weekly.

Reasoning & Analysis

FOSS Grants

FOSS Grants is set to back initiatives aimed at bolstering anti-censorship, promoting internet freedom, and nurturing the growth of permissionless tech. This support isn’t just for projects under the Radworks umbrella; we’re looking to fuel innovation in the wider FOSS space. Our funding is geared towards those ready to create a web that’s resilient and free from undue restrictions.

Our grant-making philosophy draws inspiration from the likes of Sovereign Tech Fund (STF) and the Electronic Frontier Foundation (EFF), with a track record of catalyzing change through both substantial and highly specialized grants. A great example from STF are their grants targeting tooling within coding ecosystems, specifically targeting single repositories for funding (e.g Python Security Library Grant). We’re aiming to emulate this funding model, aiming to strike a balance between substantial contributions to large-scale projects and pinpointed funding.

As for the allocation of our resources, we’re taking a page from sentry.io’s playbook. Their incremental approach began with an initial funding pool of around $70,000, methodically nurturing their program to greater extents over the years (2022 program, 2023 program). We’re setting off on this journey with a similar initial funding, determined to expand and evolve our funding initiatives to scale up the support for open-source grants progressively.

Integrations & Tooling

The primary goal with Integration & Tooling (IT) grants is to cover key integrations for Radicle code collaboration. These include integrations across the typical software development stack.

Starting from writing code in IDEs, to instant messaging for teams, continuous integration/development (CI/CD), these grants are aimed at making it easier for developers to plug Radicle into their existing workflows.

Essentially, the aim is to make sure we have integrations across each part of the software development life-cycle, as shown below. So far, we are focused on the most basic components around Coding and Deployment of software.

Each tool we integrate with is generally prioritized by a combination of market share.

Reporting & Success Criteria

Through Q2 2024, the Foundation Org will provide monthly financial reporting to Radworks on behalf of the Foundation, Radicle, Drips and Grants Orgs. Therefore, starting in Q3 2024, the Grants Org will publish monthly financial reports on Radworks-granted funds spent by the Grants Org .

FOSS Grants

Operational

  • Contributor Growth: measure the growth of contributors to each project. Gaining contributors is a strong signal that a project is of interest to developers.
  • Project Legitimacy: we will aim to onboard key FOSS projects (of the likes of curl:// or Tor) to accept Drips.
  • Funding Variety: measure the diversity of project types and sizes to ensure a broad impact. We should aim to cover projects that touch most, if not all, of Radwork’s Foundational Beliefs.

Technical

  • Onboard 100% of FOSS teams to accept payment via Drips
  • Onboard 100% of FOSS teams to Split their incoming Drips
  • Onboard 100% of FOSS teams to use Radicle

Integrations & Tooling

Technical

  • 100% of new features delivered

Operational

  • 100% of tools tested by users
  • 100% of tools get feedback from users
  • 100% of grants paid out via Drips
  • 100% of code delivered via Radicle

Retrospective

Timeline & Budget

All costs will be spread out over 2024.

Grants

1,050,000 USDC

Committee

100,000

Fund Management

The Grants Org - also the “Grant Recipient” of Radworks, if this proposal is passed - hereby agrees to use the amount granted by Radworks in support of fulfilling the purpose outlined in the “Purpose” section above. The Grant Recipient understands and acknowledges that the awarded amount may be used only for this Purpose. Furthermore, any part of the grant that goes unused in the calendar year outlined in this proposal (for 2024) will either be returned to the Radworks Treasury (by March 2025) or rolled over into and applied towards the Org’s 2025 proposal and future grant from Radworks.

Assets

All assets will reside in one of two locations: Gnosis Safe or Drips. These will be used both for paying grantees and committee members.

Any remaining assets will roll-over into the 2025 budget.

Gnosis Safe

Link: https://app.safe.global/balances?safe=eth:0x394B920c5d39E0Ca40fCa2871569B6B90D750c7c

Drips Account

Link: https://www.drips.network/app/0x394B920c5d39E0Ca40fCa2871569B6B90D750c7c

Risk Management

Paying for Grants work is inherently risky. We do not know which projects will succeed in delivering work.

However, luckily with Drips, we can pause and completely stop Streams at will. In the event that a Grantee needs to pause work or stops working entirely for any reason, we will be able to either pause or stop the Stream.

Retrospective

Please see 2023 retrospective here: Grants Org Retrospective 2023

Technical Implementation

1 Like

Hi @bordumb! First, thank you so much for the proposal and apologies for not being able to drop comments/feedback earlier. I read the Discussion & Formal Review posts and wanted to share some feedback here before voting on the Snapshot poll.

To start, to be clear: the main change made between the Discussion and Formal Review was the decision to allocate more of the budget from the FOSS Grants category to the “Other Radworks” category? So the requested budget is still 1,050,000 USDC + 100,000 USDC worth of RAD? It’s a bit unclear what the actual ask is in this version of the proposal. Perhaps try making it more clear in the Budget section.

I’ll split up my feedback by category of funding:

On “Integrations & Tooling”

  • First, just wanted to give a huge shoutout to @yorgos and co. for all the amazing work they’ve contributed throughout the year on the Jetbrain/VScode integrations, migration tooling, and CI work. It’s been awesome to see you team building out the Radicle open source ecosystem and I’m excited to continue that work into 2024!

  • Regarding budget, as @lftherios mentioned, the requested $680,000 USDC is around 34% of the requested development budget for Radicle (~1,975,448 USDC excluding marketing & operational costs). I believe this number is a bit too high. Allocating 680,000 USDC to only Radicle integrations would mean total spend on Radicle vs. Drips would be around 1.6x more. While I understand the need for integration & tooling to support the adoption of Radicle (@yorgos I really agree with your replies to the Discussion post), its hard to see the reason for such a larger spend on Radicle before a stable release has been shipped.

  • That being said, I do believe additional funding should be allocated towards integrations & tooling via Grants outside of the Radicle budget because the work is important to the growth of Radicle’s open source ecosystem. I believe being able to provide more “stable ground” for the great developers who have been contributing to the project is important for all the reasons @yorgos listed below :point_down:

  • Finally, to warrant this budget I belive there needs to be some vote of support or signal of alignment from the Radicle Org team. I am hoping @cloudhead or someone else from the Radicle team can chime in here with their thoughts because it is hard to judge the value of the proposed integrations to the Radicle ecosystem (and indirectly to the Radworks ecosystem) without a supplementary opinion from building out the tech. For example, I still have open questions like:

    • How does the proposed CI work interoperate with the Radicle Org’s “Build out Radicle CI/CD” objective?
    • What integrations will best support Radicle’s “path to PMF” as outlined in the MoU: Radworks & Radicle Org
    • What are the biggest pain points of early Radicle users?

    Its hard to evaluate the budget without being able to understand how the proposed work will support & interoperate with the Radicle Org’s objectives & roadmap.

My suggestion would be reduce the number of scoped projects from 3 to 2, and closely integrate these projects with the roadmap of the Radicle Org so that they can be adapted to support the organic growth that we will see with the release of Radicle 1.0. This would mean removing projects that are dependent on the stable release (as you’ve identified).

I am lacking context for where & how the proliferation of tooling amplifies adoption of open source software, but I feel like focusing on smaller, well-scoped integrations (e.g. the migration tools, specific developer tooling) and making them great makes more sense vs. broadening the scope of integrations (e.g. IMs, messaging).

On “Other Radworks”

  • I think its important that our Grants program should support the growth of all our technologies. There is a lack of detail for how Grants can support the Drips Org and their objectives in the proposal. I would like to see more definition in this category specifically highlighting the ways that grants can be used to steward & support adoption of Drips.

  • I agree with reducing the “FOSS Grants” budget in an effort to put more capital & focus into this category, but (as mentioned above) believe we should add more definition to ensure that it will be allocated as intentionally & productively as it can. I believe the proposal should provide more specific context on how different types of grants tie into the objectives & roadmap of Radicle & Drips. I believe a conversation with Org leads about their needs & desires is warranted before setting this category in stone.

On “FOSS Grants”

  • I understand @lftherios’s concern of “What justifies the current timing for extending beyond Radicle and Drips-related initiatives?”, and am supportive of reducing the budget for this category. My personal belief is that with proper scoping, this category can strengthen the Radworks ecosystem as whole by bringing in more developers, users, and potential governance participants to our ecosystem. While our dependency funding (Radworks Gives $1M to FOSS Dependencies with Drips — Radworks) is definitely a substantial step in this direction, I see a lot of opportunity to continue “funding new censorship-resistant and permissionless technologies to cultivate Internet freedom” without minimizing focus on Radicle and Drips respectively. I consider us building out the Radworks value proposition as mutually beneficial to the technologies we fund. That being said, I am supportive of taking a slower, more progressive approach to building out this strategy in an effort to collectively prioritize the work of Radicle & Drips.

Despite all of my feedback above, I am still in support of this proposal and plan on voting as such. Due to the organizational structure of Grants (meaning, that funds are still only accessible via application and approval by Grants committee), I believe that we can take the rest of the year to collectively restructure these objectives to ensure all capital will be allocated intentionally and productively. I am in support of the Grants Org existing in 2024 and am excited for the potential grants outlined in all three of these categories.

That being said, I believe we have to revisit the top-line number of this budget to 1) align it with the priorities of the Orgs and 2) more accurately reflect the feedback of stakeholders in the Discussion post. I believe this proposal would garner more support if it reduced budgets to something like:

  • Integrations & Tooling: ~430,000 USDC (IDE Plugins + Migration Tooling)
  • Other Radworks: ~250,000 USDC
  • FOSS Grants: ~50,000 USDC

These are just rough numbers that “make sense” to me based on personal opinion + digesting other stakeholder feedback. However, I am really looking to the Radicle Org to provide more context on the Integration & Tooling category so I can provide a more informed opinion on what I think spend should be there.

Let me know your thoughts here. Again, apologies for not being able to send this message earlier. I am still confident we can find a way to move this proposal forward in either this cycle or the next one :slight_smile:

1 Like

I agree with Abbey’s feedback, the two issues I see are:

  1. The proposal code transfers 100K RAD if I’m not mistaken, which is not the number in your proposal write up
  2. The amount of 680K seems much too high for integrations, since it’s not far from the spend on core protocol development for Radicle

thanks! :raised_hands: :slight_smile:

I am not sure I understand where the comparison between the 2 projects comes into play here when deciding how much to invest in each one… :thinking:
Is there some assumption that we want to invest equal amounts of money to the 2 projects ? Would we always divide the total investment amount by the number of projects we’re funding? Shouldn’t the investment into each one be considered independently of the other one?

If we do want to compare however, just considering that Radicle is taking on the whole of GitHub (and competitors) while Drips is only taking on GitHub Sponsors (and competitors) - which is only a part of GitHub’s offering - I would expect a much larger investment in Radicle than in Drips (overall, not just referring to this proposal cycle or this particular proposal).

We’ve already made the point (in the proposal itself and in the previous discussion post) that the budget can be used for other projects (beyond just integrations), and that we’ll align with the interests of the communities that the Radicle Org is planning to onboard and prioritize work accordingly, since we’d essentially be funding people to work on projects (that the Grants committee will then still need to approve).

There is still tons work involved in making a core protocol (that the Radicle Org wants to focus on) into a product that people actually want to use (let alone might want to pay for) and migrate their projects to, and this is what I’d like our team to focus on, while the Radicle team focuses on core protocol development itself.

Having said that, if that is not an area of focus for this year, or we don’t want to have so many people working on this area yet, (or if there is overlap with the Radicle Org team and you will be taking on that work) that is also perfectly understandable and I’ll be resting my case. :slight_smile:
We can just keep contributing in a part-time capacity and see how things go in the future.

Thank you for the updated proposal @bordumb.

I agree with most of @abbey 's point above.

With regards to Integrations & Tooling, I am ok to support the budget requested as long as the budget and work prioritisation is managed and distributed by the grants committee throughout the year based on impact. Specifically, I would like us to scale funding as the year unfolds and:

  1. Radicle 1.0 is out
  2. user feedback is collected and shared with the Radworks community about which integrations to prioritise and why
  3. work is prioritised based on 2 and
  4. usage / expected impact is measured and reported

Basically, the same things that we expect from the other two tech teams.

With regards to “Other Radworks” and “FOSS Grants” I am fully behind what @abbey wrote above.

I think the comparison spawns from the reality that Radworks is supporting both Radicle and Drips relatively equally in terms of time, capital, and commitment. While the allocations should be considered independently to each other, when evaluating the spend of a Radworks Grants program I personally would expect Grants to be used to support both technologies relatively equally as well.

You are correct that Radicle is taking on a “bigger fish” in a way and so it doesn’t make sense to just compare $$$ to $$$, but I believe the Grants program should contribute to both Drips & Radicle’s path to PMF equally, even if the amounts of funding differs.

I hear you, and I think the approach is definitely the right one. I think the goal here is to get more alignment with the Radicle team on how integration & tooling grants can support their path to PMF to better support the Grant Committee’s decision-making. As a committee member myself who would be evaluating these applications, I don’t feel like I have enough information to make effective decisions about what should be funded and when without more information on how the proposed grants should interoperate with the Radicle roadmap.

This is why I appreciate @lftherios’s take on how we can scale funding.

Just to be clear, I can also get behind the budget being proposed and at the end of the day, want you and your team to feel empowered & committed. I have concerns with how well the Grants Committee will be able to manage the proposed budget without more information/alignment with the Radicle Org. If we could work together to paint a clearer picture of how the potential tooling & integrations budget could be deployed alongside of the Radicle roadmap, that would be great.

I think that figuring this out together now will actually make everything run smoother throughout the year, as the Committee will be able to review and approve grants in a more intentional & informed manner.

1 Like

@cloudhead - can you elaborate on what amount of funding you see being appropriate for spending on tooling & integrations in 2024?

:sparkles:Snapshot Poll Result :sparkles:
The 2024 Grants Org proposal was unable to meet quorum needed to move to onchain Submission this week. This is mostly due to disagreements with the budget and spending distribution proposed. The proposal author will take this feedback into consideration and post a new version of the proposal for discussion in December. As there will be no December cycle given the holiday interruption, the new proposal will be voted on in the January proposal cycle.

Note for clarity & transparency:
The proposal author had deleted the original Snapshot poll over the weekend after discovering some errors in the description. The amount listed for the RAD allocation in the poll description was not aligned with the governance code. The description showed 44,000 RAD, while the code showed 100,000 RAD. 100,000 was the correct amount, and this was changed in the description of a new poll he posted on Saturday.
Unfortunately, in doing this, he lost all votes that had been casted on the original poll.
The new Snapshot poll was also unfortunately not created correctly, and had the wrong end date & time which would have given the Grants poll a longer voting window than the other active proposals. To avoid confusion and to be fair to other proposal authors with active proposals, we will be deleting this poll, as there is no other way to pause or deactivate it. We wanted to leave record of its existence below. We apologize for any confusing, and are discussing measures to make sure this doesn’t happen again in the future.

Thanks a bunch for the thorough notes, including screenshot @shelb_ee

I’ve gone ahead and completely deleted the Snapshot poll, so that we’re aligning with the policy of having votes up for a week.

Will regroup with others and put in another proposal in the coming months.

Thanks a bunch everyone for the feedback!

1 Like