SourceCred is still a very young project. As we grow it, we have a choice of priorities: do we want to go “wide” (adoption by lots of projects) or “deep” (intensive usage by a few projects)?
Going “wide” is easier. SourceCred can run on any GitHub repo, so we have a path for engagement with the entire GitHub community. We could focus on getting more and more projects to try running SourceCred, and then convert them to regular usage. If we went down this route, we would focus on features that make the existing cred scores more salient and engaging— for example, making it easy to generate “weekly reports” showing the new cred being earned by contributors.
Going “deep” is more challenging. It means finding a way to make SourceCred deeply and durably valuable to individual communities—not as a passing interest, but as something that gets a lot of community engagement, and becomes a part of how that community operates and thinks about itself.
As an added bonus to going wide, progress is much easier to measure, as it’s easier to quantify the number of projects using SourceCred, but hard to quantify the amount of value that SourceCred is adding to any particular project.
Initially, my instinct was to go both wide and deep simultaneously, as is reflected in the 2019 OKRs. Given that going “wide” is both easier and provides clearer incremental feedback (via increasing adoption), this operationalizes as a bias towards going wide rather than deep. I felt this was fine, as going wide presents a larger surface area, which means more outside contributors and developers, which theoretically makes it easier to then go deep. (“Wide then deep.”)
My views changed after an in-person conversation with @anthrocypher. She made a cogent case for going deep rather than wide. Ultimately, for SourceCred to provide the lasting, meaningful value that we envision, it needs to succeed at the deep use case— of producing high quality scores and also having good patterns on how a community can consume those scores in a healthy way. Focusing on going wide allows us to punt on this hard problem, while getting positive feedback along the way (in the form of increased engagement)—but solving the underlying issues of making meaningful, high-quality cred may get harder, not easier, with scale and momentum.
@anthrocypher also pointed out that the wide-not-deep approach brings ethical quandries along with it. If we focus on getting lots of projects onboarded to SourceCred quickly, we may be ignoring consent issues around whether contributors to those communities are comfortable with having their contributions analyzed and quantified. Also, quantification could have a lot of deleterious effects to the community, and we would be pushing this onto third parties before having really deeply engaged with the consequences ourselves.
Overall, these considerations persuaded me that we should engage with the hard problem first, and prioritize going deep. This means focusing on the needs of the SourceCred community. Right now, SourceCred does a bad job of assigning cred within SourceCred itself. The prototype only picks up on GitHub activity, so it greatly over-weights the contributions of @wchargin and myself. My hope is that through the Odyssey plugin and a Discourse plugin, we’ll be able to better pick up on all the other contributions that people are making to SourceCred.
Once SourceCred is doing a great job internally, we can start giving more attention to going wide, working closely with a few other communities that are enthusiastic to try out SourceCred. By that point, the SourceCred that they are adopting will be more sophisticated and nuanced than the one-shot score generator that exists right now.
I think that if we do a good job building a “deep” SourceCred, it will go wide easily—people will want to adopt it (and tell their friends about it) if we’ve gotten to the point where it really works within our community.
So, to sum up: let’s go deep, then wide.