Creation of a Product Group

[Kaidao]

Description

This proposal is to discuss the creation of a Product Group within Radicle. The goal of this proposal is to ensure teams can effectively collaborate across Radicle.

Background

The Radicle code collaboration ecosystem is currently designed for users to use both the CLI and Upstream in order to effectively collaborate on their development projects. Thus, it is essential for the features within both tools to be compatible as users will be experiencing the platform as a whole rather than distinct parts.

This has proved a challenge for our organization as we operate in a decentralized manner. A clear example of this problem is conflicting implementations of various features that solve similar, if not the same, user problems between Upstream, Radicle CLI, and Radicle Web App. While the current decentralized structure empowers teams to make their own decisions both from product and technical perspectives, it also presents friction for users using our platform.

In this proposal, I will outline what I believe should be our primary strategic goals, what I see as the core challenges we’re facing when developing the core Code Collaboration product flow, and what I think could be short-term and long-term organizational solutions to help solve these problems.

Primary Goals

This section will outline a set of core goals that I believe we should strive for as an organization, and detail why I believe it’s important for us to align around these.

Ensure a seamless code collaboration user experience.

This is our top priority. In order for Radicle to be competitive in the marketplace, and successfully acquire users that currently rely on platforms like GitHub, we need to ensure that we are able to provide a seamless core code collaboration experience. This is especially important for our priority team persona (development-focused DAOs) as their teams rely on this workflow for their DAO’s success.

Minimize team and development inefficiencies.

Although talented and capable, our team of core contributors is tiny relative to the teams that are building competing platforms. It’s unlikely we will ever achieve the number of resources to directly compete in terms of developer throughput. As such, it is vital that we prioritize our limited resources to provide the maximum amount of user value while minimizing overall development costs.

Focus on innovation throughput.

In addition to effectively utilizing our limited resources, we must optimize for agility. We all know how quickly our industry moves, which allows us the advantage of satisfying unmet market needs if we can quickly capture these opportunities. It’s likely we will soon see competing products that are also trying to meet the market. We should make the most of our first-mover advantage through quick innovation and value delivery. This will also allow us to effectively compete against large, sitting incumbents in our space.

Core Problems

In this section, I’ll outline a few core problems that I’ve seen, starting at the high level. I’ve also outlined an example of each problem which I believe are the symptoms of each of the core problems.

Team Misalignment

There seems to be misalignment between teams in multiple areas, including product vision, feature prioritization, and technical implementation. As mentioned before, our products rely on each other to establish a seamless experience for our users. Any misalignment ultimately results in a disjointed user experience for users and makes it much more difficult for teams to effectively use Radicle as their primary code collaboration platform.

Example: We have not been able to come to an agreement about how we should implement patches across Upstream and the CLI. Currently, this (same) feature is being developed using 2 different implementation methods, and will not be compatible across the tools.

Duplicate Efforts

There are instances of various teams trying to solve the same user problem. In itself, this is not a problem, but when combined with team misalignment above, ultimately adds to the risk of a confusing user experience. This will result in an increased risk of user churn, a low rate of user acquisition, and redundant development efforts.

Example: Both the Upstream and CLI teams are beginning to scope and develop user features around issue management and organization management. We have not been able to strictly align our efforts in order to create a holistic user journey across platforms.

Conflict Resolution

Currently, when there are alignment conflicts that arise between teams, there is not a clear path to help resolve the issues. We rely on ad hoc coordination between the teams, which doesn’t always result in a clear consensus. This not only introduces friction between our teams but also results in slower development speed and value delivery.

Example: There have been multiple discussions around the feature scope of both Upstream and the CLI. Many times these scoping discussions result in conflicting ideas about what features belong on which platform. This ultimately leads to each team developing what they think is the right way to tackle the same user problem, resulting in end-user confusion.

Proposed Short-Term Solution

In order to tackle the above-stated problems, I propose we create a Product Group. At a high level, this Product Group will be responsible for helping determine the overarching Radicle Product Vision for code collaboration and help facilitate team collaboration and alignment. The group could be formed with the following parameters:

Topology

This group could be a cross-functional team of 3-to 4 individuals representing the core aspects of Product, Design, and Technology.

Responsibilities

This group could be responsible for working among themselves to determine various Radicle-wide strategies, including:

• Product Vision: This team could help determine the core product strategy and vision. They would be responsible for identifying and tracking market activity, competitor landscape, and core user needs in order to build informed product strategies for Radicle to remain competitive in the marketplace.
• Priority User Problems: This team could be responsible for gathering, synthesizing, and prioritizing user problems. By initially aligning on these issues, we can ensure teams are consistently delivering user value.
• User Research: This team could be responsible for running user research projects, understanding our core customers, and helping define our priority segment’s needs. The results of this work will help teams understand how best to solve various user problems within their platforms.

Collaboration

This group could also be responsible for helping teams effectively collaborate, assist in spinning up platform teams, and help arbitrage any potential conflicts that arise. This will obviously be on an ad-hoc basis, but could include:

• Defining Cross-Functional Work: This team could help define and prioritize work that will affect Radicle as a whole (e.g. general marketing/product documentation). This could include organizational work, such as general documentation and marketing.
• Conflict Resolution: This team could act as a neutral third party to help resolve any technical or product conflicts between teams. For instance, if teams were conflicted on two approaches in various tools to solve similar user problems, this team could help provide user research data to identify the optimal solution.

Example Structure

Potential Long-Term Solutions

Sub-DAOs

Evolving from the aforementioned Product Group, sub-DAOs can be created that sits between the “main” DAO and the various product teams. There could be various sub-DAOs including Product, Technology, Design, and other cross-organizational functions such as Legal. The primary goal for these sub-DAOs is to help facilitate coordination and alignment between the product teams. These sub-DAOs may be responsible for:

• Communication and alignment with the main DAO on budget and vision
• Aligning core product vision and features for product teams
• Determining priority demographics and organizational OKRs
• Aligning implementation details, such as data structure
• Align on product strategy
• etc.

Basically, the core idea for sub-DAOs is to help decide on a direction for questions that will affect multiple products and users expect to work across the ecosystem.

Shared Libraries and Primitives

We can strive to create common components that can be shared across all the tools in the Radicle ecosystem. These common components will help maintain a consistent style and ensure compatibility across tools. The goals are:

• Ensure consistent user experience across the ecosystem
• Ensure compatibility for cross-functional features across all tools
• Increase development throughput by providing extensible components

As an example, there could be a team that’s specifically focused on building the networking layer, whether it’s a p2p or a push/pull implementation. They would be responsible for testing which implementation would work best. Once finished, product teams would decide on a direction and implement the chosen networking solution into their products to ensure compatibility.

Cross-Functional (Utility) Teams

We can establish cross-functional teams that will own aspects of the product ecosystem that span across various teams. These teams would be responsible for ensuring that users have an understanding of Radicle as a whole. They could also be responsible for creating and maintaining documentation that spans multiple tools, helping user onboarding.

Feature Teams

Currently, our teams are structured around separate products. When users are expected to use these various products in their complete workflow, it inevitably results in both technical and product dependencies between teams. One way we may be able to mitigate these dependencies are by structuring teams around full features, and giving them full control over how a feature is integrated, regardless of the application (distribution channel).

An example of this: Team A would own the entire commenting system. They would have full autonomy to build the foundational primitives to power comments.

Teams B and C would own the application layer, Upstream and Web App. Teams B and C would initially work with Team A to define where comments may be needed within their applications, helping shape the initial requirements.

After Team A is finished with the full implementation, Teams B and C would integrate comments into their application.

Example Structure

[alexgood]

The proposal here seems to be that we should adopt a top down org structure so that we can more efficiently deliver a specific product outcome. I have a few tactical issues with this and then a more fundamental objection to the implied objectives.

Top down org structures in a DAO world

Both the short and long term proposals seem to be suggesting a structure with some set of people (whether that’s a “Product Group” or a sub-DAO) who’s role is to set the vision for the project, define work for other teams to do, and aid in conflict resolution. These structures imply a very different distribution of power, and a different working environment to that which we currently have. Here’s my problem:

I am sceptical that “vision” is something which can be defined on it’s own as a work product, without being embedded in the teams doing the actual work, but putting this scepticism aside, there is a more fundamental problem. The structure here assumes that there is some objectively correct vision and technical outcome and all we have to do is find it. In my opinion this is not the case at all, these things are driven by values and experience - we all have different views. As an example: you say this:

For instance, if teams were conflicted on two approaches in various tools to solve similar user problems, this team could help provide user research data to identify the optimal solution.

The implication here that if we just go and do the research we will find something which convinces us all of some approach. In my experience though, these disagreements are often not over the technical benefits of different approaches, but disagreements over values. Should keys have granular use and be quickly rotated or should they be widely used and well guarded? Should networking be designed for censorship resistance? Should we design some kind of private repository? These are all questions that require an appeal to some underlying set of values to answer.

For a separate product group or sub-DAO to be useful then, they would need some way of enforcing their decisions on other groups, as an appeal to technical arguments will not resolve most conflicts. This means that the product group would need to have some authority over other groups. For example this could be achieved by making other groups answerable to the product group for budgeting on a quarterly basis. Any such structure will - I believe - inevitably involve introducing layers of reporting, with groups being incentivised to produce outcomes defined by whatever mechanism is used to enforce decisions on them. In short, we would end up looking very much like a traditional company. I would find this disappointing.

Products vs protocols

My more fundamental disagreement is with the idea that there is some singular product we are trying to build with a very specific set of objectives and constraints. Namely this:

In order for Radicle to be competitive in the marketplace, and successfully acquire users that currently rely on platforms like GitHub, we need to ensure that we are able to provide a seamless core code collaboration experience

I can only speak for myself but acquiring users from Github is not what gets me excited about Radicle. I’m interested in building a protocol for code collaboration that affords much more flexibility and autonomy to users than centralized platforms tend to. I do believe that this results in competitive advantages and will ultimately lead to more people using it - but my primary goals are building something that I can use with the people I collaborate with. My point here is that different contributors to Radicle will have different objectives.

The presence of these different objectives is what motivates us to build protocols rather than products - rather than trying to define a monolithic user experience which the entire ecosystem aims to implement I believe we should aim to define the minimal constraints which allow us to collaborate on the things we do agree on. In this manner we can accomodate a plurality of values without needing a top down power structure. To me, embracing plurality and autonomy is the point of open source development - I think it does lead to some (sometimes frustrating) redundancy and short term interoperability issues, but I think over the long term it can produce more valuable software that respects users.

With respect to redundancy - whilst building multiple versions of an application may seem wasteful, building multiple implementations of a protocol based on the same speicifcation can be very valuable. It ensures that the protocol is interoperable. I particularly believe that having multiple overlapping applications with different focuses building on top of the same protocol is an excellent way to test which parts of the protocol are useful and which are not - whilst it may look like irritating redundancy to you, to me it’s delicious hypothesis testing.

So what?

My read of the underlying frustration that is motivating you is that you want to provide a “seamless experience for our users” and you want to do it faster. Certainly we could get there by reconfiguring ourselves into a product focused company and executing a product leaders vision - that’s a well worn road. I believe this would not produce a useful protocol however, it would just produce an open source product. My feeling is that fundamentally the pace of protocol development is much slower - see for example the Matrix protocol, I recall Matthew Hodgeson say he thinks it took them six times longer to produce a chat protocol vs a chat product. Nevertheless I think that a protocol is the right path for a source code collaboration tool.

What I do think is that we could do with a discussion around how we evaluate our performance as a protocol and if there’s one thing this giant essay I’ve written shows - it’s that we could do with a discussion about vision, even if that doesn’t mean we create a product group.

P.S

As an example, there could be a team that’s specifically focused on building the networking layer, whether it’s a p2p or a push/pull implementation.

I think that’s the Link team

[fintohaps]

First, I’d like to second @alexgood’s take – especially since my initial thought was, “What happened to ‘protocols not platforms’?”

To add to this, I think that this solution feels like we’re trying to organise our way out of these issues – which we should note that this was attempted on multiple occasions, in different ways, in the past. Instead of focusing on the organisation between teams by adding another layer, perhaps we can shift focus towards processes between teams?

For example, we can improve the resolution of the example conflicts you mentioned by having open, long-form discussions where we can properly debate the merits and downsides of solutions proposed by teams. These discussions can surface the commonalities between the teams, extracting the common denominator as a protocol and applications adding their own flare on top of it. They would also serve as a forcing function for the initiator and responders to really think through the problem when proposing it.

The essence of what I’m saying is that we should be attempting to discover the common denominators for these applications. Implementing these as protocols. Then allow applications to explore in their own style – naturally creating healthy competition – but respecting users by being interoperable due to the nature of commonality.

[Kaidao]

Thanks so much for your thoughts here. I wanted to provide a couple of initial thoughts:

Yes, overall, the proposed structure would shift us towards a more traditional organizational structure, although one thing I’d point out is that although this “Product Group” would be responsible for formulating a product vision and priority list, there will need to be a decentralized and democratic process for teams to agree that the proposals should be adopted.

The structure here assumes that there is some objectively correct vision and technical outcome and all we have to do is find it. In my opinion this is not the case at all, these things are driven by values and experience - we all have different views

This is also correct. I’m assuming that what we’re hoping to achieve is a unified product vision that will help teams build platforms/products that help serve that idea. You ask a good question as to whether that’s what we actually want to do. In my opinion, I can see the benefits of both sides. On specifically the code collaboration front, the benefit would primarily be a consolidated user experience. The downside is that teams will have less autonomy and there will be a more top-down, traditional decision-making structure.

As you mentioned, there are inherent pros and cons to this approach. The tradeoffs we should make should largely depend on the core objective of Radicle as an organization.

My more fundamental disagreement is with the idea that there is some singular product we are trying to build with a very specific set of objectives and constraints.

I think this is an important discussion topic as well. I do agree with you - I think it may make sense for teams to have different objectives and goals so there may be more than one answer here. For instance, potentially the experiences that help deliver a code collaboration experience could (and in my opinion, should) have a unified vision, while some of the platform teams may have more autonomy to test ideas and build protocols.

That said, another potential idea is to have a structure such as below that combines the code collaboration experiences and allows other teams to operate autonomously. The code collaboration teams can then integrate with the protocols as consumers when needed.

Example Structure:

[fintohaps]

I’ve been thinking about this more and I think there’s merit in the idea of a group tackling a shared goal together. I believe, however, that a Product Group is too large and vague of a scope. So I’d like to present the idea of a Code Collaboration Working Group (WG for short). I’m picking code collaboration because it seems to be the hot topic that has caused conflict between the two application teams. In general, there could be many working groups working on well-scoped areas. They would be short-lived only needing to be around long enough to define the base work and implementation.

So, what does a Code Collaboration WG consist of, what does it do, and how does it do it?

• It would be made up of a small focused team – as you had proposed above. It would necessarily be made up of product/UX individuals and engineers. Preferably, one from each stakeholder team. For example, the team could be made up of:
  • Alexis – alt-clients product + engineering
  • Kai – upstream product
  • Thomas – upstream engineering
  • Alex – link engineering (protocol)
• The smaller team allows for ease of reaching a quorum locally when exploring the various solutions for code collaboration.
• The working group’s job is to then explore solutions for code collaboration. The group needs to understand what it means to collaborate in a decentralized protocol – What are the challenges? What existing technology can we use? Where do we need to innovate? etc.
• Their findings MUST be documented and presented to the wider audience of the ecosystem, ideally through RFCs and decision logs, where other maintainers and contributors can communicate their thoughts, qualms, and support. It must be done in open forums – and may require multiple forums, eg. something that changes the radicle-link protocol has to be discussed via the mailing list (until we get code collab of course ;)).
• The goal of all of the above is to define a common denominator for the use of any application being built on top of this. An interoperable protocol – which in this case, I think we are part way there with collaborative objects.

I’ll reiterate, that I don’t think we will solve this misalignment by creating more organisation. I think we will solve it by properly aligning how we communicate and come to decisions. Having a WG of different stakeholders will promote cross-team communication. Having open discussions will improve buy-in from all members of the ecosystem – and also allow people to point out flaws in the designs, hopefully making our architecture more robust.

Let me know what you think

[sebastinez]

First of all I wanted to thank @Kaidao for writing this proposal and @alexgood for the great take on the protocol vision!

While I think that the conflicts on topics that touch alt-clients and upstream, like the mentioned patches implementation, are surely things that need to be discussed and a consensus to be found, I agree with @fintohaps that they can and should be tackled by a working group (WG).

I will add that this WG should not be “on top” of the product teams but parallel to the product teams, since the group would consist of all the core leads, and they should be interested in achieving a consensus and documenting their findings in RFCs which every contributor can and should read.

Also to add I understand the redundancy of features existing on multiple implementations, but I don’t see it as a negative thing, apart from the slower progress which is native for protocols, but as a broader stance on the multiple implementations we are creating, and looking at the big platforms, although they have much more development “power” they do the same in the end.

What I do think should be standardized and shared across product groups (and eventually we would need another working group for that like Radicle Standards Working Group) is a crate/module akin to radicle-common with basic implementations of primitives (issues, patches, etc.) which would be maintained by the SWG and any changes discussed in a monthly or weekly meeting, similar to the ChainAgnostic CASA meetings.
Maybe to start both these tasks could be made in the same working group to not overload the core leads with working groups

[Kaidao]

Thanks, @fintohaps, and @sebastinez for your thoughts!

I totally agree with the general outline of the Code Collaboration WG. I believe it’s very similar to the original intent of this proposal. Specifically, the idea that the consensus and ideas that come out of this working group should be public and shared with the community. The goal for this group is strictly to streamline collaboration.

There’s one aspect that I’d love to get people’s thoughts on:

The working group’s job is to then explore solutions for code collaboration. The group needs to understand what it means to collaborate in a decentralized protocol – What are the challenges? What existing technology can we use? Where do we need to innovate? etc.

I might suggest that this WG should actually not focus on the solutions themselves, but instead, focus on the user problems that exist, and form hypotheses on how we might solve them with our current technology. These findings can then be communicated to the individual teams and the individual teams would be the ones developing the solution. Once the overall solution(s) are designed, the WG could help advise and ensure that these solution(s) will effectively solve the user problems as well as be compatible with each other.

I believe this dynamic will help ensure collaboration and compatibility while allowing teams to maintain their autonomy.

What I do think should be standardized and shared across product groups (and eventually we would need another working group for that like Radicle Standards Working Group) is a crate/module akin to radicle-common with basic implementations of primitives (issues, patches, etc.) which would be maintained by the SWG and any changes discussed in a monthly or weekly meeting, similar to the ChainAgnostic CASA meetings.

I also really like this idea. I totally agree that these primitives could be developed by specific teams, and various experience teams can then choose the best way to implement these primitives in their experience for the best user experience.

[fintohaps]

@Kaidao

I might suggest that this WG should actually not focus on the solutions themselves, but instead, focus on the user problems that exist, and form hypotheses on how we might solve them with our current technology. These findings can then be communicated to the individual teams and the individual teams would be the ones developing the solution. Once the overall solution(s) are designed, the WG could help advise and ensure that these solution(s) will effectively solve the user problems as well as be compatible with each other.

I believe this dynamic will help ensure collaboration and compatibility while allowing teams to maintain their autonomy.

I somewhat disagree, but it may be down to the use of definitions here I’d like to split up the term solution into separate components:

1. Technical design
2. Technical implementation
3. Product design
4. Product implementation

I think 1. should be the output of the WG, whereas 2., 3., and 4. are informed by 1.

Having focus on user problems should definitely be part of the focus, but I don’t think it can be done without also thinking about the technical problems.

For (a hypothetical) example, say a user’s problem is organising a workflow and the WG decides a kanban flow makes the most sense. This is easy to state as a potential solution, however, it doesn’t take into context the inherent model of our technology stack – decentralization and local-first data. To explore that solution the WG would think about how that might be designed technically to see if it is at least viable given the technological constraints.

But even better, they would explore multiple problems trying to identify a unifying solution, ie. a protocol that puts the power in the user’s hands for defining kanbans, or discussion threads, or a whole JIRA system.

The flow from end to end would become:

• Explorations of problems and technical space
• Communicate findings, propose a technical design, and receive feedback
• Implementation of the technical design
• Build products on top of technical design

I think this is an improvement to what you’re suggesting because if individual teams work on developing solutions, we could still end up with N solutions that differ, and then it’s the burden of the WG to herd cats to get these solutions to comply with each other.

Instead, there should be a clear technical design and implementation that serves as the building blocks for building different product features that are compatible.

Protocols Not Platforms

But as you said, I think we are on the same page about a group at least. I think the next step would be to get other team leads involved in the conversation to get their thoughts on the matter. We could then discuss the scope, size, and makeup of the WG. This isn’t a new concept either so I think we would benefit from doing some research on how current working groups organise, eg. the W3C and the Rust Foundation.

[abbey]

Hey all!

I really really enjoyed catching up on this discussion. Thank you all for your thoughtful contributions. I think the form & function of this Code Collaboration Working Group that has emerged through the discourse is great and I’d love to help it get off the ground.

Since it seems that there’s general agreement that this could be an interesting path to explore, what can we do next? It seems like we need to source buy-in from relevant stakeholders. If we’re going off of @fintohaps’s initial proposal for who should be included, it seems that we’d still benefit from having @cloudhead and @geigerzaehler share his opinion’s on the discussion. @fintohaps / @Kaidao — maybe running an open call on Discord could be a good next step? Can help coordinate. Let me know.

Additionally, working groups that work in parallel to Core Teams is a great organizational concept that I’d love to explore further. It would be great to define the scope, size, and functions of a WG so they can be “packaged” and used across the project by contributors looking to solve other cross-team problems. What I mean in practice is developing “some” process for creating & managing working groups, similar to how the Rust community does.

They have documentation for what a working group is, how to create one, and what expectations & requirements WGs are expected to adhere to (see Forming a new working group | Rust Lang - Compiler Team). Each working group is also expected to maintain a public repository of notes/general info (see Working Groups | Rust Lang - Compiler Team).

I could totally see Radicle maintaining an autonomous network of WGs that support cross-team communication & collaboration. And I think that honing in on code collaboration is a great way to stress-test the concept!

@fintohaps and @Kaidao I’d look to both of you to take us forward into next steps. Happy to support with coordination

[fintohaps]

Thanks for those links! It’d be great to get people on a call to a have a free-form discussion on what others think and what the next steps can be. It’d be great if you could facilitate that @abbey

[matto]

I’ll chip some general wafflings into the mix as I’ve been thinking a bit about this through a slightly different lens over the last couple of months.

It feels like “vision” is being used to describe three different things here:

1. Radicle’s vision (high level, DAO-wide vision)
2. Code collab vision (incl. all teams - protocol, product, growth, marketing, community, etc)
3. Product vision (product teams, as separate from protocol)

To your point @alexgood, I do think this structure is hierarchical in nature, but I think this hierarchy is useful as a way to achieve unity within the DAO rather than to support any kind of power structure, and that that unity is important for people to feel like they’re working together towards the same goals. Each level can be created in a collaborative way, and can be applied both top-down — as a framework for assessing/scoping existing projects and for coming up with new initiatives — and bottom-up — as a way to re-assess and adapt our higher-level goals.

At the highest level, Radicle’s vision is being discussed and covered in the Collaborative Vision post here. Fleshing that out could help to set some direction for the code collab and product visions.

Code collab vision

Just as our wider goals as a DAO should inform our goals for code collab, a high-level vision for code collab is important to help formulate our protocol and product visions and the relationship between them.

Something to consider here is that protocol and product development are two very different things, and there’s a tension between these two that any high-level vision should aim to reconcile.

My understanding was that our long-term vision is to create a widely-adopted, open protocol ecosystem for code collaboration, and that this was decided on as a viable way to pursue the wider DAO’s goals of supporting and enabling the growth and sustainability of open source software (or something to that effect…)

With this view, the purpose of our code collab products is not necessarily to create a set of successful products, but to facilitate the wider vision of creating a successful protocol ecosystem. These are of course related, but I’d argue that this goal is fundamentally quite different from the normal goals of product development, and so I think it is important to keep this framing in mind.

What is the right path to success as a protocol ecosystem?

@Kaidao’s original post focuses a lot on product, and product quality, as a primary goal. This might be based on the assumption that one path to creating a successful protocol ecosystem is to create a singular product experience that rivals that of GitHub’s. That’s a fair assumption, and I think it’s largely true, but I also think it misses some crucial things.

Firstly, I think you’re right in that to be successful long-term we do need to be able to compete with GitHub in some way. I’d be curious to know if everyone is aligned on this view. At the same time, I don’t think we can, or should be trying to, compete with them primarily on user experience. This is for a few reasons: (1) they have a top tier product that has taken a vast amount of resources to build, (2) it’s hard to compete on UX in decentralised vs centralised architectures (3) they are deeply embedded in tech stacks already and deeply entrenched in the market and (4) the sentiment towards GitHub is generally very positive.

I also don’t think we can compete on the idea of decentralisation, or on the idea of being a protocol. My feeling is that, when selecting products, the vast majority of users give more weight to features that have a more immediate and tangible impact on them. And so, without capitalising on our decentralised or protocol architecture, we are handicapping ourselves, as development is slower and more difficult, and we have to figure out alternative solutions for product features that were built on centralised platforms, many of which result in further UX challenges or compromises. These ideas only convert to adoption when they start to offer significant and tangible benefits to end-users. Things like censorship resistance are not significant enough to tip the balance for most users, especially if it means compromising on other things.

Attracting builders into our ecosystem is another approach we could take to try to capitalise on our architecture. But, even with feature parity, I’m sceptical that a protocol ecosystem containing many smaller products would be enough to compete with a platform as entrenched as GitHub in a meaningful way. This is debatable, but I think the best case outcome here is a long and difficult road to adoption.

So where does that leave us?

If we can’t compete on the same feature set, it follows that we need to be offering something different. Personally, I think we need to be offering something unique and impactful enough that it overcomes all of the above challenges and makes the Radicle ecosystem compelling enough to developers and OSS projects that they would make compromises in other areas in order to become a part of it. I think exploring and fleshing out ideas along these lines should either be the responsibility of the code collab WG or, given the broad scope, a whole WG in itself. I have some ideas for avenues to explore here & will try to compile them into a forum post at some point, so if anyone is interested in chatting about this then HMU.

Product vision

Our product vision should aim to serve our broader goals for code collab, so this follows on from the ideas laid out above.

Normally product development is aiming for user adoption and retention, but in our case those goals are only important insofar as they move us towards achieving our wider vision of building a successful protocol ecosystem. With that in mind, here are some other ideas & thoughts that could form a part of our approach to product development within code collab:

• Seeding the Radicle ecosystem - I’m not sure we can expect to get protocol adoption based on a protocol strategy of “build it and they will come”, and so seeding our ecosystem with high-quality products feels like a good way to bootstrap and accelerate adoption.
• Facilitating protocol development - given that the protocol exists to serve the products built on top of it, there’s a lot of value to be gained from our product teams testing, providing feedback, and helping with roadmap prioritisation around the protocol.
• Facilitate builders - our products can facilitate builders entering our ecosystem by providing implementation examples and offering re-useable packages and components. This goal puts more emphasis on code quality, re-usability, documentation, etc.
• Attract users to the protocol - We want to attract users to our products because it benefits the wider protocol ecosystem*.* This creates a flywheel where more users → more builders → richer ecosystem → more users. A successful protocol does rely on successful products, but we also need the protocol to be leveraged beyond the products that we are building within RadicleDAO.
• Feature experimentation - This should be done when it benefits the wider protocol ecosystem — such as when it facilitates protocol development — and it should be approached with care when that benefit isn’t clear.
• Unified UX - There’s a conflict here between (1) creating a more polished cross-product UX (2) creating a variety of more targeted products and (3) redundancy and feature overlap as a way to test the protocol. There’s value in all of these things and there are so many factors to consider here that it feels like this is a topic that needs a lot more discussion in order to figure out the best path forward.
• Product end-game - If the products were to achieve their primary goal of creating a thriving and healthy developer ecosystem around our protocol, then arguably they will have served their purpose and at this point could be spun out from RadicleDAO. I say this more to emphasis the role of product strategy than anything else, and this might be a terrible idea in reality.

TLDR

For reference, here’s a tldr of some of the questions I’ve raised or given my own take on in this post

• Is our primary goal for code collab to create a thriving protocol ecosystem? What scale?
• What is the role of product in this vision?
• Do we need to compete with GitHub / other platforms on any level in order to achieve this?
• Should we be trying to compete with them primarily on UX?
• What would it take for a user / project to migrate from GitHub to Radicle?
• What possible paths lead to meaningful adoption? On what timeframes?
• Should we be exploring more unique and compelling offerings as a priority?
• How should we be thinking about UX across products (unified/polished vs overlapping/experimental)

[Kaidao]

Hey @matto ! I really appreciate the post here, and I agree with a lot of what you’re saying. As you know, in the last few weeks, we’ve been discussing product consolidation on the code collaboration front. With the sunsetting of Upstream, it is likely that it’ll be much easier for our team to build a cohesive product on the code collaboration side. In the short term, I believe this will actually solve many of the problems outlined in my initial post, as we’d essentially have one team building the core code collaboration product.

That said, I’d like to give a few thoughts on some of what you mentioned:

With this view, the purpose of our code collab products is not necessarily to create a set of successful products, but to facilitate the wider vision of creating a successful protocol ecosystem. These are of course related, but I’d argue that this goal is fundamentally quite different from the normal goals of product development, and so I think it is important to keep this framing in mind.

While I do agree that the definition of success for products vs protocols will inherently be different, I do believe that the processes required to create both successful products and protocols are fundamentally similar. In order to achieve either of these goals, there are certain core product practices that I believe will help us be successful, specifically:

1. User research to identify user needs: Regardless of whether the user is a end-user (consumer) or a developer building on top of our protocol, it is important for us to deeply understand what their needs are so we can build valuable tools that will be used.
2. Effective prioritization: Having a framework for prioritization will allow our teams to provide the greatest value to our users (either end-user or developer) in the least amount of time, using the least amount of resources.
3. Cross-team collaboration: I believe all product teams would benefit from effective communication and collaboration, allowing our organization to strategically partner when beneficial or hedge our bets when necessary.

I also don’t think we can compete on the idea of decentralisation, or on the idea of being a protocol. My feeling is that, when selecting products, the vast majority of users give more weight to features that have a more immediate and tangible impact on them. And so, without capitalising on our decentralised or protocol architecture, we are handicapping ourselves, as development is slower and more difficult, and we have to figure out alternative solutions for product features that were built on centralised platforms, many of which result in further UX challenges or compromises. These ideas only convert to adoption when they start to offer significant and tangible benefits to end-users. Things like censorship resistance are not significant enough to tip the balance for most users, especially if it means compromising on other things.

I completely agree with this. In my opinion, it’s not feasible for us to go head to head with a product like GitHub for without significant resource shifting and organizational alignment. Even then, we will likely only be able to target a niche segment in the market for all the reasons you mentioned.

Our greatest value proposition and differentiator is our decentralized architecture. It’s absolutely necessary for us to lean into this. The question, in my mind, is how we can achieve adoption of our protocol. It seems like our current strategy is centered around building the protocol, while offering a complementary product. This strategy is similar to what Uniswap did - they first created the Uniswap Protocol, and complemented that with the Uniswap trading app. The trading app was offered at essentially zero cost to end users in order to bootstrap the network effects for developers to expand on the underlying protocol.

Final Thoughts

Overall, I agree and resonate with the majority of what you mentioned, and I appreciate you taking the time to respond in depth. To summarize my ramblings above, a few key takeaways are:

• I believe regardless of whether we are hoping to achieve success as a product or a protocol, there are various product principles that should be applied as an organization.
• We need to lean into our core value proposition of the decentralized protocol, which should be reflected at an organization level.
• Both our product and protocol teams can benefit from having a clear idea of what the Radicle organization’s goals are, and understanding how their specific teams fits into the overall strategy.

I believe the proposed WG can help facilitiate some of these. The scope of the group’s responsibilities is still TBD, but the idea of a parallel (to the core teams) group working to help capture and provide user insights as well as help cross-team collaboration could be extremely valuable.

To touch on @abbey 's thoughts above, I’ll be formalizing these thoughts into a more formal document. It would be awesome if we could meet in the next few days, @matto , @alexgood , and @fintohaps , to throw around some ideas. Would you all be open to that?

[fintohaps]

@Kaidao

To touch on @abbey 's thoughts above, I’ll be formalizing these thoughts into a more formal document. It would be awesome if we could meet in the next few days, @matto , @alexgood , and @fintohaps , to throw around some ideas. Would you all be open to that?

Ya, sounds good to me! I’m open from Wednesday onwards

[matto]

Ya. I can do any day except Fri.