Been spending the weekend reading through and organizing posts from the last year. There’s a lot of amazing ideas and initiatives in play or in the pipeline. Would like to explore how this might all look from a product development standpoint.
Out of the box SourceCred measures activity to create a graph that aims to measure value creation. Then we have plugins (Initiatives, Boosting, Artifacts, SuperNodes, Cred voting, etc…) to help communities (just us atm) enhance that graph to move beyond raw activity. This is similar to Discourse where you have the basic forum framework that works and works very well, but can also be customized with plugins (some officially supported and some 3rd party).
Does everyone else see SourceCred evolving as a flagship protocol that “just works” along with plugins to customize the game as users desire? Or are there other ways we see SourceCred evolving, and if so, what does that look like and why?
I think for the long run the out-of-the-box experience is going to be a separate “bundled” SourceCred. One that’s specifically packaged for analyzing other projects.
The “real” SourceCred experience for communities that want to leverage it, will be asked a lot more to set things up according to their needs. Kind of like shipping Docker clients. At the heart of it is a protocol, you also get a lot of useful tools from us, but really it’s kinda pointless without some containers to run.
The setup would involve plugins and weights for sure, but it will involve some work to go through the politics of figuring out what values your community has, mapping a bunch of supernodes retroactively, figuring out if-when-and-how to put real money into the system, and so on.
At the end of that (first iteration) you should have your own SourceCred instance
I do like the idea of a core SourceCred product that just work “out of the box”. That’s really powerful. Also, if we’re looking at this from a product angle, to make this financially sustainable we do need “product-market fit”. The lean startup methodology here is proven, and I think makes sense for us. That means putting things out there and seeing what gets actually used, and ultimately what people are willing to pay for. Iterating quickly and not letting scope creep (e.g. building out a whole suite of features and adjacent products that may not gain use) is paramount. This is what a16z (a possible investor) just stressed in a paper they put out a couple days ago, which is a fascinating read generally, and touches on decentralized governance as well.
That said, I do think we’re not a typical startup in a lot of ways (and I’m glad we’re not). It’s good we’re dogfooding the messy bits too (politics, values, etc.).
This makes sense to me. And also touches on another possible product direction. Namely, SourceCred as an analysis tool. This could be incredibly valuable, for instance, for recruiters, business intelligence (BI), etc. Something that just works to gain insights quickly I think has a good chance at success. It’s also not the most interesting direction to me personally, as it’s just an input into the traditional “firm”. There’s a bigger upside in the green field of new governance and coordination systems.
SourceCred is also just fun to run on other projects. If I had more time (and the deyployment was easier), would be doing it more–I attempted to do Monero recently but stalled because I hit GitHub’s 100MB memory limit for files…
I think it makes sense to think of SourceCred as a protocol, and learn from OSS business models pioneered by projects like Docker. I think we can also learn from crypto projects building protocols; though there the valuation models aren’t quite proven yet, and much of those high valuations still rest more on speculation than utility at scale. There’s also the tokenomics of Grain, which could generate a ton of value if projects adopt it.
If the goal is to create a distributed protocol that allows anyone anywhere to run pagerank on their things to recognize and reward contributors, then you’d want the protocol to be run on some sort of distributed network and then have open source clients be able to connect to integrate however they want - an ecosystem of modular building blocks that people can assemble around the core SourceCred protocol that computes Cred scores based on data inputs. The core protocol would have a standard UX/UI around a use case (code contributions, forum conversations, etc…). Each of those use cases would have it’s own set of best practices and UI/UX flow. That way it would “just work” for that use case.
Does that kind of answer your question? I think what I’m trying to get to is that the UI/UX should match the use case. The back-end protocol should “just work” across domains, but the way it’s used and how users interact with it needs to be tailored to the audience. The flagship product that works out of the box should be optimized for the highest leverage target audience that SourceCred can provide value to.
These are the same product architecture principles being explored in the commons stack: this project is framing a Minimum Viable Commons which is essentially the out of the box (and credibly neutral) configuration, but with the idea that this is not a one size-fits-all design but rather a starting point to lower adoption friction.
The concept of credibly neutral is incomplete for good governance, because it implies that something credibly neutral is sufficiently fair in some static sense. I would argue that claiming/achieving credible neutrality serves as a means of abdicating responsibility for steering by community leaders. Certainly, their power should be checked, but in practice, leaders will not cease to be disproportionately influential; they are natural to social systems ~ mechanism design can only reshape their effects AND if the mechanisms attempt to constrain the natural process to much, new influence flows will emerge outside the control of the mechanisms in question. With this in mind, governance must be considered as more than just mechanism design. Governance is inherently dynamic (and adaptive) in that the rules of the game are always changing (both explicitly and implicitly), the capacity of the governed to change the system to meet its context is critical. I do agree that rate limiting change is important feature for good governance.
SourceCred itself, in its current state is a perfect example of a community not ready to be in a state of credible neutrality. Aspiring to meet the credible neutrality requirements is good, through I would strongly recommend expanding the paradigm through which we view governance. @jeffemmett expended a great deal of effort to distill Ostrom’s 8 principles for consideration by the dGov/DAO design communities:
On the point of front-ends. I think its probably worth looking at what DAOstack is doing with Alchemy:
Although at this stage it’s not visible, their roadmap is primarily focused on abstracting away the blockchain/web3 frictions to provide applications that look and feel the same as web 2 applications. Of course this opens up questions about what kind of services and applications need to be built to safely handle the abstraction without creating points of power that can be leveraged.
Ultimately, I believe the product strategy of SourceCred and any project aiming to facilitate self-actualizing inclusive communities must be to provide
a framework that balances constraints (to limit complexity and avoid obvious degeneracies) with features to provide a large class of viable automated micro-instition infrastructure.
a concrete and easily deployed vanilla instance of that framework which minimizes the friction of launching a fork which works out of the box.
well fleshed out guidelines for the stewards of the newly minted micro-institution to engage with their communities around customizations with transparency about the implications of those choices.
low friction user experience, which includes front-end development. while there will be learning curves in every community, UI/UX work for the vanilla instance will help ensure that the product itself doesn’t facilitate the use of friction to exclude people.
Probably the most exciting thing is that so many people in the web3 space are pursuing grassroots approaches to public goods problems. It sits in stark contrast to the systematic degradation of systems historically provisioning public goods top-down. (I read this piece this morning: The Twin Insurgency - The American Interest after it was tweeted by @vgr)
