SourceCred

Chat with OpenCollective

@wchargin and I had a rewarding chat with @piamancini from OpenCollective today. Here are some notes, both for future reference and to appreciate Pia!

Major Takeaways

  • Pia thinks SourceCred can be really useful to open collectives. Figuring out how to fairly distribute funds from a collective is a hard + socially contentious problem
  • Open Collective has open APIs / plugin interface, so building a SourceCred integration to OpenCollective should be straightforward
  • A number of existing collectives (I think Pia mentioned Webpack and Mocha in particular) have had trouble figuring out how to fairly give funds to contributors, so they could be early adopters of a SourceCred integration.
  • Pia will intro us to Evan from Babel (@mikeal has also suggested talking to him)
  • OpenCollective and SourceCred have similar values and vision, and I’m really excited to collaborate more with OpenCollective!

On Centralization and Platform Lock-in

We also talked about platform lock-in, centralization, and control. Open Collective has open-sourced their platform, and people who want to implement their own legal/organizational backend and turn on a separate Open Collective instance are free to do so. Also, OpenCollective offers data export, so existing collectives would be able to migrate to the new one. This resonated with me as a model for SourceCred: I think full decentralization isn’t technically feasible, so keeping SourceCred open-source and easy to migrate out of will avoid having inappropriate degrees of platform lock-in.

Maintainers may not want control over the cred

Pia pointed out that control over how the money flows can be really contentious, and it may be a lot easier for maintainers if they don’t have responsibility for exactly how it happens. Specifically, having maintainers of a project choose the cred weights invites a lot of conflict around whether the choices are self-serving, etc. If SourceCred, as a neutral/disinterested party, can make impartial weight choices, that may be a lot better for the community. Mikeal has mentioned something similar in offline discussions.

We’ll still want maintainers to be able to moderate the cred, e.g. flagging low-value or spammy posts.

Business Models

OpenCollective’s business model is that they take a %-age fee from the funds that flow through their platform. I imagine that SourceCred’s long-term business model will be that it earns a fraction of the cred for the projects that use SourceCred and/or depend on us for hosting their cred. So there’s a similar perspective here, and I can easily imagine projects that use OpenCollective also giving a fraction of their cred to OpenCollective.

Also, thanks to @coderberry for intro’ing us to Pia, and to @owocki for intro’ing us to coderberry.

1 Like

This is very exciting!

1 Like

Hi there @decentralion & @wchargin

It was a great chat. I am really looking forward to seeing SourceCred grow and think about ways to connect you with the open collective community.

  • Intro to Henry and Ele was made.
  • Maybe Ele, but it looks like James Haydon from OSCoin will be at SustainOSS.

MochaJS and Babel are figuring out how to distribute funds (webpack has functioning system)

On talking with other folks about SourceCred a comment that came up is that as is at the moment, it might be compensating people who have the time / capacity to contribute to open source projects but it’s not helping grow the number of people starting to contribute. If it amplifies existing privilege instead of supporting more people getting in, it won’t make open source more sustainable.

I think there’s an interesting take there in that sustainability of open source has to do with the sustainability of its communities and incentivizing community growth instead of commit growth can be a more successful path towards sustainability.

Maybe thinking about how SourceCred can also distribute value to newcomers, firstPR, onboarding, diversity and accessibility to add this piece of the puzzle?

Food for thought!

Thanks for the intros Pia! I replied on both threads :slight_smile:

Agreed, it’s really important as we build SourceCred to think about the power/privilege dynamics that it will contain, and not to create a system that only serves the most connected/powerful participants.

Right now, you needs a fair bit of privilege to be able to regularly contribute to open source— either in the form of working for a farsighted corporation that’s willing to pay for it, or the financial privilege of being able to put a lot of effort into work that doesn’t get paid. I hope that if SourceCred can help people get paid consistently for open-source work, that will make open-source inviting to a much larger group of people.

Another way I think SourceCred can help is getting the reputational rewards distributed a lot more fairly. Right now I think if there are two people working on an open-source project, and one is charismatic and likes to give talks, go to conferences, etc, and the other is just heads-down working on the project, it’s easy for the person who asks for less attention to go unrecognized. SourceCred can recognize implementers who aren’t courting attention.

Yep! I think it’s really important that SourceCred detect e.g. emotional labor in keeping a community growing and healthy, and not just the technical labor of writing the code and fixing the build and so forth.

It’s an open question how to do this best—technical labor leaves a clearer metadata trace and so it’s just easier to track right now. Some ideas I have here include having more of a social component in cred tracking, e.g. publicly thanking someone for (technical or non-technical) work they’ve done to support the project.

In the case of SourceCred, I look forward to integrating these Discourse forums into SourceCred’s cred graph to try and recognize people like you and @nayafia who are involved in figuring out how to use SourceCred, but not in implementing it.

Totally. At its core abstraction, SourceCred is extremely flexible (it’s just a graph with nodes and edges), which means it should be really easy to develop plugins to support goals like this. For example, the “first PR” plugin could create a node that starts with a large amount of cred (configured by the community), and has an edge to every newcomer’s first PR, so that they immediately get some reward and validation for having put in the effort to create a PR. You could imagine similar approaches to build diversity, or reward people for focusing on improving the project’s accessibility, and so forth.

As SourceCred starts to get traction, I look forward to experimenting with approaches like these and see what works best for projects and their communities.

Per the concern about privilege. I work currently in a functioning cryptocurrency DAO that pays open-source contributors, for both code and non-code contributions. I found SourceCred in my search for a way to pay people that currently aren’t being paid (or are underpaid). In my project, the way it works is, to become a paid contributor, you need to contribute for free for a long period of time (typically 1-3 months), prove your worth to the community through accepted contributions, and then get voted in to the “guild” (they don’t call it that, but that’s essentially what it is). This path, of course, typically requires a lot of privilege – though the pay is low’ish and not based on geography, so it has repelled some devs working in expensive cities and attracted numerous developers from developing countries with lower cost of living (and presumably less privilege). When I proposed simply tracking contributor metrics, with the idea of paying people directly for contributions (whether they were members of the guild or not), the reaction from some influential core developers was swift and overwhelmingly negative, effectively killing the idea on the spot. These developers (which likely have the most privilege, wealth and autonomy in the community (they can work on pretty much whatever they want)) saw it as an effort to control them and take away their “sovereignty”. Apparently they’d had bad experiences with dev metrics at prior traditional jobs. I went back to the drawing board, and after some further research, realized maybe their fears had some merit. Dev metrics (and the gaming of them), have a bad reputation among the developer community for creating bad incentives and being abused by management. I’m now back to the drawing board. SourceCred looks promising, as I think it has the potential to create better, more defensible metrics. But I worry about another reactionary response. And wonder if it’s better to propose the idea early, allowing people to give feedback into customizing (and risk it being killed for good), or to work on the customization myself until I come up with something that is more fair and appealing. Also, wondering if there is any material on how to “sell” something like this to an org that may be resistant to it? Case studies?

Per the privilege question. I think that if the metrics are done right, they have the possibility to push the system in the direction of meritocracy (in practice, not just silicon valley mythmaking), lowering barriers to entry. This is particularly true if the system is permissionless and controlled by smart contracts. Existing contributors will start out with more cred. But if they want free, valuable labor they will have to send some of their cred to those new contributors, who have a path to more cred. Projects that don’t accept these free, valuable contributions (so they can hoard their cred) IMO will be at a major competitive disadvantage if DAOs gain traction (and I believe they will). Giving more cred (or better, money) to newer contributors is not only an altruistic way to level the playing field, it’s a good recruitment strategy (another competitive advantage). A larger problem, privilege-wise, is that non-code contributions (including a lot of emotional labor) are not tracked. That means that, even if we’re successful in leveling the playing field for developers, on the larger playing field, developers pull further ahead (and they’re already overcompensated as is). That SourceCred is integrating with this forum (e.g. this conversation may generate cred), is an encouraging development. I think there are many ways you could measure interaction on forums, slack channels, twitter, whatever. - Indeed tipping bots funding content are already being used to great financial success on twitter by crypto projects such DASH and Ripple.

Another unsolved problem is gaming the metrics. Aside from contributors gaming metrics, If the parameters that assign cred are in control of those with more privilege/capital, there will be an incentive to optimize those parameters for profit. Will that align with fair, meritocratic valuation of work? Or will it be massaged to extract value from those with less privilege? Some combination of both? I’m optimistic (and am a cynical veteran of the tech industry). But I don’t think we should lose sight of the fact that historically, new technology has tended to increase income inequality. Money attracts money. Technology that values labor (especially permissionless labor) accurately could be an a great tool to fight back against that. But it’s not a forgone conclusion.

2 Likes

Thanks for the reply @noman, you bring up a lot of interesting points.

A few thoughts / responses:

When I proposed simply tracking contributor metrics, with the idea of paying people directly for contributions (whether they were members of the guild or not), the reaction from some influential core developers was swift and overwhelmingly negative, effectively killing the idea on the spot. These developers (which likely have the most privilege, wealth and autonomy in the community (they can work on pretty much whatever they want)) saw it as an effort to control them and take away their “sovereignty”.

Really interesting case study and reaction. It makes sense, in that once people have an existing power structure (particularly one that pays them), the people with power are going to be motivated to prevent the system from changing. In some conversations I’ve had with @anthrocypher, she’s mentioned how adding money into an equation will tend to amplify the intensity of the reactions that you get, I suspect this may be playing a role in this case.

I’d be curious to hear more about how this guild operates – e.g. does everyone in the guild earn the same amount? Or are there further power delineations (and reward brackets) within it?

I had a conversation with the developers of another cryptocurrency focused on paying open-source contributors, and they said something along the lines of, “this whole SourceCred thing isn’t really necessary if you just want to build crypto-based reward infrastructure on top of open source. Just pay the maintainers, they are the ones that projects are suffering a shortage of, people are already willing to be code contributors for free”. My push back on this is that it will create a lot of really bad social dynamics around who “counts” as a maintainer. Your anecdote supports this thinking IMO, one might this “only maintainers get paid” system thinking that it will be replaced by something more equitable later on. But once the power structure and precedent exists, it may be a lot harder to change it to something fairer later, because of the entrenched interests.

But I worry about another reactionary response. And wonder if it’s better to propose the idea early, allowing people to give feedback into customizing (and risk it being killed for good), or to work on the customization myself until I come up with something that is more fair and appealing. Also, wondering if there is any material on how to “sell” something like this to an org that may be resistant to it? Case studies?

Honestly, I think it’s probably still early to be using SourceCred to directly approportion financial rewards-- as we explored a bit in the call today, the algorithm is still kind of naive, and not yet robust against gaming. Given how much pushback you got from the core group, it sounds like it would be better to wait until SC is more developed before putting it infront of a hostile audience. Right now if you’re looking to find problems in SC, it’s not hard to surface them. Also, we haven’t really “sold” SC to anyone yet (except Protocol Labs, I suppose, in that they are willing to fund its development :slight_smile).

A larger problem, privilege-wise, is that non-code contributions (including a lot of emotional labor) are not tracked. That means that, even if we’re successful in leveling the playing field for developers, on the larger playing field, developers pull further ahead (and they’re already overcompensated as is).

yeah. I’m curious if this cryptocurrency has any non-technical people in the “guild”? Or is it all coders?

That SourceCred is integrating with this forum (e.g. this conversation may generate cred), is an encouraging development. I think there are many ways you could measure interaction on forums, slack channels, twitter, whatever.

Yep. Conceputally, since SC is built around a plugin architecture, it’s pretty straightforward to integrate social forums. The challenge is doing it in a way that rewards meaningful contribution, rather than just lots of activity.

Aside from contributors gaming metrics, If the parameters that assign cred are in control of those with more privilege/capital, there will be an incentive to optimize those parameters for profit. Will that align with fair, meritocratic valuation of work? Or will it be massaged to extract value from those with less privilege? Some combination of both?

Another astute question. De facto, I expect the maintainers will be in control of the parameters (especially initially, before projects develop governance systems that are robust enough to make these kinds of decisions). I think one thing we can do is try to make SourceCred an exemplary “model citizen” of this new style of development, and really make an effort to treat everyone in the community fairly, and bias away from the powerful within SC tilting the playing field to their own advantage. The “do as you would have others do” maxim is especially powerful in cases where you are explicitly defining and role-modeling a new behavior.

But if they want free, valuable labor they will have to send some of their cred to those new contributors, who have a path to more cred. Projects that don’t accept these free, valuable contributions (so they can hoard their cred) IMO will be at a major competitive disadvantage if DAOs gain traction (and I believe they will). Giving more cred (or better, money) to newer contributors is not only an altruistic way to level the playing field, it’s a good recruitment strategy (another competitive advantage).

I also hope that doing a fair job of attributing cred will be a competitive advantage for open-source projects, in that open-source projects depend on a lot of voluntary labor. There’s an extra dynamic here which is the possibility of forking. In an extreme case, suppose that you have an open-source project run by a dictator or cabal that gives themself all the cred and rewards, and everyone else on the project goes un-rewarded. Well, “everyone else” can make their fork of the project whose cred distribution is parameterized differently, and since way more people are motivated to work on the fork, it may pull ahead of the original. This would be inconvenient and costly, not least b.c. then you need to persuade the dependents to switch forks. But having the threat of forking may force maintainers to be more fair with the distribution.

2 Likes

Really interesting case study and reaction. It makes sense, in that once people have an existing power structure (particularly one that pays them), the people with power are going to be motivated to prevent the system from changing. In some conversations I’ve had with @anthrocypher, she’s mentioned how adding money into an equation will tend to amplify the intensity of the reactions that you get, I suspect this may be playing a role in this case.

i think this is absolutely true. especially when you consider how precarious “employment” is in these projects. with everybody (presumably) working below market rate in the “normie” economy for ideological reasons. if you work hard for months (or years) and finally create some semblance of financial stability (however that works), you might be resistant to someone “disrupting” it. i have also absolutely observed (in myself and others) how money changes the relationship to open source work. there is an extreme sensitivity even to discussing what is billable and what is free work (of which there’s a lot of - i went from earning six figures to minimum wage (on good months) because i don’t bill for most work i do). someone gives you money, you give them control. period. and the second money touches work, it is shaped by it.

I’d be curious to hear more about how this guild operates – e.g. does everyone in the guild earn the same amount? Or are there further power delineations (and reward brackets) within it? I had a conversation with the developers of another cryptocurrency focused on paying open-source contributors, and they said something along the lines of, “this whole SourceCred thing isn’t really necessary if you just want to build crypto-based reward infrastructure on top of open source. Just pay the maintainers, they are the ones that projects are suffering a shortage of, people are already willing to be code contributors for free”. My push back on this is that it will create a lot of really bad social dynamics around who “counts” as a maintainer. Your anecdote supports this thinking IMO, one might this “only maintainers get paid” system thinking that it will be replaced by something more equitable later on. But once the power structure and precedent exists, it may be a lot harder to change it to something fairer later, because of the entrenched interests.

there are non coders in the guild. Probably more than coders if you count part-time members (who do get paid) (e.g. community manager(s), moderators, designers, marketers, etc.). the pay seems relatively even (and low’ish compared to US tech salaries, think $20-40 typical, even devs, though in reality it’s lower because people don’t bill for everything (see above)). there is a general resistance to sharing salaries/hourly rates though. Especially (predictably) at the top (see Faucault). the core devs are typically the maintainers of the main code repos, though i don’t sense a maintainer/contributor power imbalance per se (though note: i am a part-time guild member with limited visibility/power into this system).

Honestly, I think it’s probably still early to be using SourceCred to directly approportion financial rewards-- as we explored a bit in the call today, the algorithm is still kind of naive, and not yet robust against gaming. Given how much pushback you got from the core group, it sounds like it would be better to wait until SC is more developed before putting it infront of a hostile audience. Right now if you’re looking to find problems in SC, it’s not hard to surface them. Also, we haven’t really “sold” SC to anyone yet (except Protocol Labs, I suppose, in that they are willing to fund its development :slight_smile).

my pushback against that would be, that even the SC prototype does a pretty amazing job already. and the people at the “bottom” (the majority), are being paid 0. or a fraction of what they should. just paying people anything. even a trickle of micropayments that give them some visibility (on-chain) and a communication mechanism (money is a content type) with those in control of the treasury, would be immensely valuable. my thinking is that it’s OK as long as the stakes are low (e.g. start out at $100/mo (from my own pocket even)), it’s responsible. if it’s producing valuae, slowly raise it. i also think there are many at the “top” (especially in crypto) that want to pay people, but don’t have the tools/ability. even if those at the top (maintainers, investors, etc.) wanted to pay people further “down”, they simply don’t have the bandwidth. if they just started giving money out blindly, the would be taken advantage of. i shared some initial results with a more open-minded guild member. they said it was “pretty accurate”, but right away mentioned needing the time component (which i see there’s an issue for on SC’s repo). i think this is the biggest missing piece. let the flow of funds start the conversation at low stakes (micropayments even). let the system be guided by emergent behavior.

Yep. Conceputally, since SC is built around a plugin architecture, it’s pretty straightforward to integrate social forums. The challenge is doing it in a way that rewards meaningful contribution, rather than just lots of activity.

The plugin architecture is good and necessary. The degrees of freedom for measuring work are infinite. Seems like your graph architecture can handle it.

Another astute question. De facto, I expect the maintainers will be in control of the parameters (especially initially, before projects develop governance systems that are robust enough to make these kinds of decisions).

MakerDAO comes to mind. Their whole governance system is only concerned with setting of key parameters (interest rates, penalty fees, etc.). Seems to be working well for them. I could see a similar system working if the degrees of freedom are narrow enough. E.g. just vote on rates for different roles (dev rate, marketing rate, etc.), or a % given to individual contributors based on monthly self reporting, which is reviewed by “stakeholders” in a way that’s respectful of their valuable time. Or do it at the group level, where “contractors” with subcontractors get paid. Or do it piecemiel, for work that can be easily quantified (e.g. a typo fix is worth $0.25). uber for knowledge workers (but more like lyft please, and in addition to tipping workers get paid in liquid “equity” and early drivers, not just executives, share the wealth). we already have lots of models for valuing work that could be applied. my project is governance-focused, and could theoretically vote a system like this in a give it a budget, without guild consent (though the guild presumably owns large shares and may see it as a “coup”).

I also hope that doing a fair job of attributing cred will be a competitive advantage for open-source projects, in that open-source projects depend on a lot of voluntary labor. There’s an extra dynamic here which is the possibility of forking.

this would be a big barrier. my project was designed to be fork-resistant from the beginning. the costs to fork are estimated to be much higher than other projects. i think you could either implement something like this at the beginning of a project, or perhaps organize decentralized “strikes”, where contributors, presented with a fancy dashboard showing them a reasonable estimation of the value of their labor say, “hey, wait a second. i’m toiling for free why? people (rich people mostly) are making millions while i can barely make rent? if we all (or enough of us) stopped working, millions->billions dollar valuations, propped up by illiquid markets, would fall (and are shortable)" :evil_grin. has protocol labs considered a model where labor has bottomed, and that that could mean another bull run, similar to the labor movement in the mid 20th century :fist: :slight_smile:

Definitely interested to hear more about this… and about why you decided to switch from earning six figures to minimum wage (on good months).

there is a general resistance to sharing salaries/hourly rates though. Especially (predictably) at the top (see Faucault).

I think this will be one of the issues with SourceCred generally–right now everything is transparent, and I think people will be uncomfortable with having all this comp be transparent. Although it is good for exposing/curbing abuses of power. Maybe we are just moving into a more transparent world and just need to live with it.

Yeah, this resonates with me a lot. Actually, I’d been thinking of doing the exact same thing with the sourcecred community (micropayments to contributors based on cred, on the order of $100 per payment). I figured that if any community is going to dog-food this, (and accept potential weird social consequences) we are the best for it, since we are directly empowered to fix it. However, if another crypto project wants to try this out, I certainly wouldn’t stop them!

I agree that time-scoped cred is the necessary feature here, and is also a key requirement for a lot of other use cases… e.g. if you want to send out a weekly newsletter thanking recently active contributors, you need a way to time-scope cred. We ran out of time in office hours so I didn’t go into my priorities for sourcecred development for the quarter, but I basically want to ship a reliable + easy to use API for time based cred.

Also, good to hear that another project thinks the scores basically make sense! That’s been very common feedback for me as I show the prototype to various projects.

I agree, I think it’s really important that people earn “equity-like” long-term rewards (that hopefully give financial sustainability) rather than 1-off lowest-acceptable-price payments. I don’t want to further contribute to a divide between those few insiders who get long-term wealth and a digital precariat that live commit to commit.

IMO, forks are hugely important in changing the power dynamics vis-a-vis traditional labor/capital relationships. Consider the example earlier, of uber/lyft. If drivers are unhappy with how they are being treated+rewarded, their options are not great. They can strike, but they lose their income and they may just not have that financial flexibility. Their BATNA (best alternative to negotiated agreement) is one in which they don’t get paid. Finally, even if the public is supportive of the strike, it’s hard for them to act in solidarity, other than by not riding (which may also be nonviable, e.g. they commute via Uber). The drivers and public are stuck with negative actions that impose cost on other actors, but without positive actions they can take.

Now imagine instead that uber is a forkable cryptonetwork. Then rather than threatening to strike, they can threaten to fork. This presents far higher upside, because if the fork is successful, they can redistribute very large chunks of the equity in the network to the drivers, i.e. change the economics radically rather than incrementally. And it’s an easier spot for drivers to coordinate around, because they are not stopping work, they are just switching networks. And it’s easier for the public to support, since they can also switch networks, and thus tangibly contribute to the movement. Since this is a far better BATNA than a strike, in this case the network operators should be way more accommodating to the drivers from the start, because the drivers have a great alternative to working with them.

What do you mean?

Definitely interested to hear more about this… and about why you decided to switch from earning six figures to minimum wage (on good months).

I actually wrote an article about my journey. But, not having the time to work for free on it (see minimum wage), I loosely negotiated in chat with project leaders (or people I think will vote to pay my invoice anyway) to get them to pay for it, understanding that by accepting money I was losing some control over the work. The PR people liked the article enough that they’re shopping it around some larger publications, and I’ve been asked to sit on it until I hear back. Because rates/terms were never explicitly discussed, the amount I bill will likely be in part determined by the impact of the article (and perhaps resulting greater “cred”/“status” in the community.

I think this will be one of the issues with SourceCred generally–right now everything is transparent, and I think people will be uncomfortable with having all this comp be transparent. Although it is good for exposing/curbing abuses of power. Maybe we are just moving into a more transparent world and just need to live with it.

Information is power. Those at the top maintain (and increase) their position by sharing/trading information with those at the same level and above (if you consider that money is a content type, this theory is quite encompassing). Even though there is now wide recognition that the gender and racial wage gap, for example, could be narrowed by making salaries public, few are doing it. I can share here that I’m earning minimum wage, because I have little to lose (and perhaps something to gain). Being a pseudonymous spaceman also helps :slight_smile: Will you state here how much you earn as CEO of SourceCred? I would expect not. The leaders of my project, for instance, have been saying that they will release an audit of the Treasury for months (if not longer). But it never quite happens… despite persistent outbreaks of cries for it…Hmmmm…Teams other than marketing have had to go through budget approval, but devs have not (and are more vocally opposed to their privacy being violated by having to divulge their salaries). I think this dynamic if fundamental to the current system. And will likely be recreated even if we sprinkle blockchain fairy dust on it. It could get worse. The opportunity here, I think, is in attracting underpaid (or not paid) talent to systems that are transparent, and that is part of why they pay more. Perhaps give them a chance to participate meaningfully in governance on the level they’re qualified, allow them to fork, etc.

“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.”

Buckminster Fuller

All of the focus is currently on the bottleneck (devs), but the pyramid of labor turning their expertise into money is currently undervalued (and sometimes not paid at all). That represents a huge “arb” opportunity for organizations that can be transparent and offer those at the bottom a path to stability and equity.

However, if another crypto project wants to try this out, I certainly wouldn’t stop them!

Indeed, with open source, you don’t have the power to :slight_smile:

I agree that time-scoped cred is the necessary feature here, and is also a key requirement for a lot of other use cases… e.g. if you want to send out a weekly newsletter thanking recently active contributors, you need a way to time-scope cred.

I actually wrote some python code that scans our GitHub repos for new contributors. Those contributions (GitHub commits typically) are then manually reviewed, and if non-trivial, thanked publicly via a monthly newsletter.

We ran out of time in office hours so I didn’t go into my priorities for sourcecred development for the quarter, but I basically want to ship a reliable + easy to use API for time based cred.

If I knew JS, I’d be hacking on this already. Since I don’t, may look at just time-filtering the GitHub elements I input into it (do you think this would yield anything meaningful at all?). Or possibly just run a “post-processing” on the rankings, where I take the credit score for each node is adjusted as a function of time (perhaps a Gaussian where the mean is the current time, and the standard deviation is set to optimize the “long tail”, to keep long-term contributors receiving cred/payment for super impactful work.

Now imagine instead that uber is a forkable cryptonetwork. Then rather than threatening to strike, they can threaten to fork. This presents far higher upside, because if the fork is successful, they can redistribute very large chunks of the equity in the network to the drivers, i.e. change the economics radically rather than incrementally.

I think that if the code stays open source, and users control the data (our project is paranoid about that and doesn’t rely only on GitHub), then this becomes possible. Permissionless even. And perhaps more sustainable (neither Uber or Lyft are profitable if they stop heavily subsidizing drivers with VC money).

What do you mean?

Just that this could be a tool to organize open source knowledge workers (and since open source is taking over, knowledge workers in general). We’re in a moment of upheaval where people are so dissatisfied that it’s once again scaring the ruling class; as has happened cyclically and predictably since the beginning of capitalism. The middle class in America during the 20th century was unprecedented in history, in terms of wealth and power transferred “down” to the working class. It was largely a reaction to the industrial revolution, extreme income inequality (statistically, income inequality is back to where it was in 1929, right before the crash), inhumane working conditions, and organizing. Lots of hard work and new tactics to organize labor. Many argue that the transition we’re undergoing is on the scale of the industrial revolution (information revolution, whatever you call it). I think it’s shortsighted to say that organized labor is dead. History may not repeat, but it rhymes. I can imagine big labor” making a comeback, enabled by new tools for communication and collaboration (and privacy), and ability of global citizens to work outside of nation-state restrictions (I work with paid contributors that are pseudonymous cartoons in other parts of the world).

1 Like

A post was split to a new topic: Thought Experiment: “SourceCred Treasury”

@noman I’m getting hyped reading your post, love your thoughts on this.

@brianlitwin great to hear. Hyped on the possibilities, obv :slight_smile:

Wow @noman, your enthusiam is palpable! :smiley:

I enjoy envisioning SC not just as a ranking or distribution mechanism, but more holistically as a system which incentivizes or disincentivizes certain kinds of behavior. So I was wondering, if SC in its current form were turned on for your “guild” tomorrow, how might being ranked affect contributors or alter their behavior?

All hell would break loose. Some lead devs would call for my head in an emotionally charged group chat, and I’d fear (perhaps rightly) about my only source of income. If you mean what would happen if the “guild” adopted this on its own, I imagine it depends a lot on the implementation. If it’s just for “informational purposes only”, no money attached? It would be a source of curiosity. People of a certain personality type would become obsessed with it. People might hack it for fun (e.g. inject the entire text of Lord of the Rings into a header file and claim the top stop, mocking the system. A private chat channel is created just to get lulz by putting someone undeserving at the top of the rankings (boatymcboatface has the most cred), etc.). It might just be a novelty for a few days, but eventually largely ignored. It might get customized over time and used in decision making. If used, it would likely augment a phenomenon I’ve observed in open source projects generally – that status (cred) does operate almost like a currency. I don’t think the cred score would replace that unspoken, more nuanced currency, but it would inform it.

If SC determined how much money you were paid, that’s a different story. I do think people would become very interested in how the algorithm worked. Dig into the code, find out how to game it. Or just more generally do the rational thing and make sure you’re going to keep getting paid in this new scenario. There will be a (rational) fear of others “juicing” their cred scores. Pressure to do the same. Power might shift to those with commit access, who are now incentivized to block some contributions to keep out spam (real or perceived (and the lines will blur here)), or for various political reasons. I also think that if the project was committed to making it work, a lot of these problems can be addressed. And that actually, out of the box, it would still probably be a better, fairer way of paying people. All those games around money still exist currently, just in different (more opaque) forms. At least it would be in the open, a conversation started.

To make it work really well, I think you’d need some customization. Probably some "human in the loop”. Like the “spotlight” feature I believe I saw on here somewhere, where humans can manually nudge cred. A governance system could also be useful (perhaps necessary). E.g. you could fork MakerDAO’s governance system, and instead of the ongoing active voting on risk parameters (interest rates, debt ceiling, etc.), vote on a limited set of cred parameters. E.g. weights for code reviews, weights for comments, etc. Perhaps add some skin-in-the-game-style incentives. E.g. a “griefing” system, whereby if a person tries to obviously game the system, they’re punished harshly (perhaps set to zero).

I also think one could phase this in in parallel to an existing system. Salaries continue to be paid by the existing system, but some small % of the budget is distributed by SC. That keeps the stakes low while the system is attacked, customized, and made more robust. If the system is working well, the budget can be increased over time. There is a possibility that the people with the most money and power in the current system will oppose this because it will actually decentralize power. In the end, we’re all still humans here (even the ones shouting the loudest about decentralization on Twitter), and they will resist giving up their power. But I also think it will create more work/value overall, which will eventually translate into more money and power for all. Systems that adopt this will simply be more competitive. Andressen Horowitz, capitalist as they come, is putting out papers on scaling co-ops.

The system could also be introduced in more limited capacities/applications. Maybe it’s used to spot “rising talent”, in your project. Maybe it’s pointed at the competition, for intel purposes or recruitment/headhunting. Maybe it gets used to generate cool visualizations of contributors’ cred over time (imagine a bar chart race for Ethereum devs – would totally go viral in that ecosystem and perhaps give SC some nice cheap exposure). Perhaps someone is given a grant to explore these ideas as a way to introduce SC to the ecosystem in a non-threatening way.

(Note: there’s so much to reply to in this thread! I think we should maybe start biasing to splitting off into other threads with new ideas. For now, I’m going to try to do one-reply-per-post and engage with a lot of really interesting comments. :D)

I’m not the CEO of SourceCred (which isn’t a company, and doesn’t have investors, executives, or a CEO). So I also don’t have some big claim on future economic rewards from SC that I get to monopolize and then dole out to other insiders. If/when SourceCred does a token distribution or similar, it should go through SourceCred’s own public cred attribution, without any special “insider mode” where the people running the project get to pay themselves big opaque bonuses. If, when the distribution is actually happening, I defect and try to do this, you should throw these words back in my face and organize a fork of the project. :slight_smile:

(You might accurately suspect that I don’t subsist on blockchain pixie dust. I’m an engineer on Protocol Labs’ payroll; they’ve decided to support the project, and that support comes in the form of paying people to work on it full-time. When we get around to a full, nuanced cred distribution, I think PL should and will receive a lot of cred, both for funding and a lot of organizational/operational support. Figuring out exactly how to do this fairly will be a really interesting question.)

This is a really interesting idea. I’d love to read more about your thoughts here, and suggestions for how we could apply this insight to SourceCred. Right now our infrastructure is focused on recognizing the value that devs provide (looking @ Git and GitHub) but the Odyssey Hackathon is coming up, and I think we’re going to focus a lot there on building tooling that makes it easier for us to recognize other contributions. So, I’d like to experiment with your theory by doing a better job of valuing and rewarding all the other labor that SC needs to be successful.

Can we support you in learning JS, via hacking on our codebase? :slight_smile: The Live Coding Session we did a few months ago could be useful for orienting on the tools in the codebase and how to get started.

As for specific approaches on time-weighted cred: in the long term, I expect we’ll do time-filtering via “Personalized Pagerank”, where we have the seed vector for exploring the graph start by pointing to all the contributions in a certain timeframe, and then see where cred propagates from there. In the short term, I think that something like just time-filtering the contributions could work well. Suppose that C(t) is the cred distribution for all contributions up through time t. Then if we want the cred just for the interval [t, t+1] we could define it as C(t+1) - C(t) where subtraction is just elementwise score differences. This is pretty easy to hack; you could do it right now by just running SourceCred one week, then re-running it a week later and seeing what the diffs are.

For the goal of having a robust, reliable API, we’ll obviously need to actually integrate this into the system in a more principled way. Actually getting the data from GitHub is straightforward, we can modify the schema to get creation dates for all the posts. However, it’s not totally clear how to incorporate timestamps into the Graph. Giving every node a timestamp would be a bit odd because some nodes, like user accounts, don’t have natural timestamps associated with them. @mzargham has proposed organizing the graph to have different fundamental types of nodes including an “Event/Post” type which would have a natural timestamp associated, so implementing that system would be one way of doing this in a principled way. As a hack, I might be willing to condone adding a nullable timestamp field to nodes in the graph, although I suspect @wchargin might object.

When we get around to a full, nuanced cred distribution, I think PL should and will receive a lot of cred, both for funding and a lot of organizational/operational support. Figuring out exactly how to do this fairly will be a really interesting question.)

Very interesting. PL should definitely be rewarded. This wouldn’t exist it looks like without them. If they take too big a cut though, they’ll not give contributors enough for this to be interesting/take off, and open the project to criticisms of centralization. Presumably the reward should be as organic as possible. E.g. SC or related projects get an early stake due to being early adopters, and then that stake appreciates in some way…

So, I’d like to experitment with your theory by doing a better job of valuing and rewarding all the other labor that SC needs to be successful.

I’d say most of the other labor is captured by forums and social media (e.g. this post, moderation (defending against trolls is hard emotional labor)), though to be truly expressive (and therefore equitable), messier human inputs will need to be captured.

Can we support you in learning JS, via hacking on our codebase?

Is that support in the form of cred? Money? Mentoring? Connections? I’m looking forward to watching SC’s evolution, and participating where I can (e.g. this comment). But while I’d like to learn JS (lots of exciting stuff being built with it), I have already heavily invested several years learning Matlab, python, and now go (very different languages, JS syntax looks alien to me). It would take several months to start coding bad JS, which isn’t feasible for me right now. If Source Cred wants to support me in other ways. E.g. pay me part-time in any liquid crypto to create a rogue MVP hacked together with python, GitHub and Medium articles, I’m all ears;) I am fairly heavily invested (on many levels) in my current project (which I had to work at for free for a couple months before they started paying me). I’m also working my up in the guild, which has invested in me despite lack of qualifications usually required to get a full-time developer position (which I’ve never held), and I am gaining valuable experience. Feel the need to “ROI” for the project, at minimum (their skin-in-the-game game is strong). While also trying to diversity income with freelancing gigs. Also, living paycheck to paycheck right now. Have to keep my habbit of contributing for free to amazing projects in check (Source Cred is dangerous in that respect:).

As a hack, I might be willing to condone adding a nullable timestamp field to nodes in the graph, although I suspect @wchargin might object.

+1. Also posted a perhaps hacky but perhaps useful workaround in the new thread.

Also living paycheck to paycheck. So have to limit my time spent on

So, we’ve been talking quite a bit about how to capture the value of an individual’s comments on a forum like Discourse. Generating excitement/momentum behind the ideas/narrative of a project directly feeds into the labor that produces all the other components, e.g. the code contributions. So we’re working on making your contributions visible in SourceCred.

On the subject of learning JS: don’t feel blocked by having to write great code or as though you have to “prove your commitment” by contributing a bunch of free labor before the maintainers take you seriously. If you look at the SourceCred PR history, you’ll notice Dandelion and William giving lots of feedback to first-time contributors. This isn’t the normal dynamic I’ve witnessed in other repos.

also @noman, if you wanna write python, check out the sourcecred/research repo

One simple approach is for PL to earn explicit cred for supporting SourceCred (e.g. since I am being paid by them to work on it, some %age of all the cred I earn goes to them). Then they could also get cred from the OKR process b.c. they set it up, etc. (Challenging question of how to value the OKR process. :slight_smile:)

If we do go with the “employer takes %age of cred” model, the employee should always be allowed to walk, and contribute on their own (and keep all their cred). Although that woudn’t change the distribution for old contributions.

The support would be in the form of mentoring, connections, and cred. I like your SourceCred treasury suggestion a lot, so maybe before too long we can set up a solid pipeline for money->cred.

I agree with @BrianLitwin that your contributions here on the Discourse are quite valuable, so in that sense you are already earning cred, we just haven’t been able to formally recognize it yet. :slight_smile:

to be truly expressive (and therefore equitable), messier human inputs will need to be captured. Yep, keep your eyes out for whatever comes out of the odyssey hackathon. Current brainstorming.

@brianlitwin great to see sourcecred/research. Just the fact that python has hooks into this could be very useful. And obviously this is ripe for interesting research.

@decentralion mentoring, connections, and cred are no doubt valuable. Alas, I have gone broke and into debt working on other projects for free and pursuing my crypto dreams. Six months ago, I’d be all in. Now gotta put my time in the guild and focus on currencies my landlord accepts (no SC, I asked). Also, since what excites me about SourceCred is that it’s the key missing piece in the open source funding puzzle, it seems right to ask for money. If ETH (or whatever) stared flowing through cred tomorrow (which I think it could), I would be much more inclined to contribute. Even if the amounts weren’t large. That also might be a good, more inclusive way to take this to the next level. Something that informs some of these big design decisions being made with real data (and people with less privilege (many people need less money than you think to contribute)). And honestly, with the right fiery medium piece and retweets, and the treasury being permissionless, an inspired whale could kickstart this puppy before you know it :firecracker: