I had a chat with @dfield today and he made a number of interesting suggestions:
Thanks, decentralion!
Another thing we talked about was making sure cred was monotone increasing. This would be combined with the first suggestion you mentioned; on some interval (weekly?) you could get more cred according to your contributions to the project, but this would be on top of the cred you already have. I think it would be tough to make cred valuable if we removed user’s cred.
One thought I had after Friday: it would be a worthy goal to figure out how to make one SourceCred currency that exists across projects. I’m not sure how this could work, but it’s worth trying to solve for.
So, I need to write a little essay explaining this, but that’s the function grain will serve in SourceCred. Basically, cred represents reputation, and is perpetually fluctuating based on how the project values your contributions, what contributions others have made, etc. Cerd is not monotone increasing, is not fungible, and is not transferable. Think of it as an analogue to your real world reputation: there’s some sense in which it doesn’t accumulate, but rather perpetually fluctuates. If you make a really great contribution, you earn a lot of reputation; if it turns out to be non-reproducible or flawed, your reputation decays; if you disappear from the scene, your reputation decays, etc.
Grain is the quantity that you accumulate by virtue of contributing to a project. I expect cred will be something like the derivative of grain, so that e.g. every week the project mints 1000 grain and issues it based on who has cred. We might use the time-decay idea you mentioned so that you earn more grain for recent contributions. Also, some grain can be stored for other incentives (e.g. every week 50 grain goes into a fund that is split across users who make their first commit, 50 grain goes to people that wrote the best documentation, etc). Also, some grain will be held aside to give to a project’s dependencies.
Grain will be transferable, and acts a lot more like a currency. Grain is just as important a concept as cred in the long term, I kind of regret that the name “SourceCred” implicitly focuses attention on cred rather than grain. But, I think that our choice to focus on building cred first makes sense: if we have a good system for finding cred, we can use it to allocate grain in a way that is fair and meaningful. If we built grain first, we wouldn’t have any fair system for deciding who should earn it (besides one-off heuristics like rewarding people for their first commit, or based on # of lines of code, but this would all be easily gamed).
Yep, this is a really interesting question. I think it’s worth asking: what properties should this unified currency have exactly? Supposing that SourceCred makes grain as described above, and every project has its own grain, then we can expect the various grains to be fungible and traded in a market with good liquidity, in which case dollars (or Ether or bitcoin or w/e) can be viewed as the unified currency across projects, since you can exchange IPFS grain into dollars into SourceCred grain and so forth.
Having unified Cred across projects might be more interesting. Being able to abstract over many JS projects and see that someone has a lot of “generic JavaScript cred” would be a very valuable signal that someone is a trusted and capable member of the community. For now, I’m not focused on figuring this out, because unifying cred across projects creates a lot more coordination cost, centralization, and risk of collusion. But in the longer term, it’s a very natural direction to go in. I think that if Token Curated Registries (TCRs) take off, they would be a very promising system for creating meta-creds like JavaScript-cred or MachineLearning-cred and so forth.
Once you have the meta-cred, it’s straightforward to implement meta-grain. I’m not quite sure what it would be used for, though.
@decentralion thanks for your reply, and sorry to just be seeing it now.
Is there a reason why cred and grain need to be different nouns? It might be a lot simpler to understand the model if the word “cred” or “grain” was used for both. To your point, cred might be “pending” as it fluctuates throughout a given period, but then it could be assigned at the end of the period.
Good question. Initially “cred” and “grain” were effectively the same thing, and then we split it apart b.c. we realized these are meaningfully different quantities.
Consider the following case. Vin is a developer who works on FooProject, thus earning a lot of FooProject cred. She can’t sell or be separated from that cred, because it’s directly tied to her identity and to her work. She also earns FooProject grain, which she decides to sell to Elend, who is a supporter and user of the project. So now Vin has cred, and Elend has grain.
Having cred vs grain implies different things. For example, if we are considering a major refactor to the build system, we will probably pay a lot of attention to Vin’s opinion as a creator of the project, and not very much to what Elend’s thinks. However, if we are deciding what features or use cases to prioritize, we should give Elend’s needs plenty of weight, because he has been a supporter of the project.
Does this make sense (and justify having two separate nouns)?