[Discussion][RGP-22] - Start the Radworks Seed Network (RSN) Org

[lftherios]

[Discussion][RGP-22] - Start the Radworks Seed Network (RSN) Org

Author:	lftherios
Type:	Org
Created:	2024-02-12
Status:	active

Purpose

The purpose of this org is to provide seed node services that makes hosting and fetching content from Radicle simple & performant for any developer.

Annual Strategy & Quarterly Objectives

Q1 2024

1. Hire two engineers and bootstrap the team

Q2 2024

1. Onboard new engineers
2. Launch a production-ready centralised seed node service providing storage for Radicle projects and bandwidth, that is available for both FIAT and cryptocurrency payments.

A centralised seed node service for Radicle refers to a web-based service or server that allows users to access and retrieve content from the Radicle network through a centralized point of access. An example from the IPFS ecosystem is Pinata.

3. Conduct and publish research on decentralised alternatives for content retrieval and assess their feasibility.
4. Evaluate the viability and technical direction of a decentralised seed node network for Radicle.

Q3 2024

1. Hire new team lead to replace Ele
2. Iterate on the centralised offering based on user feedback and improve it’s reliability and UX
3. Publicly release performance and adoption metrics for the centralised offering.

Q4 2024

1. Continue refining the centralised offering in terms of performance, features and pricing.
2. If applicable (see objective 4-Q1-2024), launch the first incentivised testnet for the decentralised service.

Organisational Structure

I’d like to propose that I kickstart this team. The objective would be to swiftly onboard three senior engineers to commence work on this topic. This also includes identifying and hiring a future team lead (one of the three hires) who will eventually succeed me in this role, as I already have a substantial workload to manage between Drips and Radicle.

With regards to the organisational structure I am planning to create a new Swiss Association (identical to what we’ve done with Public Goods Association for the Drips Org), but I am also open to other setups (org vs team under an existing org vs grant) so please contribute if you have opinions.

Communication

Website: A new website will be set up.
Discord: A new Discord server will be established.
Radicle: A new Radicle repository will be created.
We will attend and present our work at all Radworks community calls.
We will share quarterly updates, as every other team.

Reasoning & Analysis

My primary rationale stems from the following observation:

Radicle’s gossip-based peer-to-peer network suffices adequately in terms of performance for individual / hobbyist users. However, when considering professional developers, performance & convenience become significantly more crucial. Thus, there’s a high likelihood of demand for self-hosted or third-party gateways.

This trend mirrors what has occurred with IPFS, Scuttlebutt, or any other peer-to-peer network that gained adoption.

Why (Likely) Two Services

When it comes to this audience I believe that is wise to offer two services. The centralised offering should target convenience, while the decentralised offering should target a blend of censorship resistance and performance.

My thinking is this:

• If you care about convenience: Radicle + 3rd party seed node > Radicle + decentralised network of seed nodes > Radicle’s gossip based network

• If you care about censorship resistance for the content of your app: p2p gossip > Radicle + a decentralised network of seed nodes > Radicle + 3rd party seed node > db operated by a company

With regards to the decentralised offering that I describe above, my hypothesis is that there is a large number of well funded crypto related applications and protocols that care about censorship resistance but are looking for something more performant than p2p gossip and something more decentralised than relying on a single seed node (3rd party or self-hosted). I also believe this proposal enables us to manage risk appropriately, as the centralised service path is fairly trivial and will give us the opportunity to explore more innovative approaches for node coordination (the decentralised service) simultaneously.

Focus & Separation of Concerns

Establishing a dedicated team for seeds, allows the protocol team to focus on protocol development and serve all node operators impartially. The new team can concentrate on user-centric aspects such as UX, onboarding, community support, and customer service.

Try before you commit

As @yorgos wrote on the original discussion, it is a well established pattern for many open source projects to offer a hosted service as a quick way for end users to get acquainted with the project and try it for themselves before they decide to self-host and deal with the operational complexity of self-hosting.

End users are generally comfortable using such hosted services because:

• they can reduce the investment / learning curve on this new piece of software, as they have less to learn (i.e. it is not just “more performant”, it is also “easier to use”),
• they can find out if it is a good fit to their problem faster,
• it is a nice way to support financially the maintainers/creators of the project,
• there is no vendor lock-in, as they always have the option of self-hosting.

Equally, I think this will also help node operators in deciding whether they want to be involved with running Radicle nodes, because before deciding to offer / sell any service it is important to understand the service / features / advantages of whatever it is you’d be selling to your potential customers. Not having to self-host, to find that out, makes that path shorter.

Timing & Strategy

With Radicle 1.0 a few weeks away we have to start considering new challenges and opportunities. Bootstrapping a new team is something that always takes a lot of time (at best weeks, more realistically months), so I think it’s wise to start now in order to have a service in the market by the end of Q2.

As @yorgos wrote above, with Radicle essentially not having hit general availability yet, moving forward with this initiative will essentially lay a much smoother onboarding path for new users, assuming this new org is more focused towards that.

In addition, there is currently no established node operators network, so there is essentially no established competition between different entities at this point in time. If this happened 6 months in the future, when some hosting companies might have started investing in “hosted Radicle” services for their customers, such a move might be seen competitive to those community members. Doing this now allows us to set a different stage so that doesn’t happen.

This new organisation can also contribute valuable work to the community by providing documentation, deployment scripts, and operational know-how for deploying Radicle in various environments, addressing the current lack of information and limited deployment options.

Finally, achieving the centralised offering is in my opinion well within reach, and I have a high level of confidence in our ability to swiftly deliver a great service. An initial centralised offering will provide the necessary resources and time to thoroughly investigate the demands and viability of the decentralised offering. While the decentralised option is more intricate and ambitious in nature, it strongly aligns with Radworks’ values and overarching goals. I also think that this is the most natural sustainability model for Radworks and I am excited for Radworks to move beyond its current form.

Reporting & Success Criteria

The main success criteria for 2024 should be to:

1. build the team
2. ship the v1 for the centralised offering
3. decide on direction for the decentralised offering and execute

Later in the year we will provide a lot more detailed metrics for each service with a focus on performance, user adoption and revenue.

Timeline & Budget

I am requesting $544,520 to be paid fully in RAD. Using last 30 days’ average closing price based on Radworks USD Historical Data | CoinGecko that would mean 289639 RAD. Break-down below:

Total Budget	$544,520
Marketing	$65,162
Team Offsites	$4,000
Accounting	$7,678
Operational expenses	$3,190
Contributors	$464,789

Fund Management

I will set-up a multi-sig to receive the funds and I am currently discussing who the signers should be, until I onboard new contributors.

Technical Implementation

The actual code will be added during formal review.

Finally I would like to thank @yorgos @vanton @cloudhead and everyone else that participated in the conversations on the forum & Discord. This proposal started from a personal idea and was co-developed in the open based on all of your feedback.

[shelb_ee]

Hey Ele, thanks for the proposal! It is excited to see the discussion around incentivizing seed nodes move forward.

Although I am not an expert in gateway networks/infra, the idea to have a few contributors dedicated to providing node services seems to makes a lot of sense to support onboarding and adoption of Radicle! I do, however, have some questions about your proposal - primarily regarding the setup and budget.

Re Setup

• Why do you feel this project needs to be a separate Org? It seems that the work is extremely specific to Radicle and is highly dependent on protocol development and the success of the Radicle Org. From my understanding of the work described above, this work may be better suited as a Team within the Radicle Org?
  A “Team” is defined as being a group of contributors that further or support the development of an Org, that also receive funding and operational support from that Org. That seems to fit the description of the above better than the definition of an “Org”, which are defined as "independent organizations that serve the Radworks purpose by building new, resilient, and permissionless technologies (see Ecosystem docs). I know we still need to have a deeper community discussion around clarifying what it means to be an Org vs a Team, and that the documentation needs to be made clearer, but I would still be curious to hear your reaction to this, and some examples to why you think it would make sense for this team to be an Org?

• If this were to pass, how would you imagine this team would work/cooperate with the Radicle Org? Since the work is so closely dependent on each other, I imagine there would be a consistent communication process in place? In addition, how do you imagine this team working with Yorgos’ team in the future?

• How much of your time do you expect to be contributing to setting up and running this proposed Org? As you are already fairly busy with Drips, I am curious how plan to split your time if this Org is created?

Re Budget
The budget seems very high. A few clarifying questions re budget:

• Re marketing: How would this team’s budget be different from the marketing budget already allotted to the Radicle Org for 2024? If this passes, would that change anything regarding how the budget will planned to be used within the Radicle Org?
• Re offsites: Is this implying they will have their own offsites or are those costs to cover travel to Radicle Org offsites? If the former, why would this team need a separate offsite than the core Radicle team?
• Re contributor costs - Are these meant to be full-time or part-time contributor? For either, I would like to hear your thoughts on why the suggested time commitment is suitable for the workload you are expecting. I would also like to hear from @cloudhead and others in the Radicle Org what they feel would be a good amount of time to spend on this.

Alternative idea: Grant funding
As this work was inspired by the Radicle 1.0 launch, why not apply for a Grant to fund this team/work through the rest of Q1/Q2 2024 (or until whenever you feel is appropriate) to focus on building this idea out in alignment with the Radicle 1.0 launch? This work would align perfectly with the Grants thesis and funding categories for 2024.

This also sounds like a good way to lay the initial foundation for this work and would allow the community time to assess working with this new team as they will most likely be new contributors who the community doesn’t know or trust yet? (Please correct me if I am wrong here though.)

[lftherios]

Thank you for your reply @shelb_ee. Answers below:

@shelb_ee

A “Team” is defined as being a group of contributors that further or support the development of an Org, that also receive funding and operational support from that Org.

I personally do not have a strong preference with regards to org vs. team vs grant.

Having said that:

• this is a different service that is built on top of Radicle.
• we do not need any particular operational support from the Radicle org. In fact this is one of the main arguments of separating these efforts. The Radicle team should focus on the Radicle protocol and the RSN team on its retrieval services.
• it’s imo very important that the Radicle protocol team treats all node operators equally vs prioritising one set of node operators.

@shelb_ee

hat seems to fit the description of the above better than the definition of an “Org”, which are defined as "independent organizations that serve the Radworks purpose by building new, resilient, and permissionless technologies (see Ecosystem docs).

I think we need to collectively revisit this definition, as it doesn’t apply to the current orgs. For instance the Radicle org depends on the Foundation org for maintaining the Radicle trademarks as well as its domain names. This was a conscious decision (not an afterthought). Also the Foundation org is not developing any technology at the moment.

@shelb_ee

I know we still need to have a deeper community discussion around clarifying what it means to be an Org vs a Team,

@shelb_ee

but I would still be curious to hear your reaction to this, and some examples to why you think it would make sense for this team to be an Org?

I think that it would be better to revisit some of these definitions because it’s hard for current orgs to clearly satisfy them as is.

@shelb_ee

If this were to pass, how would you imagine this team would work/cooperate with the Radicle Org? Since the work is so closely dependent on each other, I imagine there would be a consistent communication process in place? In addition, how do you imagine this team working with Yorgos’ team in the future?

I don’t think that we need to cooperate in any specific way in particular. We will be part of the Radicle community, similarly to hopefully hundreds of other developers. This team should not have any special privileges with regards to the Radicle org. We want the Radicle protocol to remain neutral to all node operators. It’s a feature, not a bug. And it’s important in my opinion it stays this way.

The RSN services will consume Radicle’s code, build something on top of it and contribute back to the Radicle community a new service, documentation and hopefully some protocol patches here and there.

@shelb_ee

How much of your time do you expect to be contributing to setting up and running this proposed Org? As you are already fairly busy with Drips, I am curious how plan to split your time if this Org is created?

I have budgeted for 10 hours a week (that’s all I can provide for now) in order to hire the right team until I replace myself with a new team lead. In addition I plan to contribute to the research for the technical direction of the decentralised service.

@shelb_ee

The budget seems very high

High relative to what?

@shelb_ee

Re marketing: How would this team’s budget be different from the marketing budget already allotted to the Radicle Org for 2024? If this passes, would that change anything regarding how the budget will planned to be used within the Radicle Org?

RSN markets to a different audience than Radicle. The way I imagine it, it will be a subset of all Radicle users and potentially an additional audience that the Radicle p2p protocol can’t market to / isn’t relevant as is. That’s why I have allocated a marketing budget.

@shelb_ee

Re offsites: Is this implying they will have their own offsites or are those costs to cover travel to Radicle Org offsites? If the former, why would this team need a separate offsite than the core Radicle team?

This team doesn’t have much to do with the Radicle protocol team. It consumes it’s work, the same way Radicle consumes the work of GitHub - libgit2/libgit2: A cross-platform, linkable library implementation of Git that you can use in your application..

@shelb_ee

Re contributor costs - Are these meant to be full-time or part-time contributor? For either, I would like to hear your thoughts on why the suggested time commitment is suitable for the workload you are expecting.

It’s 3 full-time senior engineering hires (including one team lead)+ my time until the team is fully operational without me.

@shelb_ee

Alternative idea: Grant funding

As I wrote above I have no preference about it. Ideally there is more guidance beyond what’s there.

[cloudhead]

@shelb_ee

a Team within the Radicle Org?

I’d just like to chime in to say that I have enough responsibilities currently and don’t need more

I don’t see any reason why this can’t be a fully independent team with its own budget/leadership.

[abbey]

Hi @lftherios, thanks for the proposal! Happy to see the idea making its way to the forum.

Before sharing my questions, I’d like to state that I think hosting seed nodes for end users is a great idea for bootstrapping adoption and improving user/network experience. I also think that it creates an exciting opportunity to leverage RAD for incentivization.

With that in mind, I have a couple of questions about implementation:

@lftherios

Hire two engineers and bootstrap the team

Have you scoped job descriptions for these engineers? What kind of hires (e.g. seniority, part-time vs. full-time) will they be and what experience are you looking for?

@lftherios

Launch a production-ready centralised seed node service providing storage for Radicle projects and bandwidth, that is available for both FIAT and cryptocurrency payments.

Without any engineers onboard already, can you elaborate on how you scoped this objective? Is one quarter (three months) enough time to complete this objective fully?

Also, how does this service relate to the Radicle Org’s objective to “Q4: Start experimenting with paid offering, given product-market fit”?

@lftherios

Evaluate the viability and technical direction of a decentralised seed node network for Radicle.

Does this include evaluating the feasibility of an incentivization model that incorporates RAD? If so, can you elaborate on how you would evaluate the feasbility of a decentralized, incentivized seed node network?

How would you see this playing into the Strategy Committee’s work on sustainability modeling?

@lftherios

I’d like to propose that I kickstart this team. The objective would be to swiftly onboard three senior engineers to commence work on this topic. This also includes identifying and hiring a future team lead (one of the three hires) who will eventually succeed me in this role, as I already have a substantial workload to manage between Drips and Radicle.

As you are already an Org Lead of the Drips Org, how many hours will you need to realistically contribute to bootstrapping this team and the first implementation of the centralized network? Is this possible with your current commitments?

@lftherios

With regards to the organisational structure I am planning to create a new Swiss Association (identical to what we’ve done with Public Goods Association for the Drips Org), but I am also open to other setups (org vs team under an existing org vs grant) so please contribute if you have opinions.

Does the choice of entity change since this would be offering a paid service (aka an entity with revenue)? Have you taken the timelines and costs of entity formation into account? How will the revenue generated by the paid service be used by the proposed Association?

Also, can you elaborate on why you think this work should be initiated as a new Org vs. as a grant?

@lftherios

Total Budget $544,520 Marketing $65,162 Team Offsites $4,000 Accounting $7,678 Operational expenses $3,190 Contributors $464,789

Can you elaborate on the marketing costs? What will those be used towards? And how are you calculating your contributor costs? What market rates are you using? Are your contributors full-time?

Have you done an estimation of what resources/time will be needed from other Radworks contributors? I’m specifically thinking about the Foundation Org (Ops) and Radicle Org.

---

A couple general thoughts on the proposal:

I think the benefit of a hosted service to ease onboarding to Radicle is clear. It improves convenience and usability for end-users, while also increasing the performance of the network as a whole. I also see the value of having third-party gateways available to bootstrap adoption of Radicle at these early stages, especially as we approach our first stable release.

My main concerns revolve around implementation. If the goal is to get resources to fund developers ASAP, wouldn’t it be easier to submit a grant application to fund a third-party (e.g. Chainsafe) to build out the centralized solution or a single developer to ship an MVP? With a grant, you could have the funds allocated quicker and require less operational overhead (and time on your part!) because you wouldn’t have to set up a new entity. cc @bordumb

With the official publicly-stated deadline for Radicle 1.0 release being end of Q1, I feel that taking a more iterative and progressive approach to bootstrapping this work is more appropriate, so we can remain light and adaptive pre-stable release. What if in six months nobody wants to use the centralized hosting service we just spent ~$500k in RAD developing? Investing in a new Org seems like a heavy-handed approach to a problem that could be addressed quicker and easier via the Grants Org.

I’d like to clarify, however, that forming a new Org to develop third-party seed node services does make sense to me personally in the long run. Most hosted services should operate separately from core protocol development as separate companies (I mean, Pinata raised $21M of external funding in 2022!). I think the issue we’re running into (that we also ran into with @yorgos’ proposal) is that currently, the Radicle Org isn’t explicitly just the protocol team. It’s technically currently responsible for UX, product development, onboarding, community support, and exploring its own sustainability. I believe a re-scoping of the Radicle Org might be necessary to clarify the role of Radworks as a funder & supporter of the Radicle ecosystem.

TL:DR; As we wait for the stable Radicle 1.0 release, I’d like to explore a what a lighter approach to bootstrapping this work could look like, perhaps by leveraging existing capital in our Grants Org. I believe doing so would allow us to start the work quicker, remain adaptive, and test/validate the concept before investing heavily operationally and financially. I think it would also give us time to build out a team sustainably and intentionally, while also keeping up with the Radicle 1.0 release. I’d appreciate your perspective on how you see the trade-offs between initiating this work via starting an Org vs. applying for a grant!

[shelb_ee]

Thanks for the quick reply @lftherios! My responses to a few things below:

@lftherios

• this is a different service that is built on top of Radicle.
• we do not need any particular operational support from the Radicle org. In fact this is one of the main arguments of separating these efforts. The Radicle team should focus on the Radicle protocol and the RSN team on its retrieval services.
• it’s imo very important that the Radicle protocol team treats all node operators equally vs prioritising one set of node operators.

Thanks for elaborating on the distinction between the teams - this is helpful.

@lftherios

I think we need to collectively revisit this definition, as it doesn’t apply to the current orgs. For instance the Radicle org depends on the Foundation org for maintaining the Radicle trademarks as well as its domain names. This was a conscious decision (not an afterthought). Also the Foundation org is not developing any technology at the moment.

@abbey

the Radicle Org isn’t explicitly just the protocol team. It’s technically currently responsible for UX, product development, onboarding, community support, and exploring its own sustainability. I believe a re-scoping of the Radicle Org might be necessary to clarify the role of Radworks as a funder & supporter of the Radicle ecosystem.

We are working on revisiting these definitions and trying to map out a discussion that can be had on the forum around this topic. Getting consensus on these definitions should remain a priority, as not having clear definitions has already proven to be crippling to effective community discussion.

@cloudhead

I’d just like to chime in to say that I have enough responsibilities currently and don’t need more

Also need to clarify what it would actually mean to have a Team within an Org and what the responsibilities would actually look like. The way a Team is described in the former Grants proposal draft (see version 6 under Reporting & Success Criteria), a lot of the responsibility around reporting & management would actually lie within the Teams, not the Org Leads. Abbey and I are also on this though and will be a part of the bigger discussion we want to facilitate.

@lftherios

We will be part of the Radicle community, similarly to hopefully hundreds of other developers. This team should not have any special privileges with regards to the Radicle org. We want the Radicle protocol to remain neutral to all node operators.

This is also a helpful distinction! Maybe make this clearer in the next draft of the proposal?

@abbey

My main concerns revolve around implementation

@lftherios

I have budgeted for 10 hours a week (that’s all I can provide for now) in

@abbey

With the official publicly-stated deadline for Radicle 1.0 release being end of Q1, I feel that taking a more iterative and progressive approach to bootstrapping this work is more appropriate, so we can remain light and adaptive pre-stable release.

I second @abbey and her concerns around the hefty implementation that would be required to set this up as proposed alongside the very short timeline (we are already half way through Q1). I really like her idea of leveraging a Grant to at least get a partnership with a 3rd party provider setup quickly before the end of Q1 so that the support is there when Radicle 1.0 launches.

That being said, I also agree with her that it would - in the long run - make sense to form a new Org to develop third-party seed node services. Just given the short timeline before Radicle 1.0 launch, your stated availability and the reality of setting this all up - it may not make sense right now if we want to serve the immediate goal of supporting onboarding for Radicle 1.0 launch.

@lftherios

High relative to what?

I guess relative to what I thought it would be. But I didn’t calculate in a marketing budget, offsite costs tbh.

@lftherios

The way I imagine it, it will be a subset of all Radicle users and potentially an additional audience that the Radicle p2p protocol can’t market to / isn’t relevant as is. That’s why I have allocated a marketing budget.

Hmm…I wonder if it would make more sense to first prove the service/value to Radicle and then invest in expanding marketing to others? Or generally get it setup first before pushing marketing? Just want to make sure we don’t put the cart before the horse with spending money on marketing for a service that has not been setup yet.

In any case, it would be great if you could add this detail to the next version of the proposal.

@lftherios

It’s 3 full-time senior engineering hires (including one team lead)+ my time until the team is fully operational without me.

Also good to know - please include this detail in the next version of your proposal so it is clear what folks are voting to fund regarding the team.

[lftherios]

Thank you for the feedback @abbey. Answers below:

@abbey

Have you scoped job descriptions for these engineers? What kind of hires (e.g. seniority, part-time vs. full-time) will they be and what experience are you looking for?

Yes I have scoped the job descriptions already. With regards to seniority and time commitments: they all senior engineers in full-time roles.

@abbey

Without any engineers onboard already, can you elaborate on how you scoped this objective? Is one quarter (three months) enough time to complete this objective fully?

I scoped this objective by consulting with engineers who possess relevant experience and drawing from my own experiences leading software projects over the years.

@abbey

Also, how does this service relate to the Radicle Org’s objective to “Q4: Start experimenting with paid offering, given product-market fit”?

I’m uncertain about the plans of the Radicle team in that regard. My approach to all proposals involves identifying what need to be addressed, determining when and how to tackle it as a DAO, and then presenting my arguments for public discussion in the forum. As a token holder, I still believe that the Radicle team would benefit from prioritizing work on the protocol and user interfaces. Meanwhile, a separate team, implementing the strategy I’ve outlined, could handle third-party seed node infrastructure.

@abbey

Does this include evaluating the feasibility of an incentivization model that incorporates RAD? If so, can you elaborate on how you would evaluate the feasbility of a decentralized, incentivized seed node network?

Indeed, this does entail the coordination and incentivization model for RAD. Our team plans to evaluate this through prototyping, simulations, and user testing. To provide further context, I believe the primary challenge with the decentralized service lies not in the tokenomics or incentivization model for RAD, as that aspect is more trivial. The real challenge lies in meeting the performance requirements necessary for efficient retrieval with a decentralized service. In my opinion, this challenge is predominantly latency related!

@abbey

How would you see this playing into the Strategy Committee’s work on sustainability modeling?

I am always open to contributions. Currently, the outcomes of this work are uncertain to me as it hasn’t been shared publicly within our community yet. My approach to all proposals involves assessing them here on the forum. It will be easier to discuss this in relation to a specific proposal.

@abbey

As you are already an Org Lead of the Drips Org, how many hours will you need to realistically contribute to bootstrapping this team and the first implementation of the centralized network? Is this possible with your current commitments?

I have scoped 10h a week for me. This time will be split between me hiring the team and working on research, low level strategy and execution. Yes, I feel that I can make that work. I personally consider this work extremely important and I plan to research this work even if this proposal is not funded, as I think it’s of strategic importance to the DAO.

@abbey

Does the choice of entity change since this would be offering a paid service (aka an entity with revenue)? Have you taken the timelines and costs of entity formation into account?

No. Swiss associations can have revenue, so there is no problem on that. Having done that already once for Drips, I have accounted for both formation costs and timelines.

@abbey

How will the revenue generated by the paid service be used by the proposed Association?

This is a great question and it’s something that I would like to discuss with some lawyers later in the year. I don’t consider this a blocker as there is plenty of time for that.

@abbey

Also, can you elaborate on why you think this work should be initiated as a new Org vs. as a grant?

As I wrote to @shelb_ee I really don’t have any preference here and I would like to hear arguments left and right. I defaulted to a new org as:

1. I consider this work long-term oriented (as long as Radicle is relevant, I don’t see any future where offering a 3rd party seed node service around Radicle won’t be a good opportunity)
2. I believe that this work benefits from separation of concerns from the existing orgs
3. A short-term grant will make hiring harder for me as the lead, especially for the caliber of engineers that I will look for
4. I don’t yet understand how tangibly I would be able to contract folks if there is no entity involved
5. The amount I am requesting is not currently available on the Grants org

@abbey

Can you elaborate on the marketing costs? What will those be used towards? And how are you calculating your contributor costs? What market rates are you using? Are your contributors full-time?

My idea with the marketing budget was the following: RSN will both target a subset of Radicle users (so no need for any marketing there, Radicle has a marketing budget for that), but will also target an audience that may not yet be aware or interested in utilizing the Radicle gossip network in its current form. I outline this in the reasoning section of my proposal. Consequently, I believe allocating a marketing budget would be beneficial in effectively reaching this broader audience.

@abbey

And how are you calculating your contributor costs? What market rates are you using? Are your contributors full-time?

Yes see above. These are senior full-time engineers on par with senior engineering rates from our core teams.

@abbey

Have you done an estimation of what resources/time will be needed from other Radworks contributors? I’m specifically thinking about the Foundation Org (Ops) and Radicle Org.

This work won’t need any special treatment from the Radicle org. As I wrote to @shelb_ee it’s my view that the Radicle org benefits by treating all node operators equally. The RSN services will consume Radicle’s code, build something on top of it and contribute back to the Radicle community a new service, documentation and hopefully some protocol patches here and there.

With regards to the Foundation org, I don’t think that we will need any substantial support. Having gone through this with the Drips org, I feel that we will likely need some advice and intros from @ange sporadically, but that should account to 2-3 hours a month for legal topics (that will likely benefit both orgs). If preferred, I would be happy to include a separate budget for legal advice from 3rd party contractors, which is something that I am missing on the current proposal. But I would like to hear @ange’s view on that.

With regards to ops we will work with external contractors and that’s already accounted on the budget. For context, the Drips org is receiving ops support of 4h a week from @sllyllyd (with 3x the size of the team).

@abbey

My main concerns revolve around implementation. If the goal is to get resources to fund developers ASAP, wouldn’t it be easier to submit a grant application to fund a third-party (e.g. Chainsafe) to build out the centralized solution or a single developer to ship an MVP?

Over the last 15 years that I’ve been involved with software, I have become extremely skeptical with outsourcing development to 3rd party teams. There are many problems with that most notably maintainance after the MVP is delivered, but mostly importantly quality and process. Shipping a product that resonates with people involves iterative development, that requires care and passion from the builders as well as short feedback cycles within the team. I’ve never seen the model of “we will send requirements and get software back” work for projects of moderate engineering complexity.

@abbey

With a grant, you could have the funds allocated quicker and require less operational overhead (and time on your part!) because you wouldn’t have to set up a new entity. cc @bordumb

Once more, I am receptive to the idea of a grant, provided that someone articulates why a grant is the preferred approach for this particular piece of work. Above I laid out the reasons for why I chose an org for this proposal. I would appreciate it if someone could delve into a similar level of detail to advocate for a grant.

@abbey

What if in six months nobody wants to use the centralized hosting service we just spent ~$500k in RAD developing?

In my opinion, every software project inherently entails both risks and opportunities. As a token holder, I perceive my role as discussing both aspects here on the forum to arrive at an informed decision. In this case, I believe the potential opportunities far outweigh the risks. Therefore, I consider it a strategically sound choice for us to invest in this endeavor.

[shelb_ee]

February Proposal Review Recording

The recording from the February Proposal Review call last night is live!

Please note there are timestamps that mark each question/new discussion from the call in the video description if you already want to go back and listen to specific parts of the discussion!

I am also working on a summary of key new points discussed, but wanted to get this out ASAP for folks to watch. I will have this up ASAP.

[shelb_ee]

Proposal Review Notes

Below is a summary of key discussion points that came up on the call yesterday. There are still many open questions concerns around setup and accountability. It will be critical to get these outstanding concerns clarified before the proposal moves into Formal Review on Monday (Feb 19th).

Reminder: You can check out the timestamps in the video description of the call recording to listen to discussion around specific points.

A few key new or clarifying points discussed on the call yesterday:

• Compensating contributors in RAD - Ele clarified that although the funds for this work would be requested in RAD, he plans to allow contributors to choose to be paid out in whatever currency they wish (crypto or fiat).
• Generalized service for broader p2p vs focus on Radicle: Ele prefers to start small and focus on being valuable to Radicle first and then expanding to broader ecosystem in the future.
• Why not use existing service? Ele explained that a lot of the existing alternatives are really early stage and might not be able to deliver what we want or need. Prefers to explore in-house, as it could be a great opportunity for our ecosystem to bring a differentiated and focused service to the market.
• Setup & Funding: “Org” vs “Grant”: Ele expressed again that he is open to either structure, but highlighted that he sees this as a long-term oriented project and would need long-term funding. It was discussed and clarified that no matter what structural path is chosen to setup and fund this work (Org or Grant), the team will have to setup its own, separate entity (Swiss Association).
• Fund accountability: Given it will be a new and currently unknown/unconfirmed team, a few folks expressed concerns around voting on a proposal that would give funds and responsibility to this team without knowing who they are giving it to. This concern is particularly relevant when considering the establishment of an “Org”, which holds a unique and trusted status within the ecosystem. There were calls for the addition of a substantial accountability mechanism to this proposal before moving forward to vote. A few possible ideas and solutions that were mentioned in the call.
  • Could stack Swiss Association for this team with existing, trusted contributors to start out, could transition power/membership over to new team as trust builds
  • Possibly use Drips as a payout mechanism over time to have more control over funds
  • Distribute funds via Grants Org - Already have a model in place for conditional (milestone-based) distribution of funds. Possibly have funds for this work be distributed via Grants to utilize this review process as trust in this new team builds.
• Potential revenue: The question of what would happen to revenue if the entity were to generate revenue over time came up. Some possibilities that were discussed were to potentially have the revenue return to the Radworks treasury or make the entity a non-profit, BUT there are still many outstanding legal questions around what different options would mean.

[vanton]

First, I really love the idea of both centralized and decentralized nodes. This approach effectively leverages Radicle’s value and makes it accessible to a broader developer base.
I have a couple of questions though.

1. If the association is for-profit and generates income, who will constitute the membership and how will profits be distributed? Are “stakeholders” synonymous with “members” in this context?
2. While the plan mentions hiring three senior engineers, could you elaborate on the need for other roles? Developing and marketing a new product/service typically requires personnel beyond engineering, such as product developers, product managers, and potentially market research specialists. Specifically, tasks like market discovery, value proposition validation, product strategy, and roadmap development seem crucial from the outset.

[ange]

Hi Ele,

In addition to the main concern I mentioned on the call Wednesday (about the unknown Org Lead who will control the funds after you transition out of the Org Lead role this year), I wanted to mention that I would be open to supporting in the initial operations setup for this Org. And refining the budget (including Ops, etc) for the final vote.

[lftherios]

Thank you for the support and the questions @vanton.

@vanton

If the association is for-profit and generates income, who will constitute the membership and how will profits be distributed? Are “stakeholders” synonymous with “members” in this context?

I am planning to address this on the formal proposal as well, but this is the plan I have:

With regards to the organisational structure I am planning to create a new Swiss Association, with three known trusted community members as equal signers / members.

Any income created in 2024 from the centralized service will be applied against any 2025 budget this Org requests from Radworks. In the scenario, that the income generated is higher than the proposed budget for 2025, we will discuss on the forum and vote and then the association members will implement the community’s decision (the reason why they are there).

From the start, the Org will also license any code developed under a permissive FOSS license and make Better Internet Foundation (non-profit) owner of any future trademarks and domains.

This way this new team will be aligned with the DAO.

@vanton

While the plan mentions hiring three senior engineers, could you elaborate on the need for other roles? Developing and marketing a new product/service typically requires personnel beyond engineering, such as product developers, product managers, and potentially market research specialists. Specifically, tasks like market discovery, value proposition validation, product strategy, and roadmap development seem crucial from the outset.

I generally prefer to start with a lean group of technical folks, given the nature of the product and audience. This is what we’ve done previously with Radicle and Drips.

With regards to marketing, the budget requested will be used to contract with a marketing agency that will work with the team lead and bring this to market.

With regards to product, validation and strategy, this is work that I expect myself and the future team lead to do. Again I would like the team lead to be technical in nature, but bring some of those qualities to the role.