[Discussion][RGP-20] - Grants Org Proposal 2024

Grants Org Proposal 2024

Author(s): bordumb, abbey
Type: Org
Created: 2024-11-06
Status: active

:memo: This is the official discussion post for the 2024 Grants Org budget proposal. With this post, the proposal has entered the first phase of the governance process. Please review the drafted proposal and contribute feedback by Sunday, November 19th. This proposal will be discussed in the Proposal Review call on Wednesday, November 15th. Add to calendar here.

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 250,000 or 25% 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 $250,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

2 Likes

Thank you @bordumb for this awesome proposal! It has been so exciting to see how Grants has grown and developed over the past 1.5 yrs! :rocket: As the work outlined here is so well scoped, this will be a great reference to share around the ecosystem to attract talented folks to tackle it.

A few comments & questions for you below:

This is a really exciting direction and feels really well aligned with Radworks’ overall purpose & mission.

Weren’t you considering to request a portion of the next Grants budget in RAD so that we could start distributing RAD to meaningful contributors within our community? We had discussed at one point that having a bit of RAD on hand to partially compensate grantees who continually come back and do impactful work would makes sense. Why does this budget request not include any RAD/what changed?

These are AWESOME goals to have - and I love the dog-fooding nature of using Drips & Radicle. The first two points, however, could require a bit of coordination on your end in order to get ample and meaningful feedback. How do you plan to spread the word within Radworks to get folks a) to test projects and b) give feedback?

This is such an incredible accountability mechanism to have built into a grants program! It really provides the flexibility that is often needed in this type of funded work.

Not sure if this is relevant for the proposal itself, but I wanted to bring it up anyway just in case it was. Regarding the distribution of influence experiment you started last year using Otterspace badges, do you plan to continue this? I thought this was a great initiative to try to open up influence on decisions around which grants to fund to more community members, and would love to see it continue!

I have also had some ideas recently on how we could possibly expand it and would be curious to hear your thoughts. I know the current program allows past grantees to participate in off-chain polls to signal support for a new grant application to help the Grants Committee gauge broader support for the proposed project. I think it would be cool to explore how we could open this up even more to include other active contributors within the Radworks ecosystem (Org contributors, active delegates, etc.)! Also, how would you feel about using this same system to elect new Committee members? This could be done just by signaling support like the current system or, with the right tooling setup, the vote could result in the actual granting of access to the committee multisig. I would have to look more into exactly how this would be possible with Otterspace badges, but with Hats Protocol this is definitely possible.

1 Like

Also these numbers are not the same. Which one is correct?

In its current form, this Proposal’s budget is very much just about the labor/wages going into 2024.

In speaking with Yorgos, it seemed like that adding a significant budget increase for this might put the overall Proposal at risk of too much back-and-forth and not passing. It’s a bit like trying to add “pork” to the Grants Proposal.

What we’d likely do is something like this:

  • Propose budget for X amount of RAD
  • Add this to Drips Contract
  • Schedule a Stream of that RAD that streams over 4 years
  • Usually vesting contracts last 4 years and don’t start until 6-12 months (to incentivize sticking around at least until that Stream start date)

So realistically, we wouldn’t need these funds for another 6 months. We can always make another Proposal sometime later to ask for this budget and that Proposal would be very specifically target incentivizing grantees with RAD.

This is another reason to just wait until later to Propose budget for this.

Hope that makes sense!

1 Like

The word “community” was a misnomer here.

I’ve changed it to “users.”

This will be the responsibility of the grantees (Yorgos) to collect feedback from users of their software.

2 Likes

I think this is a good call out.

I’ll spend some time fitting this into this 2024 proposal and get it in by early next week.

We will definitely be able to use this in the near future.

Good catch!

Corrected it to 1,050,000 USDC.

1 Like

@bordumb - it’s exciting to see you mature and professionalize the Grants Org. This proposal looks strong and I’m eager to see how you evaluate grant seekers - and how we can potentially work together to identify additional support for these Grants Org-supported projects within the Radworks ecosystem.

Could you include the total cost for this “Integrations and Tooling” work in this section? It would be helpful given the comparison to market rates. Also, I take it the amounts listed are in USDC?

It’s clear that the evolution of the “Integrations and Tooling” work is truly the result of the (awesome) work of @yorgos and team. Has there been any similar work to help engage more projects to build on top of the Drips protocol?

Are we missing something? “… a combination of market share and…”?

Secondly, will @yorgos and Team interact with (support, use, inform) the user research that the Radicle Org intends to do, regarding
“Gain a better understanding of what features are missing to onboard more users”? Does this have any tangential impact on the team’s prioritization of tools to integrate?

Again, “USDC” I presume? It would be good to provide currency throughout for clarity.

Could you provide (in this section) the breakdown of this budget to show how it’s allocated between “Integrations and Tooling”, “Outreach,” “FOSS” etc?

Generally - want to say thank you for the high level of transparency around budgeting and what certain objectives will cost.


Are there any other costs associated, other than labor?


What kind of conferences or meetups are planned in this budget? My initial thoughts are that $3K might be a little low, even for modest outreach, but might be wrong!

Huge fan of the Migration tool horizon and details there!

Why would it have to be a budget increase though? I had understood/imagined it being requested as a portion of your total budget request (e.g. 1,000,000 total worth of USDC with 800,000 USDC & the rest in RAD)?

We could also try using Jokerace for this! Gitcoin is using to nominate/select “collection curators” (see here).

(this is probably also a question for the radicle org, but just to add my point of view here)

We already have a close interaction with the radicle core team on https://radicle.zulipchat.com/ on a daily basis and are in the process of migrating our own repos to radicle as well.

As far as prioritization of features we build, that is absolutely the goal and that is, I think, why the proposal above states:

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.

Thank you for this proposal @bordumb. My comments & questions below:

While going through this, my primary inquiry was, “What justifies the current timing for extending beyond Radicle and Drips-related initiatives?” The foundation’s 2024 proposal suggests substantial ongoing efforts in shaping the vision, mission, and strategy for Radworks. Personally, I would recommend that the Grants organization refrains from allocating capital outside Radicle & Drips, until these aspects are more clearly defined and matured.

My main objection here is that the budget requested for releasing Radicle 1.0 for 2024 is $2.1m. Based on the above, the requested budget here is 30% of that ($640k). This feels quite substantial to me. As a relative allocation I would feel a lot more comfortable with an amount closer to 10% of Radicle’s budget.

I would also recommend that we revisit some of the proposed Integrations & Tooling work after Radicle 1.0 is out and reprioritize initiatives based on actual user feedback from Radicle users. For instance, we might discover that their tooling needs are very different from the needs of the average developer.

@ange I’ve addressed all the smaller points by editing the proposal.

Regarding this one:

It’s been small.

As of right now, the budget breakdown for Grants is 1,050,000 USDC, broken down as:

  • IT: 680,000 USDC
  • FOSS: 250,000 USDC
  • “Other”: 120,000 USDC

The left over 120,000 USDC for “other” projects can be used for Drips.

I think the reason that Radicle has garnered such a large budget over the past year is because Radicle is built off of existing technology (namely Git). So the problem set — namely integrations — is a known technical problem. We know what kinds of integrations are necessary for developers and it’s very, very easy to look at all the current integrations others — like GitHub, GitLab, etc. — already have. So there’s a lot of low-hanging fruit. And it happens that these integrations fall outside of the purview of the Radicle Core team. It’s safe to say that the timeline for this work started earlier, so is naturally further ahead.

Drips is building brand new technology, so much of the build-out has fallen on the Core team.

We have received grant applications related to Drips, but they were not approved after input from the Drips team (e.g. This One or This One.

Looking at that 120,000 USDC, I think it’s a good chunk to start building a muscle for funding grants related to Drips projects. But I think we’ll want to work closely with the Drips team to make sure these funds are used judicially, in a way that helps them grow their user base.

I agree with this, mostly.

I’m assuming we’re talking about the FOSS budget, currently set to 250,000 USDC.

I think it would still be good to have some nominal budget put aside to allow us to jump on something, if it makes a lot of sense. For example, what if we took the 250,000 USDC budget down to 25,000 USDC.

Then we’d use the remaining 225,000 USDC left over to categorize into the “other” category, to cover any thing that might come up with Drips or other more core-related grants.

Thoughts?

I agree that it feels substantial.

The argument here is that the space for the very basics of developing software is a somewhat “solved problem.”

For example, we know we need to write code in an IDE. So we need IDE integrations.

We know we need to store and share code. So the Core team works on Radicle.

We know we need to test and build code. So we need CI/CD integrations.

etc.

This concept is outlined in the last slide/visual:

I agree that we may be blind to some future needs of Radicle 1.0 users. But I think setting aside the budget for the above integrations will be the bare minimum that many developers will ask for.

If we imagine developers onboarding to Radicle without the above projects, it’s likely safe to say that onboarding new users will be that much harder.

This could also have a negative impact on our ability to get feedback at all (i.e. how many developers would give up without IDE and CI/CD support?)

Happy to discuss this more on the call! :smiley:

1 Like

Based on feedback from the community call earlier this week, I’ve edited the IT Grants sections.

Please note the changes made addressing feedback from the call, namely:

  • A note at the top of the section on the governance of those funds (i.e. we will still expect quarterly applications + final approval per application will be at discretion of the Grants Comittee)
  • Which parts of that budget is dependent on Radicle v1.0 launch (only CI integrations)

I am still working on lowering the 250,000 FOSS and writing up plans for what to do with remaining funds left over after that. I’ll post a similar comment once that’s done.

1 Like

@lftherios thanks for the feedback and additional context added on the Proposal Review call. After @bordumb 's changes above, please also allow me to add my point of view as well here:

With the additional context you shared on the November Proposals review call, I think this is already in line with how we were planning things, because there is one important differentiating factor between this proposal and the other 3 org proposals for 2024:

The Grants Org would have budget to assign to the Grantees (e.g. my team), but it is still up to the Grants Committee to assign / approve this budget during the year (e.g. on a quarterly basis), based on where things stand at the time.

So, from my point of view, assigning this particular budget to the Grants Org:

  • does not mean the budget is already available to the Grantees - we would still need to submit Grant proposals throughout the year and have those approved by the Grants committee, as has been the case so far,
  • does not necessarily mean we’ll use the budget to build the tools mentioned above, because:
    • the onboarded communities might require others,
    • we’ll discover different needs in collaboration with the Radicle core team (and submit Grants for that),
  • does not necessarily mean this budget will even be used up completely (in the worst case that “radicle 1.0” is delayed for months and somehow isn’t shipped, the Grants committee can simply reject these proposals).
  • on the other hand, having this budget assigned to the Grants Org is a strong indication that there is some budget available for us to sustain a team that has reliably been taking on (and delivering) grants in the past 18 months. To echo (and amplify, if I may) the point that @bordumb made on the call, sourcing software engineers
    • of some seniority, so they have the capacity to contribute individually,
    • that are comfortable working in open source,
    • to contribute in a less-than-part-time capacity, when they already have a full-time job (and a life outside that),
    • in today’s market of high demand for engineering talent,
    • in a risky (pre-alpha) project,
    • that pays in crypto

… has been nothing short of challenging for me personally :sweat_smile: and also, if I may say so, less than optimal for the work itself.

Having at least some of us in a more full-time capacity (through longer-term grants, always approved / overseen by the Grants committee) would be considerably more efficient and, I think, beneficial for everyone:

  • we can put more of time into Radicle: less context switching, more dedication/focus,
  • the Radicle core team can focus on the protocol / core product itself and not worry about everything else that falls a little outside that scope and they don’t want to focus on - but is still necessary to build a complete offering around the forge,
  • the Radworks community (that pays for this) gets good value (our rates are not more expensive, in fact the opposite - despite the on/off nature of the work) and more efficient allocation of capital.

Apologies for the long text, I just wanted to also try and capture the Grantee point of view on this proposal and ensure that Radworks token holders who will be voting have also heard our side of the story as well… : )

Thanks for your time, support and feedback !

2 Likes

Thank you for taking the time to address my concerns @bordumb @yorgos.

Thank you for addressing my main concern. I will be supportive, but I believe it would be beneficial for both the grants committee and the grantees to prioritize integrations based on user feedback as the year unfolds.

I totally understand and this makes total sense. I think the project will benefit from having your team focus on Radicle.

I think allocating 25k USDC makes more sense to me, but I still believe that it would be beneficial for the grants committee to have a concrete idea of the objectives they aim to test, learn, or achieve with that allocation. This is the aspect I find lacking currently and why I initially had reservations about the original allocation.

1 Like