[Discussion][RGP-18] - Radicle Org Proposal 2024

Radicle Org Proposal 2024

Author(s): cloudhead
Type: Org
Created: 2023-11-03
Status: active

:memo: This is the official discussion post for the 2024 Radicle 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.


The Radicle Org aims to develop a fully-sovereign code collaboration stack called “Radicle”.

Radicle is designed to be a secure, decentralized and powerful alternative to
code forges such as GitHub and GitLab while preserving user sovereignty and freedom.

Specifically, Radicle attempts to address the following problems:

  • Platform risk
    • GitHub and others have been known to censor projects as well as shutdown developer accounts (eg. youtube-dl)
    • GitHub is closed source and its ToS allows them to change and remove functionality at will.
    • GitHub and others create lock-in via their non-git features, eg. issues, pull requests etc.
    • GitHub trains Copilot on user data without consent.
    • GitHub and others can choose to monetize any feature at any time, requiring users to pay for something they weren’t paying for before.
    • GitHub and others are built as monolithic platforms that are not adaptable and changeable by users.
  • Open access
    • GitHub and others are not available in all countries due to trade embargos and require an account
      for interacting with the platform.
  • Privacy
    • GitHub and others have access to all private user repositories.
  • Data ownership
    • GitHub and others own their user’s data and this data is not part of the git repository, hence it cannot be migrated.
  • Security
    • By not using cryptography, GitHub’s security model allows hackers and/or employees to forge user data
      without evidence to the user.
  • Availability
    • When GitHub or GitLab are down, there is no possible access to the service. Only the source code remains accessible.

By providing the following solutions:

  • Users are able to run their own nodes without reliance on any third parties. They cannot be de-platformed.
  • All social artifacts (eg. comments, issues etc.) are stored in git, and thus easy to migrate, backup and
    access both online and offline. Users own their data.
  • Radicle is always available, since it is local-first. Users don’t need internet access to carry out a majority of tasks.
  • Radicle uses public-key cryptography throughout the product and protocol, removing the need for trust in third-parties.
    Every social artifact or piece of code can be verified by anyone.
  • Radicle plans to add end-to-end encryption to git repositories, protecting all user data from third-parties.
  • Radicle is open source and permissibly licensed.
  • Radicle is censorship resistant: any node on the network can choose to host a radicle repository and make it
    available to others.
  • Radicle is an open protocol that can change and adapt to user needs and a changing world.

Annual Strategy & Quarterly Objectives


  • Improve and stabilize the Radicle stack
    • Improve and extend Radicle Patches
      • More advanced code review workflows
    • Improve and extend Radicle Issues
      • Improved issue management options
    • Build out Radicle CI/CD
      • Implement Radicle “native” CI
      • Support the integration of third party CI platforms
  • Stabilize and improve the Radicle network protocol
    • Implement hole-punching
    • Optimize performance
    • Improve new Git fetch protocol
  • Improve the Radicle CLI
    • Improve user experience: auto-complete, documentation, errors, help etc.
  • Improve the Radicle web interface
    • Feature parity with the CLI
  • Implement Radicle notification system (stretch goal)
  • Implement Radicle user identities (stretch goal)
  • Create a great onboarding experience for users
    • Launch docs website
    • Launch Radicle guide
    • Revamp website
  • Onboard users, communities and teams to the Radicle stack
  • Gain a better understanding of what features are missing to onboard more users
  • Gain a better understanding of what users or companies might want to pay for
  • If we succeed at these previous goals, convert some of these users to paying customers


  • Q1: Launch Radicle 1.0
  • Q2: Start onboarding users
  • Q3: Continue stabilizing and improve the Radicle stack
  • Q4: Start experimenting with paid offering, given product-market fit

Organizational Structure

Legal structure

Corporate entity (Sárl) based in Switzerland, with @cloudhead as managing director.

Core Contributors

  • @cloudhead – project lead – full-time
  • @zlatan – project & community management – part-time
  • @rudolfs – software engineering on web – full-time
  • @sebastinez – software engineering on web – full-time
  • @erikli – software engineering on heartwood – part-time
  • @fintohaps – software engineering on heartwood – full-time
  • @lars – software engineer on heartwood – full-time
  • @daniel – product designer on web – part-time
  • @arastoo – software engineer on heartwood – part-time
  • @sllyllyd– operations – part-time

Support from

  • @geigerzaehler – software engineering on heartwood and radicle-interface
  • @stellarmagnet – content and strategy


Reporting & Success Criteria

The 2023 critertia still applies:

  • Number of repositories published on the network
  • Number of nodes online
  • Commit activity on published repositories
  • Social activity (patches, discussions, issues, etc.)
  • “Key” projects using Radicle
  • Number of members on Zulip
  • Number of contributors to core stack

For 2024, we also add:

  • Stability of the network, reduce breaking changes
  • Number of onboarded open source projects
  • Team member hours paid by project income, if any

Through Q2 2024, the Foundation Org will provide monthly financial
reporting to Radworks on behalf of the Radicle Org. Starting in Q3 2024,
the Radicle Org will publish monthly financial reports on Radworks-granted
funds spent by the org.

Timeline & Budget

The total budget requested for 2024 is $1,370,482.

Total costs for 2024

Description Budget
Development $1,975,448
Marketing $116,500
Offsites $52,032
Operations $26,501
Total $2,170,482
  • Development: contributor pay for a team of ~13, R&D costs
  • Marketing: sponsorships, events and some contributor pay
  • Offsites: we plan on having two offsites this year
  • Operations: accountants, Skyline digital fees, online subscriptions, legal costs & gas fees

This includes room to hire one more engineer.

Budget carried over from last year

There will be an estimate of $800,000 left over at the end of 2023.

Requested budget

$2,170,482 - $800,000 = $1,370,482

Fund management

  • DAO funds will be received on a 3:2 multisig (Safe)
    • @cloudhead as signer (two keys)
    • @sllyllyd as signer
  • Funds to be paid in fiat will be paid out by Skyline Digital.
  • Payouts will be done by operations on a monthly basis.

The Radicle 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.

MoU with Radworks: MoU: Radworks & Radicle Org


Is there any plan for hiring more developers this year? Does the Development budget account for that?

Hello! Yes.

This includes room to hire one more engineer.

1 Like

Hey @cloudhead (& the Radicle team) - thanks for the detailed proposal! Sounds like there are a lot of exciting developments to look forward to in 2024!!! :space_invader: :rocket: :metal: I have a few questions for you below:

Does the Radicle team not technically have the sole power to add/remove functionality currently as well? What processes/checks & balances do you have in place within Radicle that would prevent the team from being able to turn off partial or full functionality of Radicle?

In a similar vein, what processes are in place to allow user/contributor influence over protocol development or changes to the protocol?

Is this section in order of importance/urgency and therefore in order of when you plan to tackle these throughout 2024? If not, would you mind adding more detail around when (what quarter for example) you plan to tackle each of your objectives?

What are some features or services you are already imaginings users would pay for? In the Radicle<>Radworks MoU, you mention “the ideal end-state for Radicle is to exist as a fully community-driven open-source project that is supported by a handful of organizations and users who pay for support, hosting or licensing.” Would you be able to elaborate here a bit?

Related to the above: Have you thought about how you will plan to price these services? Also, who will be involved in deciding what those fees will be?

More of a comment - but it has really been great to see Radicle talks and folks from the Radicle team pop up at more events & conferences recently! It was awesome to watch a bunch of devs join the Radicle onboarding workshop hosted by @sebastinez & @erikli at Protocol Berg in Berlin this year and be really excited about trying out the new Heartwood protocol! I hope to see this trend continue in 2024! :slight_smile: Do you have any conferences/events already on your calendars for 2024?

Really great to be seeing focus (in 3 out of 4 quarters, If I Understand Correctly (IIUC)) on the general go-to-market strategy and on onboarding communities and service providers !! :clap: :partying_face:

I guess the stretch goal here is some new way to approach notifications, on top of standard email notifications, right?

(Asking because email notifications seem like a must-have feature to me - without that, we’d be missing the most standard way to notify each other when we’ve left comments on issues / patch reviews, etc. And, yes, the IM tooling integrations that we’re proposing can help, but I don’t think those replace email… )

In terms of 2024 roadmap, and considering how much of an impact AI Coding Assistants have already had in the industry in such a short period of time, is that an area you are thinking of focusing on ?

GitHub CoPilot is significantly re-inforcing Microsoft’s vendor lock-in, so I was wondering if you’ve considered some kind of partnership with some open source project in this area, or have any other idea in how folks could break free from GitHub there ?

1 Like

Thanks @shelb_ee !

The radicle team does not have sole power over the product, since it’s an open protocol and open code base. Anyone can fork the source code, change it, and run the modified product or protocol. No checks and balances are needed on our part to make that possible :slight_smile:

There is an open radicle improvement proposal (RIP) process that allows anyone to propose a change. It’s pretty basic at the moment, but sufficient. The core team can then review these proposals and approve/reject them. Of course, users can choose to implement the changes without core team approval though, since it’s an open protocol. Certain changes and additions are also possible without breaking compatibility with the existing product/protocol. In that case, no RIP is required, users can simply implement the changes and use them without approval. Examples of this would be implementing new COBs or gossip messages.

They are ordered by priority, we should be able to tackle 2-3 of those top-level objects at a time.

I think the simplest one based on what people want is repository hosting. Some users will only self host and others will choose to additionally purchase hosting services as a safety measure and for better data availability.

The important thing about the end state is that we (the radicle org) are not the only contributors to the ecosystem. Therefore the answer to the pricing question is that we will price the services competitively because otherwise someone else will undercut us. Again, being an open protocol means that we aren’t the only ones who can offer paid services.

We’ll definitely continue the trend! In 2024 there is FOSDEM and we will probably go back to some of the 2023 conferences that worked out well.

1 Like

I’m not talking about notification delivery here, that can take many forms (email, sms, push, activity pub, zulip…); I’m talking about the underlying inbox system within radicle. The notification messages in that inbox can then be delivered in various ways to users, in addition to be able to be checked within radicle.

E-mails require an email address to send from, which implies a service/server and priviledged entity (eg. a company) to pay for the domain. Therefore this cannot be part of radicle proper, but just like hosting services, can be easily offered by a third party service provider.

Not at all. I consider AI asistants orthogonal to what we’re doing with radicle. In the same way that code editors, compilers and language servers are not something we’re developing.

There are and will be many more open-source solutions to AI-assisted code editing, I don’t think it’s our business though, how users write code. Any kind of partnership would also have to be tied to the org and not the product; and I intend the product to outlive the org.


Great point to highlight - thanks.

Thanks for explaining the process in detail here! Always a good reminder for the community/users to let them know how to contribute.

Got it.

This makes sense. Are you currently supporting any projects with hosting (I guess pro bono for now)?

Exciting! Be sure to let us know on your Twitter or feel free to drop event links where Radicle will be attending/speaking at/sponsoring in the :circus_tent:events channel on the Radworks Discord so we don’t miss any! :slight_smile:

@cloudhead and Team - I’m very excited about what you all are looking to do in 2024.

I really like these key performance indicators. [Question: should “Number of users converted to paying customers” be part of these KPIs yet?]

…but feel like I’m missing a tangible vision for what “success” of Radicle looks like in 2024.

I know there is a planned launch for Radicle 1.0 in Q1 - but what (features) will determine the launch a “success”? Why not include specific numerical Objectives related to some (if not all) KPIs? And/or can you tie Objectives to the Roadmap? Something isn’t clicking for me - maybe it’s a mixture of the content’s tangibility and the proposal’s format. I have the same “what does success look like” question for the Q3 and Q4 elements for the Roadmap.

Especially regarding Q4 (“Start experimenting with paid offering, given product-market fit”), what does this mean? Do you mean “Design and test a paid Radicle offering with existing Radicle users”? And who will lead this work? I can’t tell from the contributor list.

It’s great to see these objectives. Who will be in charge of the user research with regard to the paid offering? Who will be in charge of user research in the effort to identify features that are needed to onboard more users? Will @zlatan work on this as part of their work on “community management” or do you intend on hiring other skillsets?

Thanks, @cloudhead !

1 Like

Thanks for the proposal @cloudhead! Seems like its going to be a really exciting year for Radicle :space_invader: A couple comments and questions below:

  • I do not see any retrospective published — can you please provide one? It’s hard to gauge how much of the 2023 roadmap was completed. Specifically, can you elaborate on how you performed against your 2023 criteria/KPIs (see below, taken from 2023 proposal)?

    • Number of repositories published on the network
    • Number of nodes online
    • Commit activity on published repositories
    • Social activity (patches, discussions, issues, etc.)
    • “Key” projects using Radicle
    • Number of members on Zulip
    • Number of contributors to core stack
  • How does the “Build out Radicle CI/CD” work interplay with Yorgos and co.’s proposal to the Grants Org for their CI Integrations?

Can you identify which objectives need to be completed to “Launch Radicle 1.0”? Can you elaborate on what “Radicle 1.0” is? Is it a stable release? Is it the improved UI, new docs, and website?

Seems like the bus factor is high on that multisig. Would it make more sense to have three separate signers, vs. having one signer with two keys?

Looking forward to discussing further — great work! :slight_smile:

P.S. Please link your MoU somewhere in this proposal!

It’s a great point @yorgos — I think that reframing partnerships as “integrations” could be a better way to look at it. Idenitfying more places to introduce Radicle into developer’s workflows seems like a great way to introduce more adoption.


Thank you for this proposal @cloudhead.

It’s really great to see all the progress that has been accomplished on the tech stack in 2023 and I am very excited for Radicle 1.0!

On the other side, the below strategy feels very under-developed to me with regards to community development & user research / onboarding. Specifically:

  • What kind of work did you do in 2023 there? What worked & what didn’t?
  • Is the Radicle community healthier now than the start of the year?
  • Did the Radicle community grew this year? If yes/no why?
  • What is the strategy for 2024 with regards to community development and user onboarding?
  • Who is leading that work? Who has experience with this type of work in the team? Who is contributing?
  • What is the profile of a community you want to target in 2024? What prior work has been done there?
  • Are you already in contact with prospective users? Is there a process for that internally?
  • What does success looks like here? I second @ange’s comments on this section that you will benefit from some concrete numerical goals with regards to users.

I personally think that this is the wrong strategy. Product-Market-Fit in the category that Radicle is operating in is an extremely lofty goal that will effectively be defined by user retention. Even in the best scenario that user growth goes as expected, I would prefer to see you all focus on user retention before you take on the problem of org sustainability. From my own experiences, building confidence in user retention will most likely take longer than 2024, even in the best scenario.

With that in mind, I would prefer if you all focus on PMF in 2024, rather than try to also take on another (big) problem. My subjective opinion here is that I don’t see any reason why to prioritise any paid offering this year and what material impact you hope that it can have on Radicle’s sustainability.

I also maintain my opposition to non-sovereign paid offerings, such as traditional enterprise-style options, as I believe they contradict the principles that Radicle upholds. However, I see this as a broader discussion for the future, and I’m open to providing more details if needed.

1 Like

Nope, though we do run a public node that anyone can use, but we don’t offer support on there.

Too early in my opinion.

Radicle 1.0 is meant to be the first stable release of Radicle. It is designed to be a package that includes a suite of tools that are polished and documented, as well as a stable network protocol. From a users perspective, this would be the time to try Radicle out. In terms of features, it won’t include anything major that isn’t already in Radicle. Most of the work at this stage is going to be on fixing bugs, improving existing features and improving the onboarding experience.

A successful launch would be one without major issues discovered post-release, and with the planned feature set (ie. everything currently in Radicle).

In terms of objectives relating to 1.0, it’s mainly the first: “Improve and stabilize the Radicle stack”. The 1.0 release is a milestone within that objective.

I wouldn’t know what numbers to put there at this stage, it seems arbitrary since we don’t have any real users besides ourselves right now.

It’s too early to say really, perhaps it makes more sense to remove the roadmap, as it’s really just an example of how the year could unfold. The only real milestone at the moment is the 1.0 release. The rest of the year will depend on that 1.0 release.

Again, there is no paid offering planned yet, we are focused on product market fit; and if we achieve that, we will start orienting some resources towards sustainability. That question would have to wait for that milestone to be reached to be answered.

As mentioned in last year’s proposal, these were simply metrics I was asked to provide, but were not meant as KPIs, since the main goal for 2023 was to stabilize the stack, not grow the community.

This year, things will hopefully shift towards growth, if the 1.0 release is successful.

Our work on CI will be on what we call the “Radicle Native CI”, which is our own, custom CI. Yorgos’ team is working on integrations with third-party CIs.

We’re going to be adding a 4th signer to this multi-sig, yes :slight_smile:

1 Like

I think the reason is that we don’t have a product yet that is polished enough to onboard a wider audience to. This is what we’re working on now.

In 2023 there was no planned work on community development, all work went into product development.

For 2024, we don’t have a strategy yet with regards to community, I don’t want to spend any resources on that until we have a product we’re happy with, as it would be time wasted if the launch doesn’t go as planned.

I can answer some of your questions though: in terms of user profiles for 2024, we’d like to onboard people in the FOSS/Linux community, DAOs and indiivduals in Web3 and people in the Bitcoin community, for example. Prior work there has been talking to some of these folks and getting a better understanding of what they are looking for and what resonates with them.

Success for 2024 is users moving their repositories to Radicle. I’m not sure how else I can state that, the goal of Radicle has always been to be used as an alternative code forge.

I agree, this came out of the MoU with Radworks, that’s why I included it here. My preference would be to focus only on product-market fit for 2024. However, if that is achieved, there is no harm in starting to think about paid offerings.

There can be preferences here in terms of what the Org does, but Radicle being an open protocol means that we don’t control what paid services are offered.

Does the Marketing contributor pay mean only contributor work to work on Marketing objectives or is this specifically for contributors to attend conferences, events, etc.?

For the Development budget - does this include any roles that are not engineering? For example, the project and community management role or operations role?

The past 3 months have averaged about $120k for contributor costs (roughly $1.5M USDC for the year). If we assume 1 new engineer is added at the higher end of compensation, that might be $1.7M USDC for the year. What is the plan for the remainder of the Development budget under “R&D” and feel free to provide a better breakdown than my assumptions?

Thank you!

1 Like

Does the Marketing contributor pay mean only contributor work to work on Marketing objectives or is this specifically for contributors to attend conferences, events, etc.?

It’s the former.

For the Development budget - does this include any roles that are not engineering? For example, the project and community management role or operations role?

Yes, this is all the work that is categorized as development work, and isn’t necessarily coding.

The past 3 months have averaged about $120k for contributor costs (roughly $1.5M USDC for the year). If we assume 1 new engineer is added at the higher end of compensation, that might be $1.7M USDC for the year. What is the plan for the remainder of the Development budget under “R&D” and feel free to provide a better breakdown than my assumptions?

There have been people on leave or taking time off as usual. The budget is calculated based on everyone working at full capacity, so it’s a little higher.