SourceCred

Thought Experiment: "SourceCred Treasury"

Thought experiment:

Set up a sourcecred “treasury” for a handful of pilot projects (let’s say 10). Put a smallish amount in each treasury (say a hundred dollars). Each month, the SourceCred algorithm calculates cred for each individual project, then distributes $100 (in that project’s cryptocurrency) in proportion to each contributor’s cred score – preferably time-weighted to reward newer contributions, but also recognizing long-time contributors that have put in years.

A message is automatically sent to each contributor (perhaps via their public info on GitHub) with a link to claim their crypto, along with a short message telling them that this is a donation/tip for their compensation, as part of a new experiment in funding open source software. Perhaps the sender is anonymous (and mysterious). There’s also a link to a microsite explaining the project, and a link to a dashboard/leaderboard for their project (one could even run the prototype as is), where they can explore the UI and see how their cred was calculated. They are told that if they do not retrieve the funds after some time (e.g. one month), the funds will be automatically put back into a pool for redistribution to contributors that do claim their payment (similar to what Brave/BAT does with publishers). Contributors can “unsubscribe” to the messages at any time, but funds will continue going to their address in the system, should they change their minds. At any time they can check their balance on the dashboard and see the payments accumulating.

Anyone can send funds to each project’s treasury’s address (i.e. give the workers a raise). The system is permissionless. Perhaps some project leaders will see it as a welcome experiment and add some funds from their treasuries, or sympathetic whales of a project will donate – most will likely allow it to at least continue and be discussed on their social channel. Perhaps grants can be used to put a few thousand into a project treasury and measures the results. But only cred determines outflows. This could be done via trusted smart contract eventually, but done manually for an MVP. Contributors are also informed that they can earn crypto for working on other “partner” projects included in the pilot. Though their contributions there will obviously earn less, as they don’t have previous cred. Some project leaders may hate the idea. Scream that “these PRs are worth way more than X! You’re taking away our/my sovereignty!”. They will be politely reminded that thier network is permissionless, like they often tout on Twitter, and that they are welcome to help customize the algorithm so that it better fits their project. Project leaders reactions will be telling, and publicly viewable to all contributors (paid and not paid), along with the wider crypto community. If a community genuinely rejects the scoring and payments (via formal on-chain governance mechamism or informal, off-chain goverance (i.e. consensus is clear on social channels where decisions are made)), their cred site is shut down, and the funds distributed equally to all remaining participating projects, thus increasing the amount of cred distributed to participating projects, and making the participating projects more enticing to the free labor of non-participating projects (who don’t have the power to speak vocally against their leaders, but can move with their feet). At the early stages, because most contributors have not signed up, a decent chunk of crypto starts flowing to early adopters that claim their cred/rewards.

Accurate (enough) price discovery of labor gives contributors a tool to leverage in negotiations over pay. Because the system is permissionless, they can always “walk” by simply starting to contribute to a project that does pay via cred. No job applications necessary. 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)).

By this point, the project has created multiple epic drama storms on social media, stoking the flames of an already hot-button issue. It highlights the fact that even highly skilled devs holding up billion dollar valuations are begging for rent money on Twitter/patreon, as rich investors make millions. CoinDesk writes an article. Increased attention draws more criticism, but also interest. Perhaps the creator of said project/shitstorm is still anonymous, adding to the intrigue (and free press). Who is this mystery whale? What is their game? People start gaming the system, of course. But this only adds more valuable data to the sourcecred team. Who now have sources of data with which to evolve their models: github activity in participating repos, which contributors have claimed their cred, social media data, etc… It can analyze the interaction between cred and the ranking algorithms, optimizing meaningful metrics (or discovering said metrics in the first place). Sourcecred can build plugins that its “customers” ask for, not just guess, lean startup style. Sourcecred begins to function almost as a, currency….

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. 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. Projects are free to host their own dashboard, and all code is open source, but many will not want to (or have the resources to) do this on their own. Numerous partnership opportunities also exist. 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.

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. E.g. a forked repo is used in another project, causing additions to the forked repo to send cred back to the original repo, etc. A researcher’s idea is used in several projects. Non-code contributions become integrated, allowing for conversations on comms channels to create connections between projects, etc. Eventually, when “global” scores become meaningful, more business opportunities emerge.

Blue sky:

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”. Members could use these scores to negotiate pay (inside projects and with companies in general). They could also demand to be paid only in WorkCoin, creating a utility coin spot market that dynamically prices worker’s future earnings. To pay workers, they would have to purchase them on the open market, driving up the price. Workers could “sell out” their sweat equity if they wanted (or needed) to. Similar to taxi medallions. To keep the system “honest”, and not be co-opted or made inefficient (like taxi medallions), there is no hard cap, and in the WorkCoin blockchain (there’s of course a blockchain, though it doesn’t have to be fancy) there is a reasonable interest rate. Every 10 minutes, the block reward (new WorkCoin) is created and distributed according to the global cred score (work across all participating open-source projects). Coins that are not redeemed/moved within a time period (e.g. a month) are burned or transferred in the next block reward to people that are “cashing their paychecks”, keeping engagement active and giving active participants more money for participating. This new consensus algorithm is called Proof-of-Labor (POL). Miners are doing actual work. And all work is rewarded, down to the fixed typo or moderated comment, not just according to a lottery. As its price rises, early open source contributors are finally given a long overdue royalty check. 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:)

1 Like

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 :slightly_smiling_face: . 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.

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.

The plot thickens:) Grain seems like a smart distribution system once Source Cred is good enough (I would argue it’s already good enough to experiment). I really do think you could start with small amounts. Perhaps I’m overly optimistic about micropayments. But money is a content type (CRED to Andreas Antonopolis). One that could be a powerful signaling/communication mechanism. Money signals get people’s attention, starts a conversation. And that system can be scaled instantly.

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.

Brilliant. If you did this manually at first even (perhaps with a little scripting to help you along), you could probably toss up an MVP in a few days.

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.

That’s one way to do it. Another would be to automatically set up a wallet for each contributor. Then just somehow send them the private keys. Perhaps use multi-sig transactions.

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.

I don’t know if any of these systems remove trust entirely. If we just created wallets for each contributor, and send them the private keys when they contact us, then they don’t have to trust us. They can move those funds to a wallet only they control at any time. They just have to periodically “cash their paycheck” by moving funds. I like the idea of a time-locked, multi-sig transaction (which you could do with BTC, and other coins). Where if contributors don’t claim their funds in a certain amount of time, it gets redistributed to other contributors. This way the initially small amounts of funds get funneled to the early adopters, bootstrapping the project by making the sums more meaningful for those that participate.

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.

Shower thought (literally): Source Cred already has temporal information. Maybe this is kinda hacky, but you could just run the ranking algorithm up till different points in time. For instance, you could run the Source Cred repo to up a month ago, get a snapshot of cred. Then “fast forward” it a month to today, recalculate. You’d then have a delta between now (t) and last month (t-1). That delta reflects all new cred created in the last month. One could imagine a formula like this:

Ct = Cred at present

C(t-1) = Cred last month

W = new contributor weight

CRED = Ct + W(Ct – C(t-1))

If W = 1.5, for instance, then we’d be amplifying the cred of new contributions by 50% (made up number).

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.

I think as long as the code is open source, and the costs for spinning up a new instance are low, centralization could be curbed. After all, if you’re a contributor, and someone comes along with a new instance, which isn’t as fancy, and the algorithms aren’t as slick, but they’re offering you a better deal (by cutting out a rent-seeking monopoly), you’d be inventivized to fork and take that deal.

Similar to OpenCollective’s pricing

Another great project I’m just becoming aware of. I do think that peer-to-peer funding has proven itself (Patreon, etc.), which gives me hope for humanity. Ongoing monthly contributions/subscriptions would presumably be feasible. The business model is proven and off-the-shelf tech exists.

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.

A key feature of most currencies is fungibility. But what if, as we reinvent money, non-fungability becomes a desirable trait for some use cases? I see increasing suffering due to lack of social connection, alienation, and paradox of choice (who can choose?). What if a currency paid well but forced you to invest in a project or contributors in a way that was non-transferrable, similar to the way you invest in a friendship or romantic partner. Perhaps, ironically, by making switching costs higher, people are forced to stick it out (like we did the first 200,000 years) and they will create more meaning, community and value. The currency I work for is big on “skin in the game”. It’s hard to get in. Hard to get out. There’s something very smart there. There’s also no reason in theory cred couldn’t be fungible and exchangeable. If it’s an ERC20 token, and there’s a market, contributors can (and will) trade it. Skin-in-the-game here could come more from the illiquid nature of very specialized (down to the project (or even individual) level tokens. You’ll have to be invested so you can “pump your bags”.

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.

When Mozilla funneled hundreds of millions of dollars into open source software projects by switching Firefox’s default search to Yahoo for a few years, was that corrupt? If there are strings attached, it is corrupted. If there aren’t strings attached, it may appear corrupted, but I would argue that actually, would you rather have the revolution funded by TRON, no strings attached, or have no revolution? I think that it’s a slippery, gross slope. And you’d have to be careful who you partnered with. But that if a project puts value into open source, they deserve some cred for that.

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.

I think even managing grain and a Source Cred instance within a project, you’d run into governance issues. I think this is why governance tokens are so hot right now. The project I contract for is focused on this. I think (open source, forkable) governance solutions are being figured out as we speak. I think MakerDAO has proved a system that is limited to voting on a small number of key parameters (via active voting). One could imagine limiting the voting to what weights to give the ranking algorithm, for instance. If the weights were gamed, since money is invoved, contributors would be incentivized to quickly come vote out the scammers.

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.

You mean like creating a token that trades on Binance? :slight_smile:

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.

Of course someone has had this idea. OSCoin looks very interesting. I’m not sure distributing cred at the project level is the right level. You then have people at the top of hierarchies distributing money. Basically recreating the same problems you’re trying to solve, just with maybe smaller pyramids (and some of these projects have quite large pyramids already). Also, it’s not clear to me how a PoW consensus algorithm works in this context.

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.

Cred (which could exist permissionlessly outside of IP laws), would essentially assign a micro patent on every contribution, which distributed royalties in perpetuity to the contributor (or whoever owns rights to that cred). It would be like the American patent an invention dream, but for real, not just a system major corporations use to consolidate power.

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.

One must always be consensual. We are talking about permissionless systems here though. Did Bitcoin ask the banking system for permission? Most of the interesting (IMO) crypto projects have a core value of permissionlessness. I do think the best strategy would be to find projects that are welcoming to the idea, and work with them. Source Cred is an obvious candidate. Presumably, like Bitcoin, the idea is to simply create an alternative system, which will attract people and projects, or not. But, if there’s a centralized power structure in a cryptocurrency, where those at the top are making millions from the work of mostly unpaid contributors, and leaders of that project object to some contributors setting up a Source Cred instance so they could create and exchange value for their (unpaid) work, well, I’m not asking permission.

What if you built a product in an OS repo, charged customers to use the product, and distributed the proceeds to your contributors based on SC?

That is totally viable. The OS project would need some sort of OS business model (e.g. a closed-source premium version, support, etc.), but those business models have been validated. This could also be bolted onto an existing OS project that is looking for a way to recruit contributors.

Grain seems like a smart distribution system once Source Cred is good enough (I would argue it’s already good enough to experiment). I really do think you could start with small amounts.

There’s a higher activation energy for creating Grain, since I also want the smart contract to have some particular properties:

  1. It’s possible to send a dividend to grainholders with O(1) cost (i.e. it doesn’t matter how many accounts hold that grain)
  2. The dividends accumulate recursively, i.e.:
    • at t0, a dividend of Bar was sent to the holders of Foo
    • at t1, a dividend of Zod is sent to the holders of Bar
    • at t2, a holder of Foo should be able to retrieve a dividend of Bar, and a divided of Zod (which they transitively own because of the Bar that was owned by them at t0)

I spent some time thinking about this back when starting up SourceCred, and I’m pretty sure I’ve worked out a construction with good properties, where basically when a token produces periodic “dividend claim checks” tokens which accumulate the right to withdraw dividends from the pool. Then there can be liquid markets in the “claim checks” so that your average contributor doesn’t need to do the mechanics (and pay gas costs) for receiving all the small transitive dividends they’ve earned, they can sell the claims checks and market makers can do it efficiently at scale. Implementing it and testing it will take a while, though.

If we wanted to demo grain, we could just make an ERC20 token that is a placeholder, and then fork/migrate to a new contract when we’re ready for it. I like the idea of just paying out ETH to start though, it’s simpler.

That’s one way to do it. Another would be to automatically set up a wallet for each contributor. Then just somehow send them the private keys. Perhaps use multi-sig transactions.

Seems safer to never be sending the private keys over the internet. Also for some users this might be their first ETH address, and they might then do the very bad thing of using a wallet whose keys they got from someone else as their de facto main wallet. Better to not encourage bad habits, and instead have them generate the wallet and then we can send to it.

I don’t know if any of these systems remove trust entirely. If we just created wallets for each contributor, and send them the private keys when they contact us, then they don’t have to trust us. They can move those funds to a wallet only they control at any time.

Let’s suppose evil me sets up a cred donation instance for ETH developers. I do a good job building community and being really responsive to making the parameters work well, and so people start routing more and more funding through my portal. I get to the point where I have say, $100k/month in donations. Then one month I take all of the money and run, rather than sending it to real developers like I did all the previous months.

Shower thought (literally): Source Cred already has temporal information. Maybe this is kinda hacky, but you could just run the ranking algorithm up till different points in time

Yep, I describe a similar proposal in the other thread.

But what if, as we reinvent money, non-fungability becomes a desirable trait for some use cases?

This is an interesting idea, and also one I’ve been riffing on in my head. Fungibility can be a big problem, e.g. if I donate $1000 dollars to you with the goal of saving pandas, nothing stops you from spending it on a jet ticket to the Bahamas, due to the fungibility of money. What if we could make non-fungible money which tied it to a particular purpose? So every transaction of “save-pandas money” would need to include a compelling proof of why using the money in this way helps save pandas. Maybe once it’s produced a certain number of hops in save-pandaness it starts to regain fungibility, so that people who don’t have saving pandas as a terminal goal are still inclined to accept it in exchange for goods and services.

There’s also no reason in theory cred couldn’t be fungible and exchangeable. I don’t think so. Consider the cred I earn for writing this particular post. It’s not fungible with the cred that I get for fixing a bug today in SC, because they will vary independently. Maybe this post winds up being important to our future plans and so the cred for writing this post keeps on getting more and more valuable, vs maybe it turns out that my bugfix was poorly written and actually introduced more bugs, and so the cred for that PR later gets devalued to 0. Non-fungibility.

I think even managing grain and a Source Cred instance within a project, you’d run into governance issues.

Yes, totally! But if every project has its own governance problem, the system can robustly adapt as individual projects find good approaches to them and others can then adopt those practices. If we create a single unified instance, then it’s much more likely to get stuck in a terminal bad state and not be able to adapt. The robustness of decentralization.

I think MakerDAO has proved a system that is limited to voting on a small number of key parameters (via active voting).

This is another side discussion, but I don’t like MakerDAO’s governance model, for the same reason: it centralizes too many decisions with the same group of voters. I think that once MakerDAO needs to set parameters for N different currencies, the groups skin-in-the-game towards any individual paramter choice will not be very high, which will create an opening for lobbyist type people with an interest in moving particular parameters to exploit the system. I think MakerDAO would be more robust if every currency that gets added had its own “MKR” token equivalent (MKR_ETH, MKR_BTC, …) and then the holders of any individual token only vote on the risk parameterization for that particular collateral.

One could imagine limiting the voting to what weights to give the ranking algorithm, for instance.

I imagine that running a high-quality distribution will involve a lot of manual configuration of the graph, e.g. creating nodes that represent project level priorities and core infrastructure, and then connecting those nodes to individual pull requests, commits, parts of the codebase. It will be a lot more than voting on a few individual parameters. Take a look at the Odyssey hack design doc for an idea of what we’re thinking about.

If the weights were gamed, since money is invoved, contributors would be incentivized to quickly come vote out the scammers.

Kind of like how voters in real democracy are incentivized to quickly vote out corrupt politicians? :slight_smile:

OSCoin looks very interesting. I’m not sure distributing cred at the project level is the right level.

Yeah, I agree. I talked to the founders about this a little while ago; they made the case that maintainer-ship is the bottleneck for OS projects, so only paying maintainers is fine. I disagreed, because even if this is approximately true right now, it creates really weird power dynamics and social dynamics and will be hard to fix down the line. Having read about your experience with the stickiness of power dynamics in a ‘guild’ I’m further convinced that doing distributions just on the project-level is a mistake.

Cred (which could exist permissionlessly outside of IP laws), would essentially assign a micro patent on every contribution, which distributed royalties in perpetuity to the contributor (or whoever owns rights to that cred).

Yes, with the caveat that unlike the American patent system, you cannot use your holding IP to restrict others from using it, ever. You can just request (or assert?) a right to the share of the value created. If I have cred in something, it should be impossible for me to use that to prevent you form releasing open software or IP on top of it. (Open == freely usable and accessible.)

I imagine a future open-source license which says, essentially:

  • If you are an open-source project not using Grain (or other mechanisms for flowing economic value to people involved in the project), then you can use this software freely

  • If you are an open-source project using Grain (et al), then you can use this software, but you are required to flow some of your Grain back to the holders of grain in this project. (Maybe: 20% of grain must go to dependencies, exact distribution determined in accordance with standards…)

  • If you are a closed-source project making any revenues, then you can use this software, but are required to flow 0.0x% of your revenues back to this project’s grainholders (or maybe: 20% of revenues across all the OS you depend on, split between them according to commonly accepted practices, with arbitration by X neutral group)

I spent some time thinking about this back when starting up SourceCred, and I’m pretty sure I’ve worked out a construction with good properties, wh…

Out of my depth here, but appears like solid theory.

If we wanted to demo grain, we could just make an ERC20 token that is a placeholder, and then fork/migrate to a new contract when we’re ready for it. I like the idea of just paying out ETH to start though, it’s simpler.

That is the way…ERC20 infrastructure is such now that anyone can permissionlessly integrate with e.g. a DEX and have a market immediately. NC (NomanCoin)/ETH now trading.

Seems safer to never be sending the private keys over the internet. Also for some users this might be their first ETH address, and they might then do the very bad thing of using a wallet whose keys they got from someone else as their de facto main wallet. Better to not encourage bad habits, and instead have them generate the wallet and then we can send to it.

Starting out, it’s better to learn losing small amounts (opinion of some smart security people I follow). Also, the friction of having people create wallets could slow them down. The DAI burner wallet is a great example of super easy onboarding. Though if you’re talking about a crypto project, presumably everyone has a wallet already and this isn’t a problem.

Let’s suppose evil me sets up a cred donation instance for ETH developers. I do a good job building community and being really responsive to making the parameters work well, and so people start routing more and more funding through my portal. I get to the point where I have say, $100k/month in donations. Then one month I take all of the money and run, rather than sending it to real developers like I did all the previous months.

Exit scams will be a thing. But neither of us would have a job if 99% of people didn’t trust centralized crypto exchanges in the last couple years, many of whom have gotten hacked or exit scammed. Not trusting imposes a heavy tax. Also, if someone like yourself or another SC member did this, the reputational risk would be enormous. A human run operation in the early stages seems fine, and the quickest way to get started. Super secure smart contracts can be developed for millions of dollars once there’s millions of dollars in funding.

Yep, I describe a similar proposal in the other thread 2.

I totally accidentally stole your idea! Sorry about that. Good thing the internet captured it and cred shall flow to you for that one:)

Maybe once it’s produced a certain number of hops in save-pandaness it starts to regain fungibility, so that people who don’t have saving pandas as a terminal goal are still inclined to accept it in exchange for goods and services.

Reminds me of this guy, whose work I just found. Some deep thoughts on non-fungible tokens,

Take a look at the Odyssey hack design doc for an idea of what we’re thinking about.

This looks great. Another key piece of the puzzle. This is where non-code contributions can come in as well. So far the team seems to have answered all the big questions with actions.

Kind of like how voters in real democracy are incentivized to quickly vote ut corrupt politicians?

I would not propose traditional representative democracy (and don’t think that will work well in blockchains that are trying it). If you scrapped Maker DAO’s governance and just used the active voting smart contract, I think it works well. Unless a majority gain hold and tryany of the majority begins (in which case the community forks), any corruption/hack could be quickly voted out, and the consequences are time-bound. E.g. cred only flowed to the wrong people for a few days before people noticed. And I think people would be more responsive to money flowing out of their bank accounts than voting every two years for politicians that don’t meaningfully affect their reality.

Another approach is to just limit groups to small numbers of humans. The coordination is more limited on a global scale (although not if connected in a smart mesh somehow…), but you won’t need formal governance at all (or very light). Maker for instance made all of its decisions for the first couple years just informally. Rule was, if a proposed idea was not opposed, that was the community giving consent. This is largely how it operates informally in my project when it comes to tasks individuals want to do (and possibly get paid for).

Yeah, I agree. I talked to the founders about this a little while ago; they made the case that maintainer-ship is the bottleneck for OS projects, so only paying maintainers is fine. I disagreed, because even if this is approximately true right now, it creates really weird power dynamics and social dynamics and will be hard to fix down the line.

Initial conditions I are very important. Especially power dynamics. Once people have power and a mechanism to keep that power, they will try to keep it, regardless.

Sounds like you think we should start by making our own ERC20? I think paying out ETH has a real elegance. We already know exactly what $100 worth of ETH means, so we can be sure about the meaning and the effect it will have (“I can buy a coffee! cool.”). Whereas if we send 100 “SourceCred grain”, today it is meaningless, and tomorrow it might mean too much.

For an MVP, I would definitely go with a known crypto. Though…

We already know exactly what $100 worth of ETH means, so we can be sure about the meaning and the effect it will have (“I can buy a coffee! cool.”)

ETH is still very volatile. “I can buy coffee!”, could turn into “hey, I need another dollar for coffee, got a buck?”. I’m mainly joking, and for MVP ETH could be a smart choice. But having been paid in a volative crypto for the last few months, living paycheck to paycheck, I can tell you it’s not ideal long-term if people are making a living with this. What about DAI? Same tx fees as ETH (just gas), which is $0.003/tx (slow). Fiat trading pair on Coinbase now. Motivation to use ETH would be if that was more accessible or (more importantly) meaningful to the project getting payments. I can say safely that BTC contributors would not appreciate being paid in ETH :slight_smile: