SourceCred Protocol


Cred represents contributions to a project. Projects are constantly evolving, and as they do so does Cred.

  • Source: the source code (data) of a project that is represented as a graph.
  • Cred: scores that nodes on the graph receive based on contributions and engagement.

SourceCred creates a graph over every project with nodes represent actors and items. SourceCred then gives those nodes scores according to a PageRank style algorithm. As people contribute to a project the graph will change and Cred scores will be updated accordingly. Cred is a living representation of contributions to a project.

We want open-source contributors to earn a living, and a share in the value created on top of their contributions. Tracking contributions in a living graph that is updated over time allows people to be rewarded for the value their work provides, today and into the future.

We’re designing the SourceCred protocol around the following principles:


  • It should be easy to see why cred is attributed as it is, and link a person’s cred directly to contributions they’ve made.


  • SourceCred is designed around a plugin architecture, so you can add support for new data sources, new algorithms, or even entirely new kinds of work.


  • Each community has the final say on that community’s cred. When the algorithm and the community disagree, the community wins. Projects own their own data, and control their own cred. The SourceCred project provides tools, but has no control.


So many… I’m honestly not even sure where to start. Would the entire SourceCred repo qualify here? Or is that a dependency?

The SourceCred prototype allows you to check your Cred scores.


I feel like almost everything related to SourceCred and the CredSperiment could be in this section lol

SourceCred contributor payouts are calculated via Cred scores.

To Do

Figure out what qualifies as a reference and what actually contributed to the design and development of “Cred.”

Update the description.

Create a Cred overview post.

Thinking about this more, and “Cred” is really hard to separate from “SourceCred.” This is because Cred is a force of the system, so really it’s a part of the system. Cred can’t exist on it’s own without the SourceCred protocol, and the SourceCred protocol couldn’t exist if it didn’t measure contributions via Cred.

I would say in my mind the current distinction is that “Cred” is really a shorthand for the “SourceCred protocol,” whereas “SourceCred” refers to the entire SourceCred project?

Threads that somewhat answer the question: “What is Cred?”

I agree, I think that “Cred” is a somewhat awkward artifact because it’s so integrally a part of SourceCred.

Maybe a clearer artifact would be something like “Cred algorithm” or “SourceCred system design”. (Or maybe “cred algorithm” is a sub-artifact within “SourceCred system design”.) Then it would be a bit clearer that we’d be pointing to dependencies like the PageRank paper, the initiative for prototyping credv1, the initiative for adding timeline cred, and so forth.

What if we thought of the “SourceCred protocol” as the graph and the way to attribute Cred scores to nodes on that graph?

Then everything else that’s a derivative off of that graph and it’s scores (like Grain) could be part of the “SourceCred game” (or “system” if the word “game” is unpopular lol).

This would allow the system to change as we design new features and plugins, but the heart of SourceCred would always be the core protocol that creates a graph and assigns Cred scores based on nodes on that graph.

Related tread that explains more how Cred will flow through the SourceCred protocol