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 
).
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.
