MoU: Radworks & Radicle Org

:memo: This document outlines the partnership agreement between the Radicle Org and Radworks. It is supplemental material for [Discussion][RGP-18] - Radicle Org Proposal 2024.

Scope & Objectives

This document defines the relationship between Radworks: a networked organization that facilitates the governance, stewardship, and deployment of the $RAD treasury, and Radicle: a free and open source software project building a sovereign peer-to-peer network for code collaboration, on top of Git. Specifically, this document describes the grant funding terms and expectations for Radicle’s 2024 operational funding of $1,370,482 and outlines expectations and processes for continued funding into 2025.

Radicle is building a fully-sovereign code collaboration stack. It is designed to be a secure, decentralized and powerful alternative to code forges such as GitHub and GitLab while preserving user sovereignty and freedom. With grants from Radworks, the Radicle Org has been working towards stabilizing the Radicle stack, getting closer to the minimum feature set teams expect from a code collaboration stack, and migrating all core team development to Radicle itself. This work will culminate in Q1 2024, with the launch of Radicle v1. Looking forward, there are many opportunities for the Radicle project to sustain itself beyond Radworks’ grants. To reduce its reliance on Radworks without impacting the project’s runway, the team will spend the next year exploring potential sustainability paths.

Taking inspiration from Rust, PostgreSQL, Git and Linux amongst others, 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. These three categories are what’s currently envisioned as Radicle’s potential paid offering.

Here are some examples of the various offerings the Radicle community could offer for a fee:


  • Migration & transfer of git repositories
  • Node setup & maintenance
  • CI/CD setup
  • Dedicated support teams


  • Dedicated nodes for customers that guarantee uptime
  • Backup services
  • Compute


  • Buy plugins and extensions to the core Radicle stack

@cloudhead will work closely with the Strategy committee to report & discuss these objectives quarterly. These discussions will be made publicly available for the Radworks community.

Radworks is funding Radicle pursuant to its purpose of funding and supporting the creation of censorship-resistant and decentralized technologies that empower builders and creators to collaborate. Radworks understands Radicle to be a core piece of Internet infrastructure that will provide an essential alternative to corporately owned technology to users globally. If Radicle is successful in its goals, open source developers will have a self-sovereign alternative to corporately owned forges such as GitHub and GitLab.

Terms of Agreement

Radworks will grant 12-months of funding to Radicle to:

  • 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 user

  • 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

Grant Structure

Upon successful passing of [Discussion][RGP-18] - Radicle Org Proposal 2024, Radworks grants Radicle $1,370,482 to achieve the objectives listed above.

  • Funding will be structured as a non-recoverable grant. There is no return expectation from the Radicle Org to Radworks defined in this document.

  • Funding will be granted on a yearly basis.

  • The Radicle Org will not seek additional investment from third party capital providers without consent of Radworks.

    • “Additional investment” = capital seeking financial returns/ownership of Radicle. Additional investment does not include non-return seeking donations or grants.
    • “Consent of Radworks” = approval via a social proposal
  • The Radicle Org also commits to:

    • Participation in Radworks’ quarterly community calls
    • Meet on a quarterly basis with the Radworks Strategy Committee


If Radicle does not get any traction by the end of 2024, there will be a decision on whether to continue in the current path, or dissolve the Radicle Org (but not the project).

All of the following conditions would have to be met to dissolve the org:

  1. Radicle 1.0 has been launched for at least 6 months.

  2. Radicle has no traction, eg. no known open source projects use it, no one is paying for it and there is no or little growth in network, contributions and users.

  3. No alternative path or strategy has been found.

1 Like

How are we defining “end of 2024”? Is this until we have to submit 2025 Org proposals or is it up until December 31, 2024?

Re: pivot section, a concern of the way this is set up is it seems like this may (wrongly?) incentivize the Radicle team to delay 1.0 launch to June 2, 2024 and/or scope down the launch… do we have any counter-balance to this or is this concern somehow addressed elsewhere? Thanks!

Can you elaborate on why it would incentivize a delayed/scoped down launch?

End of year 2024 I believe!

1 Like

Thinking is, launching on June 2 would be a safer bet to ensure that the org remains funded in 2025… because it’s a sure disqualifier for #1 of this agreement, whereas #2 and #3 are subject to market forces and interpretation.