[RFC] Radworks Product Org Proposal 2025

[Kuehle]

Author(s):	@Kuehle
Type:	executeable org
Created:	2024-12-02
Status:	active

Intro

This is a new Org that brings together efforts from the RSN and the current Radicle Desktop client, with the goal to develop a coherent product experience.

Purpose

The team’s mission is to popularize the sovereign developer stack and prove new business models around it.

Objectives

1. Release new Desktop Client and the managed offering for code hosting.

   • Deliver a Desktop Client by Q2.
   • Develop the Radworks Seed Network (RSN) as a managed offering to
     address user experience gaps for organizations.

2. Increase user adoption.

   • Build an initial user base of paying users for the managed offering by Q1, aiming to achieve a steady growth until the end of the year.
   • Ship the desktop application and show increase adoption

3. Alignment with Radworks.

   • Answer: how should income be used to cover future development costs and in the spirit of open source software principles? What does a sustainable medium-term funding model look like for this Org and its products? How should profit be used to align the Org’s commercial success with Radworks?
   • Based on the answers to these questions, set up operational and legal mechanisms to contribute value back into the Radworks ecosystem.

Strategy

Now that Radicle 1.0 the protocol is stable, this Org plans to build cohesive experiences on top of the Radicle protocol.

In this Org’s first year, the intention is to demonstrate that these products can be revenue-generating (i.e. prove existence of a market) and determine what can be charged for such services. If this is successful, in the future, the Org intends to clarify how profitable the tools its building are intended to be and how sustainable it will be in terms of using income to cover its future development costs and support Radworks more generally.

In the initial rollout phase, early users will be onboarded through high-touch engagement, in order to gather actionable feedback and iterate on the product offering. This personalized approach will ensure full understanding of the needs of initial users, further enabling refinement of the product mission and the product scope based on real user experiences. The desktop client will be developed with usability in mind, with a validated release in Q2 to collect further user feedback.

As adoption grows, the onboarding processes will be automated to accommodate more users and managed seed node offerings will be developed. Features will be prioritized to address user needs and resolve blockers to adoption. By Q3, automation will enable us to grow the user base efficiently.

For growth expansion, we will focus on community engagement, increasing visibility in developer communities, and creating educational content to facilitate user adoption. Partnerships, advocacy, and clear communication will play key roles in expanding our reach and lowering barriers for new users.

Products

Desktop Application

• Target Audience: Individual contributors and developers.
• Problem Addressed: The need for a streamlined, user-friendly interface to collaborate on code using Radicle.
• Features:
  • Issues, patches, and code review.
  • Integration with local nodes for improved performance.
• Unique Selling Proposition: Fast, local-first desktop experience.

Radworks Seed Network (RSN)

• Target Audience: Companies and organizations looking for managed solutions.
• Problem Addressed: Need for simplified, managed participation in the Radicle Network.
• Features:
  • Managed nodes as a service, facilitating collaboration for teams.
  • Bridging user experience gaps through tailored integration.
• Unique Selling Proposition: Effortless participation in the Radicle Network.

Timeline

1. Q1: Initial User Base and Release managed version of RSN

   • Onboard initial paid users.
   • Develop core features for Desktop App.
   • Silent launch and manual onboarding.
   • Develop initial visual brand and brand strategy.

2. Q2: Release Desktop app

   • Release Desktop App.
   • Gather user feedback and iterate on features.
   • Conduct pricing research.

3. Q3: Automation and Scaling

   • Automate onboarding processes for managed seed nodes.
   • Address user blockers for increased audience growth.

4. Q4: Expansion and Advanced Features

   • Continue to grow the user base.
   • Prioritize development of new features based on validated user needs.

Organizational Structure

Contributors:

• Johannes Kühlewindt
• Daniel Kalman
• Fintan Halpenny (Monoidal Ltd)
• Lars Wirzenius Company Ltd
• Maninak
• Rudolfs Osins
• Sebastian Martinez (Rhizoma)
• Yorgos

The Radworks Product Org is currently evaluating the options for its legal setup in light of multiple questions at the intersection of legal, regulator and tax matters. The Org intends to have more clarity in this regard, including the relevant wallet, ahead of the on-chain vote on December 17.

Reporting & Success Criteria

• Daily and Weekly Active Nodes.
• RSN Managed Offering paid user growth.
• Engagement per user (unique repos, pushes, issues etc.).
• Revenue generated.

Revenue metrics and usage numbers will be shared quarterly as part of the Community Call and update.

Budget

Description	Budget
Contributors	$1,778,885.35
Marketing	$165,849.10
Events & Offsites	$33,544.80
Accounting Costs	$8,386.20
Legal	$81,999.15
Operations	$86,541.11
Total Budget	$2,155,205.70

Management of Funds

As mentioned above, the Org intends to have more clarity in this regard, including the relevant wallet, ahead of the on-chain vote on December 17.

The Radworks Product 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 (2025) will either be returned to the Radworks Treasury (by March 2026) or rolled over into and applied towards the Org’s 2026 grant from Radworks.

[bordumb]

This is an exciting group of people!

Non-blocking question:
A popular blocker I’ve seen from users is the need for CI/CD. My understanding is that Lars is mostly working on this. Is this work still a priority / does it sit within this Org? Or the Radicle Org?
I didn’t see it explicitly listed in either proposal. I’m just curious to understand where this work sits as it stands out as one of the main reason I’ve seen people say that Radicle is not “yet” ready.

Thanks for sharing this writeup!

[Kuehle]

Hey @bordumb,

Excellent question!

The proposal mentions:

• Managed nodes as a service, facilitating collaboration for teams.
• Bridging user experience gaps through tailored integration.

Which intends to capture the essence of “Identify and fill user experience gaps.” The proposal avoids listing specific features as more work is needed to identify and prioritize all of those gaps.

During the work on RSN, one of the main challenges was identifying the value managed nodes actually generate for the users. As a result, those conversations lead us to the conclusion that expectations on code hosting are much higher than just hosting code.

Hosting the code is just one of the components of the software development cycle, with collaboration tooling, continuous integration, and continuous deployment being where the competitors actually differentiate.

CI and the ease of use are two of the other code hosting solutions that got it right.

Lars would be a key member of the team to make CI integration happen.

Let me know if that answers the question.

[Sov]

I support this proposal for its approach to building sustainable products on Radicle. Key strengths:

1. Smart dual-product strategy addressing both individual developers (Desktop) and organizations (RSN)
2. User-centric development approach with high-touch early feedback
3. Clear focus on revenue generation while contributing back to Radworks ecosystem
4. Strong team composition with relevant technical expertise

Appreciate @Kuehle’s clarification on CI/CD integration being part of the broader UX improvements.

The proposed budget aligns well with the scope and team composition. Looking forward to seeing this team’s work in 2025.

[bordumb]

Thanks a bunch for the thoughtful response.

I really liked that the proposal was written in a way that focuses on user input as the foundation for the roadmap.

It’s good to know that CI/CD is embedded within a few of the bullet points and that a lot of the decisions will be user-centered.

[vanton]

The introduction of a Product Org is an excellent development, as it focuses on user needs and ensures feedback is funneled across all teams, making Radicle truly user-centric and hopefully helping towards its broader adoption. I also appreciate the distinct value propositions for different customer segments—companies and individual developers. It makes sense to cater to these groups separately since their needs vary significantly.

However, one thing is unclear to me: do we have evidence that individual contributors prefer to onboard to Radicle and access its services via a desktop client rather than through tools they already use, like their editor or IDE (e.g., Neovim, VSCode, IntelliJ)? Maybe it’s me but, I couldn’t find any validation supporting this approach.

In my experience, it’s usually harder to change user habits by asking them to install and adopt a new application compared to adding a feature within tools they already use. It might be worth the time to ask individual contributors directly to validate this assumption. What are their current workflows, and would they find more value in a desktop client or an integration within their existing development environment or maybe both?

This is similar to what you’ve already done with companies. Interviews and surveys clarified that companies don’t just need a code hosting service—they also require a CI tool, as it’s a fundamental part of their workflow. This insight shaped the offering to better meet their needs. I propose that part of the Product Org’s job is to validate assumptions regarding the preferred touchpoints for individual contributors. Understanding where and how they prefer to interact with Radicle could significantly enhance adoption and overall user satisfaction.

[Kuehle]

Thanks for posing this important question @vanton !

I can share a bit more on the rationale behind developing a desktop app.

Building a desktop app allows us to have full control over the user experience, unlock high performance potential, and access operating system APIs. While this may seem like a technical reason driving a fundamental user experience decision, here is where I think it all comes together:

There are tools users are comfortable stepping out of their editor/IDE for - like all the tools that are webpages - most notably the code forges.

The desktop app, as I see it, doesn’t aim to replace workflow components typically handled within the developer’s editor/IDE. Instead, it brings the git forge experience directly to the local environment, eliminating the need to fetch pages via HTTPS.

For other parts of the workflow - such as viewing branch-related information or interacting with git-adjacent features - I see integrations with editor/IDE ecosystems as a more natural fit. This is where @maninak and his expertise could be helpful.

If we see that the value of the Desktop app is high, but people still don’t want to install an app, it might have to do with packaging and onboarding.

Of course, these are just my current assumptions. The plan is to gain deeper insights into the diverse audiences using Radicle. For example, the average Vim user likely has different expectations compared to someone using VSCode (one might never use anything outside their terminal, the other might not care so much).

[vanton]

Thanks @Kuehle for your reply.

It’s clear from your description that we currently lack a solid understanding of what different user groups need or which tools they are most comfortable working with. Gaining this insight is essential for selecting the right approach to reach them effectively. By doing so, we can significantly increase our chances of convincing them to give Radicle a try and even using it in the long term.

I completely agree that a thorough problem and solution validation phase is critical beforehand. This will ensure that the new Product Org has evidence-based guidance on what to develop.