This is a really interesting thought experiment!
I’ve spent a lot of time thinking about how to do token distributions based on cred. The systems I’ve had in mind have involved creating new project-specific cryptoassets called Grain and doing distributions at the project level, with large rewards, large upfront commitments, and requiring solid buy in from the project maintainers. One thing I really like about your approach is it’s something we could launch soon (e.g. this year), with very small $ amounts initially, which lets it be a bit more of a low-cost prototype that also raises awareness. The idea that we could seed it with, e.g. $100 per project and then let whales/contributors donate more into the pot is really interesting, and as you noted it really leverages the permissionless nature of crypto projects.
Some implementation thoughts:
A simple way to do this could be to make a GitHub repo for each treasury, and post e.g. a GitHub issue each week with the current dashboard state, including how much funds are attributed to each GH username. If the issue @-s people, they’ll see the notification (by default you see mentions even in repos that you aren’t watching). There can be another thread where users post a standard message like “I request my funds to be sent to ETH address 0xabcdef…” which authenticates them so they can receive the funds.
Start earning crypto immediately. Transition slowly, and without having to reveal your identity. I.e. you can “fork” the “workforce”. Projects are also free to create their own sourcecred instance on top of the existing one to “woo” workers. For instance paying new contributors more (i.e. headhunt) if they have a lot of cred accumulated in a related project (or higher “global cred” score (more on this later)).
The idea of creating dueling SC instances for a given project is interesting. I’ve always been thinking of projects having single, canonical cred scores (which matches having a canonical grain distribution, see link above). These would be forkable, but the costs of forking are pretty high.
On the other hand, if people are spinning up these smart contracts that are funded by donations, then anyone could spin up a new one with its own parameters in the algorithm. So as a funder of the project, I could choose to put my donation towards the cred attribution I see as fair, without anyone needing to fork the project.
However, since there’s no way to run SourceCred on a blockchain (and this isn’t likely to be possible any time soon) you would need to trust the administrators of each instance not to run away with the money, or otherwise disburse it unfairly. We might be able to think of clever mechanisms to mitigate the risks here, but without a way to produce verifiable cred attributions, I don’t know how we can take trust out entirely.
Sourcecred can build plugins that its “customers” ask for, not just guess, lean startup style.
I think we’re already doing so, in a sense. I’m prioritized time-scoped cred because it’s the most consistent thing people ask for when they’re engaging with the prototype. I also hope that communities will build their own plugins to serve their own needs, rather than depending on us to build them all.
A couple business ideas off the top of my head: Sourcecred the company could offer CASS (cred as a service). I.e. provide hosting and support for cred dashboards and other services (payment services?), as well as consultants that work with a project to customize cred algorithms to suit their needs. All customized work is open source and available for all other projects to use if they find them useful.
There is no “SourceCred, the company” at the moment (it’s just an OS project). I agree that once this catches on there’s going to be a lot of demand for managed hosting and creating a company might be the best way to fill that niche. I’m a little reluctant to do so, though, because I’d rather not create a monopolistic centralized actor at the heart of this space. But this could be de-risked if the company pre-commits to open-sourcing everything, and making it possible to fork it and create a competing SourceCred hosting service, much like Discourse and OpenCollective have done.
Another possible revenue stream would be a “dev tax” of sorts, where, say, %5 of crypto sent to a “cred treasury” managed by sourcecred will be sent to a fund for development of core sourcecred technology. Everything is visible on-chain and auditable.
If we did make “SourceCred, the company” (‘CredHub?’), this would be a good way to monetize it. I was thinking about having every project distribute a fraction of its grain to SC, but if the system is directly sending money around, charging a %-age fee on the value would make sense. (Similar to OpenCollective’s pricing.)
Sourcecred begins to function almost as a, currency….
This was a bit of a leap for me. A key feature of a currency is that it’s fungible and exchangeable; cred is neither.
E.g. all cred, regardless of the project, is paid in a single “sponsored” currency. This would be attractive to certain projects as it would raise awareness and adoption and surface meaningful on-chain economic activity, which would be picked up in numerous metrics used in project valuations (and therefore investment decisions that affect the price, especially in illiquid markets). It’s a great marketing opportunity as well. A virtuous feedback loop. This also could give sourcecred a lever to negotiate with. Similar to how Mozilla funds open source software by threatening to switch Firefox’s default search to Bing. How much not to switch to BCH lol.
This strikes me as kind of gross, and an example of why we shouldn’t have SourceCred, the company 
. Every project should be paying out in whatever currency they find most appropriate. If they start getting paid in BCH because the BCH folks were able to bribe the administrators of the infrastructure to use BCH… then the system is starting to look corrupt.
At the same time people earn cred in their own projects, cred is also calculated across all projects. The connections between nodes across projects may be limited. But will grow over time. Especially as the sourcecred team adds more robust and nuanced functionality.
Yep. Just adding dependency edges (e.g. for npm) would add a lot of cross-project signal. I’m a little reluctant to make a global unified cred-coin, though, because of how hard it would be to do governance. How do we make the right parameter choices for a huge ecosystem? Who is empowered to make those choices? I’d rather that every project has its own coin (see grain, above) and each project has individual agency on how to set monetary policy, which dependent projects to distribute it to, etc. This is a lot more decentralized and therefore, imo, robust. People could then build various indexes on top of those individual grain offerings (e.g. via a token curated registry), maybe with some sort of exchangeability mechanism, and contributors who want to derisk their exposure to some particular project they work on can swap that grain for the indexed grain.
Once the project has reached a critical mass, a new coin could be premined and airdropped to all participants in the system, in proportion to their “global” cred score, effectively creating a “meta guild” of contributors across the ecosystem. Let’s call this “WorkCoin”.
You could also call it OSCoin, since this is basically what OSCoin is working on. Again, I think having a single currency creates too much centralization. It creates economic centralization (a single asset, with the inability for price signals to guide development onto individual projects) and centralization of power (in whatever committee parameterizes the WorkCoin). I think the system will be far healthier if every project has its own grain. Then “the spot market that dynamically prices workers future earnings” can do so on a per-project basis, which makes a clean mechanism for investing in early stage open source projects, etc.
The pay from open source finally passes a threshold where new talent leaves corporate America in droves, further driving up the price, and we enter a glorious golden utopia where nothing could ever go wrong:)
Yep, and more. I’d like to see other IP-dominant domains in our economy convert to open-source. E.g.: how great would it be if drug discovery moved to an open-source model? Right now its hard to imagine that working economically, because we don’t have economic infrastructure that rewards open-source creators.
Overall: I think this thought experiment is a really interesting way to kick the wheels on SC, and also generate some attention, interest, and practical experience. I think the big diff I have in mind is that we should probably do it only with projects that have consented in advance to us turning it on and running the experiment. Like you said, it has the potential to start up epic fights and drama bombs and stuff. I’m worried it would be unethical to drop those drama bombs in other projects’ laps without getting some buy-in first. This is why I’d also like SourceCred to be the first project in line for such experiments.