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:
- Radicle’s vision (high level, DAO-wide vision)
- Code collab vision (incl. all teams - protocol, product, growth, marketing, community, etc)
- 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)