Product Strategy: Flagship + Plugins

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?

1 Like

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

1 Like

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.

1 Like

@burrrata where do you see front ends playing in this product strategy? I like the framing around this.

Do you think what I’ve briefly outlined here might be useful in helping have Commonwealth help iterate around the flagship experience?

Just want to highlight that I strongly support everything said here. Also, thank you so much for sharing that article. I love it :slight_smile:

Good point. I mean this really circles back to lots of the questions about who/what is SourceCred for.

  • If the target is just creating a tool to measure, manage, and reward open source contributions to git based code bases then just use GitHub and have SourceCred be a backend tool.
  • 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.

1 Like