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

👩‍⚖️ Governance ⚡ Proposal Drafts
1

Grants Org Proposal 2024

Note: this is a V2 after feedback on the proposal 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 development that enhances, expands, and enriches the Radworks ecosystem. This includes Radworks-specific third-party integrations, tooling, and alternative interfaces, as well as mission-aligned free and open-source projects.

Our Grants budget is:

  • 250,000 USDC
  • 100,000 RAD

Please see the “Timeline & Budget” section for more details on how funds will be allocated.

image
image1920×1080 217 KB

Radicle Developer Tooling

The Radicle Developer Tooling (RDT) emerged from the 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 which supports easier user onboarding (i.e. quicker adoption) as well as user retention.

The funding for the RDT team is an interim stopgap until they find further funding via their own upcoming Org Proposal from Q2 2024 - onward.

Roadmap

IDE Plugins

:test_tube: Hypothesis: IDE plug-ins with the most popular IDEs will help developers feel more comfortable integrating their existing workflows into the Radicle ecosystem. This will help with user onboarding.

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.

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

Planning Boards

:test_tube: Hypothesis: Planning boards will help teams better facilitate work. The existence of planning boards will help with user adoption by showing potential users that more of their workflows can be supported within Radicle. And this should also help with user retention by keeping users plugged into Radicle across the lifecycle of their projects.

One of the missing features that has been highlighted by every single team that is has moved their daily workflow to Radicle is some kind of board view of their backlog items, so the team can better plan their work and roadmap.

This has been highlighted by:

  • @zlatan by the Radicle Heartwood team,
  • @daniel from the Radicle Web UI team and
  • … Yorgos’s own team, as that has been something we have still not been able to migrate to Radicle from GitHub, as explained here in more detail.

As this is not on the Web team’s priorities / roadmap for 2024, an early prototype has been developed, as a kind of proof-of-concept of how we could independently work on a separate web app that could be integrated as part of the web interface and offer this missing functionality.

The prototype is available here. More info and stakeholder feedback on zulip.

CI Integrations

:test_tube: Hypothesis: CI integrations will ensure that Radicle can handle developers’ end-to-end workflow without needing to continue relying on other tooling. This should help with user acquisition and user retention.

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.

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.

Budget

The total budget for roadmap outlined above is estimated at 150,000 USDC.

Any unused budget will remain with the Grants multi-sig.

The Radicle Developer Tooling Team (Yorgos, et al) 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. Apart from team wages, the budget also includes 25K USDC of yearly operational costs and 20K USDC to fund the team’s participation in Radicle offsites.

Reporting

The Grants Committee will oversee the progress of the Radicle Developer Tooling Team. The team will be required to:

  • Submit quarterly applications that outline specific milestones and updates on current progress
  • Receive quarterly approval from the Grants committee for continued funding
  • Participate in the reporting to Radworks during the quarterly community calls (independent to the Grants Orgs updates)

The Grants Committee will be responsible for reviewing the team’s progress with representatives from the Radicle Org on a quarterly basis. This is to ensure that the team’s proposed quarterly objectives are in alignment with the Org’s roadmap & goals.

Note:
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.

Grant Categories

Grants can be funded retroactively (i.e. paid out after a product is already finished) or proactively (i.e. paid out before work is started).

All grants will be streamed to grantees via Drips.

Radicle Developer Tooling

This category focuses on projects that develop tools and integrations to enhance user’s experience with Radicle and/or Drips. The aim is to improve the interoperability between different software systems, streamline workflows, and provide utilities that aid in development, deployment, or monitoring. This could include developing plugins for popular platforms, creating APIs that connect disparate systems, or building tools that simplify complex processes. The emphasis is on making Radworks’ technologies more efficient and user-friendly.

Budget

150,000 USDC or 60% of the grants budget.

Alternative Interfaces

This category is aimed at funding the development of new interfaces for interacting with Radworks’ technologies, with a focus on increasing client diversity and enhancing technical resiliency. The goal is to broaden the appeal and accessibility of Radicle and Drips by encouraging a variety of use cases and user bases.

Budget

100,000 USDC or 40% of the grants 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)
  • Nader (Aave/Lens, DevDAO founder)
  • Nas (ex. Safe, ex. Radworks)

Member Responsibilities

  • Recruitment of Grantees: engage with core teams (Radicle, Drips, Governance) to create requests for proposal (RFPs) that address peripheral needs of core teams, which will be the foundation of grantee work.
  • 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

Members will be expected to participate in recruiting new grantees via RFPs directly from core teams (Drips, Radicle).

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.

In the case of committee members departing, we will use OtterSpace Badges to vote new members in. Voting will be available to any Radworks member and grantees who have completes >3 grants.

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 & 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.

The Grants lead (Bordumb) regularly gives updates on current and prospective grantees in all quarterly community calls and provides written quarterly updates on community.radworks.org.

Each grant-funded team will present quarterly progress seperately to the Org Lead as part of the quarterly community calls. They will also provide written quarterly updates on community.radworks.org.

Radicle Developer 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

Stand Ups

Bi-weekly.

Reasoning & Analysis

Radicle Developer Tooling

The primary goal with Radicle Developer Tooling (RDT) 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.

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.

image
image1920×1080 159 KB

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

Retrospective

Timeline & Budget

All costs will be spread out over 2024.

USDC

250,000 USDC for Grants

Breakdown:

  • 150,000 for Yorgos’s team
  • 100,000 for other grants work

RAD

100,000 RAD

Breakdown:

  • 70,000 RAD for other grants work, where grantees are willing to take RAD
  • 30,000 RAD for Grants Committee invoices

The analysis for 30,000 RAD for Grants Committee invoices is as follows:

  • In 2023, the Grants Lead received 52,000 USDC worth of RAD (see here, here, and here)
  • Over the past 2 years of Grants, we have been paying committee members based on hours of work. In analyzing this data, the Grants Lead has worked 7.5X more hours than others.
  • Overall, we’d like to keep the “management fee” within 7-10%.

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 funds 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

2

I don’t think it’s the job of a grants program to fund full-time teams.

I am not likely to vote for anything beyond 250K. The product ecosystems this grants program is funding are still unproven, and the value delivered by previous grant cycles is also still to be determined.

Before we allocate this kind of money for grants, we should determine that we’re able to get that amount of value out of a much smaller allocation. I don’t see this being the case yet.

3

How do you think that transition should happen? Presuming we’re talking about the Radicle IDE team that has spun out of grants, what’s the path for them to become a core team? Should they be enveloped by the Radicle team or should they become a separate core team that integrates tightly with the Radicle team?

I think this is a valid point, but brings up the question of how grant teams evolve and how we can foster them into core teams that don’t just contribute to the ecosystem but become a core part of it.

I’m curious to hear an elaboration on this point. In what ways have you seen unproven value? How can we improve the value of the grant system if it’s lacking?

Personally, I find it hard to determine the usefulness of the work by the Radicle IDE team because I don’t use VSCode (I use Emacs) and so I don’t get any insight into its use. That doesn’t mean it’s not useful since VSCode is a popular editor, so others might find it useful. For me, this brings up the want for tighter input and feedback between core teams and grants. Should core teams be more involved in grant applications and work? Should core teams be defining scoped work for grants? Should we be supplying mentors to those teams? etc. All that said, maybe this tighter relationship exists and I’ve missed out on it :slight_smile:

1 Like
4

Hey @bordumb thanks for the proposal! Exciting to see the newest version on the forum! :sparkles:

Given the new proposal looks a little different than the previous version, it would be helpful if you could summarize the main differences between this proposal and the previous version of the proposal somewhere just to make them easier to catch for reachers. It seems the main difference is the establishment of a “Team” within the Grants Org around Yorgo’s team to recognize and support a mulit-grant recipient dedicated to continue contributing to one of Radworks’ technologies (Radicle). Any other major difference that might be helpful to highlight for readers?

A few comments & notes from my side:

Is this meant to be “Other Grant Categories”? Based on the subcategories, it seems so. It might be helpful to clarify this header so it is easier for folks to track this back to the image you have at the top of the proposal showing all the different categories. I like how you broke down the budget distribution here in more detail, really helpful.

The establishment of “Teams” within Grants seems to make sense to encourage trusted and dedicated teams to continue to contribute to Radworks. It gives a name to teams such as Yorgo’s team who have received multiple grants, are trusted community members, and are dedicated to continue to contribute some of their time and efforts to bettering Radicle. As they are contributing specifically to an existing technology/Org, it makes sense IMO to have this distinction between a Team and and Org (and normal Grantee & a Team). How you describe a Team within the Grants Org is also similar to how Committees within the Foundation Org work, and fits the definition of how a Team is defined on the Radworks docs pages:

Screenshot 2024-01-05 at 09.45.18
Screenshot 2024-01-05 at 09.45.18695×460 189 KB

Maybe not critical to include in the proposal specifically, but would love to see even more efforts to continue the decentralization / increase community participation in the Grants program for 2024. Currently, past grantees are able to signal support for/against new grant applications via off-chain polls using Otterspace badges, but I would love to see this expand even more - maybe even to include members of the Radicle & Drips Orgs, especially as a large portion of the grants will be dedicated to contributing to their technologies. Super happy to support you in this effort in any way possible!

1 Like
5

Hey @cloudhead, I also would like to understand better how you envision the evolution of teams - like Yorgo’s team - from dedicated & trusted grantees to core teams within our ecosystem?

I think it is a valid point to bring up in the case of Yorgo’s team specifically, as they are largely contributing to once specific Org (Radicle). While this is an interesting discussion to be had, I want to highlight that, given the current circumstance, it has been made fairly clear that if Grants does not receive funding to support Yorgo’s team in 2024, they will most likely stop contributing to the project all together, which would be a big blow. I see where you are coming from, but curious to hear your reaction to that potential reality.

Are you referring to the work planned for the Radicle Developer Tooling team or the entire grants program in general here? Can you elaborate on what parts specifically you see as unproven? Could you also please explain on how you settled on $250k?

I think it is pretty clear across the industry that having a healthy and substantial grants program is so important for community health and growth. It allows for other talented and motivated folks to contribute to the project and be rewarded for those contributions, which incentivizes further contributions - bringing more value and growth - and so on.

I understand that it can be hard to calculate exact value output of contributions, or it can take time to realize the full value. I agree with Fintan that this highlights a need for tighter feedback and input from Radicle & Drips into the Grants program going forward. It think what has been proved though is that building these trusted relationships with external teams through Grants is a great way to incentive good teams to continue contributing to Radworks. It is clear we need to discuss better processes/policies for how to onboard these teams into the ecosystem going forward, but it also would be a shame to see our first example of this phenomenon with Yorgo’s team fall away if this proposal doesn’t pass.

4 Likes
6

Hi @bordumb,

Thank you for this proposal. I really appreciate the way you’ve laid out the work, the rationale for the work, and the costs (even making market comparisons where possible).

@cloudhead It sounds like you’re getting caught up on this new notion of “Teams” as defined by the Grants Org. As I understand, it’s just a way for them to internally differentiate between Grant Recipients that have been awarded multiple grants and should trigger different kinds of review and feedback - versus first time grant recipients. “Teams” does not equal “full-time”. How a “Team” is organized should be up to the Grant Recipient - do you believe token voters should dictating how a set of contributors working on shared objectives within an Org must organize itself? So far, Radworks voters have been keen to move away from this sort of micro-management. What I think Radworks voters should be focused on is what is being funded (prioritization) and its cost (ensuring alignment with the prioritization).

Which brings me to:

When you say “The product ecosystems this grants program is funding are still unproven, and the value delivered by previous grant cycles is also still to be determined” - do you mean that the previous work done by the Radicle Developer Tooling Team is unproven? What needs to be done to prove the value of their work?

Since you are a key stakeholder and your vote is important, knowing your “250k” threshold is helpful - kind of. But what I’m missing is clarity on how you got to this number and, therefore, what “value” should be prioritized in order to scope the objectives of the Grants Org and, specifically, the Radicle Developer Tooling Team. Can you provide some input here? Does the “250k” you mention apply to the the Radicle Developer Tooling Team only or the whole Grants Org proposal?

To answer this, @cloudhead @fintohaps @zlatan @daniel @rudolfs I would want to hear about who are the users of Radicle v1. To @fintohaps’s point, for example, do they use VSCode or Emacs? Then, based on knowing WHO the users of Radicle v1 are, we can better identify and prioritize the Radicle Developer Tooling that should be built to ensure easier adoption of Radicle v1 when it launches (or with v1.1 or v1.2 soon after). Otherwise, I’m concerned that waiting to see what users simply “come” to Radicle v1 when its launched, identifying their characteristics and needs, and then building the tools to make it easier to onboard slows down the adoption process immensely and we lose the momentum of the launch. @lftherios Maybe I’m out of touch with the work going on - I know you’ll be doing some work here for the Radicle Org related to user outreach, so I would also be interested in hearing your thoughts here.

I have perhaps a similar question coming from a different perspective: what “value” do we agree is worth funding to 1. support a successful launch and adoption of Radicle v1 and 2. assuming the successful launch and adoption of Radicle v1, diversify and grow the user base of Radicle in 2024? I’d certainly welcome the input from @yorgos and @cloudhead.

@bordumb The “Technical Implementation” section refers to the “Radicle Foundation.” The Radicle Foundation will not be transferring funds to the Grant Org. All funds will be transferred from the Radworks Treasury.

I really like the idea of supporting alternative interfaces to Radworks’ technologies - while Radworks protocols are open source and can be interacted with directly by ANYONE, additional interfaces will enable more users access the protocol in more ways, diversifying and growing the use of the protocols (esp the Drips Protocol). @lftherios Based on your experience working with other projects who want to build on the Drips Protocol, can you offer @bordumb any thoughts on how to identify grantees for this sort of work?

4 Likes
7

I don’t think it’s the job of a grants program to fund full-time teams.

I think we might be debating over semantics (calling them “teams”) on this one.

The long-term idea is not to be a central manager of full-time teams.

I realize this distinction is perhaps not prominent, but I want to draw attention to this sentence:

The main goal of maintaining an ecosystem grants program is to attract & onboard contributors to the Radworks ecosystem.

The idea here is to create a gradual “funnel” through which we can onboard contributors gradually.

image
image1920×1080 123 KB

So with the 2 grantee categories:

  • New Grant Applicants: a space for brand-new grantees - who we have a lower level of trust with - to begin contributing on smaller, one-off projects
  • Teams: for lack of a better term, these are “groups” who have a high level of trust within our ecosystem, currently don’t have a place on a central team or their own Org, but who can provide valuable contributions to the ecosystem. The idea is that these groups will eventually find space on a core team or their own Org.

But I have a feeling we are either somewhere on the same page or can meet in the middle if not.

Let me know what you think.

I can make this more explicit so that we have it in writing.

Before we allocate this kind of money for grants, we should determine that we’re able to get that amount of value out of a much smaller allocation. I don’t see this being the case yet.

To play devil’s advocate on this point:

Imagine you are on a call with a team interested in using Radicle. Aside from the core workings of the protocal, what are some of the first things they will be interested in?

Some of the answers to this question are in the Radicle Org’s 2024 Proposal “Objectives”:

  1. Improved issue management options
  2. Support the integration of third party CI platforms
  3. Implement Radicle notification system (stretch goal)

Each of these map directly to several items on the Grants Proposal:

  1. Planning Boards
  2. CI Integrations
  3. IM Integrations

Request for feedback

@cloudhead:
To some degree, disagreeing funding this Grants work feels like disagreeing with some crucial parts of Radicle Org’s own proposal. Clarity around the thinking here would be great.

My 2 cents

The Radicle Org is addressing the points above at the protocol level.

Nowhere in the Radicle Org’s Proposal is there mention of actually building out those 3rd party integrations.

This creates a significant gap for anyone teams we try to “sell” on Radicle.

The idea here is to fill those gaps via Grants, especially leading into and following the launch of v1.0. The aim is to make it that much easier to “sell” Radicle to teams.

In a previous life, I worked in software sales for B2B software, so somewhat analogous to what we’re building here. The first thing I would do here is give feedback to the engineering teams to make sure that these integrations are at the ready to make “selling” the software easier.

I am of the opinion that we will be missing a big opportunity to do so if we do not allocate budget to address work on 3rd party integrations.

Request for feedback

I am not likely to vote for anything beyond 250K. The product ecosystems this grants program is funding are still unproven, and the value delivered by previous grant cycles is also still to be determined.

@cloudhead:
If we are absolutely deadset on the 250K number, direct feedback that pinpoints which projects in the current proposal are most worth funding (i.e. Is it CI? Is it issues management? Is it IDE plugins? etc.)

A stack-ranked list might be best.

Your input is invaluable, so any guidance much appreciated :slight_smile:

2 Likes
8

I think grantees who want to transition to a team should simply apply as a team, like radicle and drips. They can then be evaluated via the same mechanisms as everyone else.

By not seeing proven value. I’ll elaborate on the specific case in reply to bordum, but without seeing something like: “grant 123 brought N users to ” (or some other clear value), I’m going to posit that it’s too early to be spending this amount of money on grants.

I think we’re doing things the wrong way around. Grants team budget shouldn’t be the sum of all grant requests for the previous year. Grants budget should be set upfront based on what we can afford for grants, and then using that budget, we can fund teams that apply for grants.

Total grants budget for 2024. I see the grants program as unproven with respect to the amount spent on it. I couldn’t find the exact numbers, but I would not say that we got $1M-$2M of value out of it so far, which is probably what we spent.

$250K is just a number that seems right based on the funding radicle and drips received.

9

That’s fair, but it was included in the grant proposal, so I commented on it. In the end, the amount requested is the main issue.

I think this is the part I can agree on, but again, the issue is the amount requested, not the work being done by grantees.

I would be much more comfortable offering smaller grants that match the current phase of the project, eg. in the $10k-$50k range.

As for potential gaps we will have, I agree with:

  1. 3rd party CI integration
  2. Github migration tools

Other than that, the important work we need to do is much more involved and may not be ideal for a grants program.

10

Let me start by thanking everyone for listening to our call and putting your valuable time into reviewing this proposal! :pray:




Personally, I have no problem whichever way we go (and definitely no problem with being evaluated via the same mechanisms as everyone else!). This was just proposed as the smoother transition path and … here we are. :upside_down:




@cloudhead To be fair, isn’t this something completely new being introduced here? Have we ever prioritised any other Radicle features based on “proven value” ?

Considering the proposal and budget under question here is for specific “Radicle features”, it seems a little bit strange why we should be applying the “proven value” only for these ones but not for any others, no? i.e. shouldn’t we be applying it for all or none at all ?




A couple of comments, about each of the excluded ones:

  1. Planning Boards

I am curious as to why the planning boards is not included in the list, considering this all came up from direct user feedback: the lack of a kanban-style board is already preventing users from moving their issue management / project management to radicle. (@daniel , @zlatan , @stellarmagnet and my own team - at which point, we decided to finally scratch our own itch). Is that not enough feedback to act upon?

  1. Notifications / Instant Messaging integrations

Also, with regards to the exclusion of Instant Messaging (IM) from this list, and keeping into account that the Radicle Org will probably not get round to Notifications in 2024 (the Radicle Org proposal only states it as a stretch goal), can I ask you all:

Will any teams even consider onboarding to Radicle (allowing Radicle to find product market fit, which is our collective goal for the year anyway) when they never find out about anything that happens on Radicle (leaving each other comments, with no notifications) ? Isn’t this limiting the entire solution to just solo developers, if that ? (imagine a user opens an issue or contributes a patch on your repo and you never find out about it…)

  1. IDE Plugins

Finally, about the IDE plugins, I do understand that since some of you don’t use an IDE, you probably don’t see its value - and I am not looking to convince you about that at all. But doesn’t the majority of developers use them ? Isn’t that enough to justify this work, especially considering we are ramping up for public release already in Q1 2024 ? :thinking: As far as I know we are not targeting any specific segment of e.g. command-line only users…

Also, just for everyone to be aware of, during the recent community call “code review” was highlighted as one of the areas that will be entirely missing in V1, but we already have this working in the Jetbrains suite of IDEs, so I think there’s a case to be made that these already complement the overall offering of Radicle and it makes sense to keep working on this (and also bring the same inside VS Code, in 2024).




So, from my point of view and experience, the funding that Radicle received is regrettably not enough to get us to product-market fit.

I look at the budget and the 2024 plan and I think: even if the Radicle Org completes all its goals this year and delivers what it planned, is there enough there for open source communities (that Radicle should primarily be targeting, In My Humble Opinion (IMHO)) to migrate to Radicle? Regrettably, the answer is no and the fact that we basically have 0 external users right now and - as per the recent community call - very little idea about which our first target users are, is, I think, a very good indicator of that.

To mitigate that, we found specific areas that the Radicle Org isn’t touching yet (and that our own migration to Radicle was/is blocked on) and we are proposing that we work on these alongside the Radicle Org, so that we can complement the overall offering by removing blockers for onboarding teams.

Which leads me onto:




@everyone If the work we are doing is not the issue (thank you for acknowledging that, btw @cloudhead :pray: ), and we already have early signs of these onboarding blockers then I, for one, am failing to see why this budget is a problem.

I can, of course, not be objective here, but I do care and have a stake in Radicle succeeding. This proposal is our approach at clearing these obstacles before others also stumble on them - further delaying user onboarding and PMF in general.

Considering that 2024 is potentially a make-or-break year for the Radicle Org (as per the Memorandum of Understanding with the Radworks community that states that the Radicle Org might even dissolve), I am inviting everyone in the radworks community to vote in favour of this proposal and help us all get back to building :tools: and focused on getting radicle into the hands of users :ship: .




Additionally, a request, if I may:

as soon as you know which way you will be voting, it would help if you could signal your voting intention on this proposal.

Even if you will not be voting in favour (as is your right, of course), we would appreciate the courtesy of knowing that earlier, as opposed to later, so we know what’s coming.

Thank you all for your time and constructive feedback! :vulcan_salute:

7 Likes
11

I think there is some confusion on terminology here. “Teams” and “Orgs” are two different things.

An ORG is an independent organization that serves the Radworks purpose by building new, resilient and permisionless technologies.

A TEAM is a group of contributors that contribute to the development of an ORG and receive funding and operational support from an Org.

As Yorgos’ team (in their contributions to Radworks) is not building its own new technologies - but rather contributing to the development of Radicle, and existing Org, it makes it a very clear “Team” case rather than an “Org.” Please see the Ecosystem page on our docs site for more details.

12

It seems that this discussion has highlighted the need & desire for the establishment of a better / more consistent way to measure “value” of contributions - certainly within Radicle, but also ideally across Radworks. I believe this will be a longer discussion and will require more time to find a path forward here, but is definitely something we can try to prioritize through 2024. I suggest we start a thread on the forum to share ideas and ways to figure out what plan makes the most sense.

One comment I will share regarding measuring the “value” of contributions from @yorgos’ team specifically: As they are focused on developing tools and integrations that will make onboarding to Radicle a lot easier/more attractive, it will be easier to assess the value of the contributions once Radicle 1.0 launches and more folks try to play around with it. I think it would be smart to plan some sort of feedback process into the Radicle 1.0 launch to really try to capture and measure how valuable these contributions are to users who are trying out 1.0. This seems like a simple way to start measuring value here.

4 Likes
13

I suppose the question then becomes, “Why is it that Grants is the Org that is funding the Radicle Developer Tools team?” This is something we discussed on the call yesterday and looking forward to fleshing these ideas out more :slight_smile:

1 Like
14

@fintohaps there is a lot of feedback that by now we can move to a separate org, but at this point in time there isn’t enough time to prepare a brand new org proposal for this month’s voting cycle, so the plan right now is to get a little bit more funding through Grants Org to give us time to transition out.

Whether to a new org, or to the Radicle Org is not so important to me - I see it more as an implementation detail. At the end of the day, the money is coming from the same place (Radworks community) and is going into building the same thing. Each of the two options would require changes and new proposals to be passed. Our two teams are already working very closely and, at least on my side, I’m very happy with the level of support we’re getting from the core team, so it’s not like this is somehow keeping us apart, or anything like that.

Considering that our group is focusing on slightly different deliverables of the overall Radicle forge roadmap, perhaps the separate org might allow a clearer separation / evaluation of those by the community.

… but I think this is already getting a little out of scope of the current Grants org proposal, so maybe we can keep this discussion to be had in the new org proposal as soon as that comes round.

1 Like
15

Sorry, yes. When I stated this I implied that the “fleshing these ideas out” is out of scope of this proposal itself and something we’d discuss elsewhere.

I’ll be re-reading the proposal and the comments before stating how I’ll vote (as long I don’t mess up the voting process :P)

16

Based on feedback above, the main changed above are:

  • Reduced budget again to 250K USDC & 100k RAD
  • Reducation in scope for the Radicle Developer Tools work to reflect the reduced budget and shorter timeline
  • Changes to committee/OS badges

We will be posting this as a formal discussion on Monday (Jan 15) and Snapshot vote.

So please leave any last feedback as soon as possible.

Thank you!

1 Like
17

Hi all!

Apologies for the delayed response here, I was on vacation. I’m happy to see that we’ve been able to reach a consensus on a path forward. I wanted to drop some general thoughts here and call out some next steps I think we should take…

From this discussion, I see there being three main questions/themes that need to be addressed:

  1. What’s an Org? How does the Radworks ecosystem support the emergence and growth of development teams outside of our current Orgs? Which teams should remain grant-funded, which should become Orgs? Why?

    By dedicating time to defining what Orgs are, their purpose, and their role in fulfilling the Radworks mission, we can gain a deeper understanding of how to effectively guide and nurture emerging contributors within the Radworks ecosystem.

  2. What is the role of the Grants Org in the Radworks ecosystem? As @bordumb wrote, the “goal of maintaining an ecosystem grants program is to attract & onboard contributors to the Radworks ecosystem”. I think this process has made us realize that this can be interpreted in multiple ways. For example, it can mean contributors developing new technologies (e.g. other than Radicle and Drips) and/or contributors developing around Drips and Radicle. By further clarifying what the ideal end-state is for new grantees from a Radworks perspective and what is needed from grantees from a Radicle & Drips’ perspective, we’ll be able to specify this :point_down: diagram with criteria and expectations that will make it easier for the Grants Org to coordinate their objectives and allocate their budgets.

    image

    As @fintohaps pointed out, this will help us decide if a tighter relationship between our product Orgs and Grants is necessary. If the goal is to onboard new contributors to the Radicle and Drips ecosystems, should Radicle and Drips be be scoping work/RFPs for the Grants Org? Should they be supplying mentors? Should they be reviewing applications? After clarifying the goals of the Grants Org and its role in the Radworks ecosystem, we can revisit these questions together and ensure that the Grants Org is being set up for success and maximum efficiency.

  3. What work currently lies outside the purview of Radicle and Drips purview that can (and should) be effectively taken on by external teams? It seems like there are differing opinions about what work is required when and why. In Radicle’s case, even though it seems we agree that there’s value in “filling the gaps” with Grant-funded work to support adoption and onboarding of Radicle v1.0, we’re having trouble figuring out what work should be prioritized and when. I believe this is because Radicle Org is lacking a clear “go-to-market” plan for the Radicle v1.0 launch that identifies target users, communities, and organizations. Having a collective sense of who we want to onboard to Radicle will give contributors like @yorgos and co. a better idea of what to build and when. We all want the same thing: get people using Radicle. I believe adding some structure and approaching the GTM problem collectively will make it easier for a healthy open source ecosystem to form around the Radicle Org.

In terms of next steps, I think it would be a good idea to collectively focus on #1 and #2 while the Radicle Org ships Radicle v1.0 and @yorgos and co. focus on their upcoming grant work (Radicle CI Integrations - #4 by yorgos — Exciting!). I think the best way to move forward is to start a new post diving into these topics and host a group call to discuss. @shelb_ee and I will take lead on that. After that, we can revisit Radicle Developer Tooling specifically and strategize on what is the best way to support this work moving forward.

I appreciate everybody’s patience and participation in this discussion and the one previous :seedling: Looking forward to seeing this proposal make its way the Submission phase next week.

3 Likes