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

[yorgos]

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

@cloudhead

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.

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.

@cloudhead

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.

@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 ?

@cloudhead

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

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

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?

2. 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…)

3. 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 ? 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).

@cloudhead

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

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:

@cloudhead

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.

@everyone If the work we are doing is not the issue (thank you for acknowledging that, btw @cloudhead ), 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 and focused on getting radicle into the hands of users .

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!