[Application] Radicle Jetbrains IDE Plugin - Implementation Phase 1

Radicle Jetbrains IDE Plugin - Implementation Phase 1

  • Status: Open
  • Proposer: @gsaslis
  • Your Project(s): [optional]: N/A
  • Projects you think this work could be useful for [optional]: Developers who rely on the Jetbrains IDE for productivity boost.
  • Teams/People that could deliver the RFP [optional]: @gsaslis

Overview :telescope:

This proposal is for the first phase of implementation of the IntelliJ plugin for which we have created the UX prototypes through the first Milestone of the Radicle Grant about IDE Plugins.

Now that the UX has been laid out and we have a robust UI prototype we need to develop the actual plugin which will give IntelliJ users the ability to communicate with Radicle from their favorite IDE. We believe it is crucial to make Radicle as integrated as possible to developers’ existing workflows, so that they will not feel as if they are sacrificing productivity to onboard to Radicle.

In the next paragraphs we describe how we will begin working on this project.

Project Description :page_facing_up:

Following on from Milestone 1 of the Radicle Grant for UX research on Radicle IDE Plugins, which included User eXperience (UX) research into the functionality of the Radicle IDE plugin for Jetbrains IDEs, we are hereby proposing a Radicle Grant to fund the implementation of the plugin.

The overall development will be split into multiple phases, to allow for frequent deliverables, and iterative development.

This grant application will cover the very first implementation phase.


The overall scope (i.e. not the scope of this grant application alone) will include the following UX journeys in the IDE plugin:

  • Create new radicle identity and manage key pairs
  • Initialise and publish a git project on radicle
  • Configuring seed nodes
  • List projects available on the seed node
  • Track and checkout projects
  • Pushing and synchronising changes with Radicle seed nodes and other peers
  • Working on Collaborative Objects through the IDE (i.e. tasks, issues, patches, releases, etc. )

In an attempt to prioritize the deliverables and “start somewhere”, we decided to look at what would bring most value to the Radicle users. To assess how much value a feature brings, is a very complex problem that requires MUCH more data than we have available at this early stage of development. We therefore propose to use a simplified heuristic, simply based on what features we expect will get used the most.

With that in mind, we classified the UX journeys, based on expected frequency of use:

  • One-time or rare (less than once per week) use:

    • Create new radicle identity and manage key pairs
    • Initialise and publish a git project on radicle
    • Configuring seed nodes
    • List projects available on the seed node
    • Track and checkout projects
  • Daily use:

    • Pushing changes to other Radicle seed nodes and peers
    • Synchronising changes from other Radicle seed nodes and peers
    • Collaboration on Patches, Issues, Releases and other types of Collaborative Objects (cobs)

This application aims to fund the first two bullets of the “Daily Use” category, as described above, and as shown on the interactive prototypes, under the “Contribute” task.

If all goes well, the next natural step will be to move forward with the collaborative objects, on a subsequent grant application. This will also depend on the progress on collaborative objects on the protocol level, as well as support for collaborative objects in the CLI (which we depend on, as explained in the section immediately below).


Our approach to the implementation of the Radicle-related functionality within the Jetbrains suite of IDEs will follow the pattern already laid out by the Git plugin: rather than implementing all core-git functionality itself, the Git plugin relies on the git command-line tool to be available on the system. (There is a settings screen where it is possible to configure which git binary is used.)

We intend to follow a similar approach: rather than implementing core-radicle functionality within the plugin, we will rely on rad to exist and will build all functionality on top of rad command-line tool.

Essentially, we will only build the User Interface (UI) in the plugin that will, on the one hand, handle the interaction of this UI with the rest of the IDE, while, on the other hand, mapping all UI functionality to (parameterized) calls to rad.

This approach helps avoid code duplication and will save us a lot of time from reimplementing functionality already available in rad.

It should be noted that this approach also introduces a hard dependency on the alt-clients team, as the maintainers of the rad tool, considering that any broken functionality in rad would also break the Jetbrains IDE plugin. However, considering that rad is a tool intended to be used directly by the Radicle users, we don’t think this is introducing some worse failure mode than already exists: if rad breaks for the users who use the Command Line Interface (CLI), it is no worse if it also breaks for users who use the Graphical User Interface (GUI). In both cases we are considering a customer-facing issue.

Deliverables :nut_and_bolt:

Being our very first Milestone, a large part of this work will involve setup tasks.

Other than that, we are focusing on a kind of “Minimum Viable Deliverable” such that the plugin would still do something useful at the end of this first chunk of work, even if that useful functionality is very minimal.

Milestone 1: Pushing and Synchronising changes through the IDE

  • Total Estimated Duration: 6 calendar weeks
  • Full-time equivalent (FTE): 35 FTE days
  • Total Costs: 25 200 EUR (27 650 USDC)
Number Work Item Specification
1. Team setup + Onboarding A new team is coming together to work on this IDE plugin.
2. Tool selection + CI/CD setup The team needs to converge on the necessary tools for the job: issue tracking, CI/CD, git hosting, wiki, etc.
3. Settings → Version Control → Radicle As part of this iteration, it only allows for the path to rad to be defined, just like the Git plugin does in Settings → Version Control → Git.
4. Git → Radicle → Push menu item Introduces the Git → Radicle sub-menu and adds the first button there. This button invokes rad push.
5. Radicle → Push toolbar button Introduces a new toolbar section for Radicle actions and adds the first Push button there. The button invokes rad push.
6. Git → Radicle → Sync menu item Adds a new sub-menu item, under Git → Radicle, which invokes rad sync.
7. Radicle → Sync toolbar button Adds a new toolbar item, in the Radicle toolbar section, which invokes rad sync.
8. Activity indication Whenever the “Radicle sync” or “Radicle Push” functionality is invoked, we need to indicate there is background activity happening, using the usual progress bar available in Jetbrains IDEs.
9. Publish plugin to Jetbrains Marketplace Once this version of the plugin has been completed, it needs to be published to the Jetbrains marketplace.

Future Plans

This Radicle Grant application is conceived as the first of several applications that will fund the implentation of the Radicle IDE plugin for Jetbrains IDEs.

Rather than a big “monolithic” Radicle Grant application, we instead plan to submit each development phase as a separate application, so that:

  • the deliverables are clearer
  • we are not forced to guesstimate how long large pieces of development work will take
  • the risk for Radicle is limited: the Radicle Grants team can choose to fund only the functionality to the plugins that they find valuable - rather than being faced with an “all or nothing” dilemma. i.e. funding one application bears no commitment to fund future ones.

This approach, of micro-grant applications, is how we think iterative software development practices can be combined with Grants programmes.

Team :busts_in_silhouette:

Team members

  • Yorgos Saslis
  • Ioannis Christodoulou
  • Stelios Mavrommatakis


  • Contact Name: Yorgos Saslis
  • Contact Email: I can share this privately on discord.
  • Website:

Legal Structure

  • Registered Legal Entity: Cytech Ltd.
  • Registered Address: Science & Technology Park of Crete, Heraklion, Greece

Team’s experience

  • [Yorgos] 15+ years of experience in various roles of the full Software Development Lifecycle: writing code, agreeing on specs with clients, architecting systems, establishing product priorities, designing testing and CI strategies, and co-creating department-wide processes - with an itch for driving “waste” out the door. Co-founder of developer communities (DevStaff, Heraklion Software Crafters, Web3 Greece) and co-organizer of open space unconferences (AgileCrete, JCrete) on the (paradise!:desert_island:) island of Crete!
  • [Ioannis Christodoulou] is a Software Architect with 10 years of professional experience in Web and Mobile applications, such as Greek Passenger Locator Form (a web application that all travelers coming to Greece were required to fill-in) and Covid Free GR (the mobile application used throughout Greece to verify COVID-19 vaccination, recovery and test certificates). He is also the creator and maintainer of an IntelliJ plugin (GitExtender - github, marketplace ) for managing and updating multiple git repositories in the same IntelliJ project.
  • [Stelios Mavrommatakis] is a young Full Stack Software Engineer focused on web applications development. He had participated in large software projects like the EU-DPLF (https://euplf.eu/) a paneuropean application for covid19 contact tracing for tavelers to the EU. He is a passionate software engineer and is currently working on a web3 project expanding his knowledge and experience in new and challenging sectors.

Team Code Repos

Team LinkedIn Profiles (if available)

Additional Information :heavy_plus_sign:

How did you hear about the Grants Program? Radicle Discord


In full support of this proposal! As mentioned in my responses to the UX grant, the only thing is it would be great to get some client team contributors eyes on the IDE spec, but I’m sure that’s happening in the background.

1 Like


This looks great.

I’m definitely in support of this, especially after the great UI/UX research.

This may be a good candidate to start dog-fooding Workstreams, a few ideas below:

  • We make the initial 20% payment via current process, and remaining 80% using Workstreams
  • If Workstreams doesn’t work out, we make the initial 20% payment via current process, and remaining 80% using the current process as well

In any case, I think it makes sense to make the 20% initial payment ASAP

Let me know your thoughts.
I will go with starting the normal process if we don’t have any added input by Monday (July 4).

@bordumb that sounds absolutely fine and thank you for your feedback and support!

I am excited to try out Workstreams, so I would very much like to at least try out the transition to Workstreams! We can see what doesn’t quite work and help the workstreams team iterate on it.

As a further note, I’d like to share we are all really excited with this and can’t wait to get started!

Thanks again!!


Thanks for the quick reply @yorgos

I’ve gone ahead and started the initial vote for the 20% (i.e. 20% of 27,650 USDC, so 5,530 USDC).

In terms of Workstreams:

  • If you complete the work before Workstreams is ready, we will pay out the remaining 80% using the existing process
  • If Workstreams is ready before your work is done, let’s try and utilize Workstreams to cover the remaining 80%
1 Like