Harberger Grain License

The CredSperiment Research
1

Thanks to @burrrata, I discovered 1Hive’s Harberger’s Commons License project, which has a lot of relevance to future plans for SourceCred / Grain:

The vision for Grain is that it will create a project-specific token for any open project, and thus provide a way to flow economic value to the project’s contributors, supporters, and upstream dependencies. Thus we could imagine a ‘Harberger Grain License’ as follows:

I believe this has several improvements over the base HCL:

  • It provides a framework for directing the tax revenues back to the contributors and supporters of the project
  • It flows the revenues upstream to all the project’s dependencies, thus supporting the whole ecosystem and not just leaf nodes
  • It suggests a framework for raising the capital to buy out undervalued proprietary projects

To elaborate on point 3: suppose that someone makes a project that would have a value of $50m if open-sourced, and they set the buyout price at $10m. What good samaritans are going to raise $10m to prove that point? Within the framework of grain, the buyers would then own grain in the newly-open-sourced projects (as befits their status as financial sponsors), which provides a way for them to recoup their investment (and then buy-open more projects).

Before either system could be used in practice, we will need to figure out the semantics for splitting the rewards across different open-source dependencies. Suppose that a project depends on both left-pad and nodejs. Clearly nodejs should receive more of the tax revenues than left-pad, but so far we don’t have any framework for making these decisions.

Thanks to @lkngtn for writing the Harberger License post!

3 Likes
2

Yeah so as you mentioned, the main strength of 1Hive and our contribution to the HCL is the DAO aspect: frameworks that help communities make decisions and manage funds. Data science and creating graphs to track complex networks is not something we’re looking to roll in house. We do however have the framework to create tokens, manage tokens, and receive, exchange, and manage funds.

As such, if the $TBD_FRAMEWORK_FOR_GRAIN_SPLITTING was an Aragon app, then all of this would be easy for communities/projects to use. They’d click a few buttons and roll out a DAO with the SourceCred mechanism built it. Then the SourceCred app could be configured within each DAO community to receive grain, allocate grain, exchange grain for ETH/DAI, and use grain for voting. All the apps to do this are already being built on Aragon. SourceCred would then be responsible for connecting the graph to ensure that grain is properly flowing where it needs to go. This way you could focus on building the SourceCred protocol, and then each community could easily deploy and configure their DAO however they wanted to. This would really just require the SourceCred protocol to be working and an Aragon app to integrate that flow into a DAO.

Of course, I’m sure there’s some mistakes/assumptions here, but overall I think that this would work. Siince the da0 recently stated that it also wants to use SourceCred and an Aragon DAO, this might make a lot of sense for SourceCred, Aragon, and organizations/communities that want to use similar mechanisms for their projects (like the dao). I’m just brainstorming here, but I think this could be really cool :slight_smile:

3

Actually, the difficulty I have in mind for grain splitting between dependencies is not technical, but political and economic. Basically: how do we ensure that projects make fair judgments about how to split grain between their dependencies?

Suppose that project A depends on B and C, and suppose that (per custom) A is giving 20% of its grain to its dependencies. How should it split grain between B and C?

A first pass (naive) answer would be to split the grain equally across dependencies. Clearly, this would incentivize people to explode projects into as many tiny dependencies as possible. Also, it would incentivize greedy maintainers to pull out “utilities” that they personally wrote from the shared library, so that they can capture more grain for themselves.

We could imagine a more “data-driven” approach, like something based on the actual call dependency graph, but this would still be game-able (e.g. encouraging needlessly verbose APIs).

I think we will need some set of norms and perhaps a legal framework to solve these issues. SourceCred has the same issues of game-ability, but since every instance is its own community, it admits local moderation. E.g. if someone starts to game SourceCred, then I can use my cred and/or maintainer status to stop them from getting unfair cred. Or, if I start to misbehave, the community can fork SourceCred (or just fork SC’s cred instance). Every project is its own experiment in norms/moderation practices/leadership, and the projects that find good systems will thrive.

However, in the broader “commons” of cross-project dependencies, there’s no “maintainer” who can step in to handle disputes, and it’s not really feasible for projects to fork the dependency graph (or their downstream dependents) if those dependents are behaving unfairly. So it’s a harder problem. I think we’ll need new cryptonative legal systems to handle it.

4

You don’t. It’s up to each project to decide that on their own. If a project has a crappy grain split, someone will fork it and create a better grain split and then people will just use that project instead. Maybe both exist and one is the cheap bare bones version and the other takes a higher fee but has more active development. Anyone can fork anything at any time tho, so I think the nature of open markets and competition with sort itself out regarding competitive rates for grain splitting

5

This has been my best answer so far. But I’m not fully satisfied with it.

Ok, suppose that $Project is screwing over $Dependency by giving them a low share of the grain. Among people who are paying attention, it’s pretty clear that $ProjectMaintainer is doing it so they can “corruptly” reward some other project they have an interest in.

Now: who is going to fork the project? Perhaps a core contributors can, but the maintainer can probably retaliate by ensuring that this honest contributor is under-rewarded via cred in the base project forevermore. And getting the new fork to stick will be a very difficult endeavor. Are users going to flock to the fork? When it doesn’t actually have any advantages over the baseline, except for switching costs?

I think contributors will be willing to fork projects they contribute to, if they are directly getting screwed over by a greedy maintainer. However, I don’t know that contributors will fork a project they contribute to because it is screwing over its dependencies (the contributors get paid either way). And it’s very hard for the dependencies to get a fork to stick.

One option would be for the dependencies getting cheated to go to $Project’s dependents, and say, in essence: hey, would you please stop sending grain upstream to $Project, because $Project is defecting against its own dependencies in turn. If the major dependents went along with such an action, it would put a lot of pressure on $Project to change its ways.

And perhaps after a few turns of this wheel, we’ll collectively evolve stronger norms and governance practices around this.

1 Like
6

What if there was a min_cred parameter that projects using SourceCred could configure? Then, within the protocol, projects could say that other projects can use their code, but there’s a minimum amount of cred that would have to be kicked back if they use their code directly or as a dependency. That way a project can set their minimum (which would eventually be whatever the market equilibrium is), and anything beyond that is upside. If that much cred is not being kicked back, the project would be breaking the rules and kicked out of the protocol.

In a context like Aragon DAOs this would work because the protocol is enforced by a decentralized network like Ethereum (via a staking/challenge game on top of Ethereum, the Aragon Court, or some kind of L2 scaling solution). In the context of someone just running SourceCred on a server for some web2 project, really they can do whatever they want. Also, due to the joys of permissionless innovation there might even be multiple SourceCred forks operating on the same network, some that enforce kick backs and some that are completely lawless and opt-in/volunteer based. I think that at least making that a parameter that projects can specify tho would help a lot

7

Point of nomenclature: cred is a non-fungible reputation metric, non-fungible because cred is always specific to contributions, and the cred of any contribution may change over time. For example, suppose a developer writes a big pull request that the community is really excited about, it gets lots of positive reactions, they get lots of cred. However, it turns out to be super buggy and unreliable, and the feature never ships in a release. The cred evaporates.

Grain, on the other hand, is a fungible token that is issued based on cred. Once you get grain for your cred, it’s “locked in”, and is tradeable, etc. (Projects might have a sort of “vesting policy” for cred->grain, to ensure that you can’t get grain for flashy contributions that don’t stand the test of time.)

The dependency compensation mechanisms I imagine are all in the Grain part of the system, so it would be a min_grain kickback.

That aside: I don’t think a minimum price for using an open-source project is a good idea. One of the big benefits of OSS is that it’s free to use, which means that anyone can use it (regardless of whether their marginal value from usage is very high or low), so it gets the biggest network and creates the most value for everyone. The min_grain system would turn every OS project into a little monopolist, trying to find the highest price the market is willing to bear, with the effect of pricing out smaller or more niche and experimental usage.

To give a concrete example, let’s imagine an open-source machine learning framework, with tons of sophisticated deep learning type stuff. Clearly they would set a high min_grain price, because they can get away with it, so that those applications that absolutely must use ML will pay them a lot. However, now all of the edge cases where ML is not super core to the product, they’ll be very reluctant to use it, because it was priced based on what the core users are willing to pay.

Also, such a system would create really strong incentives for projects to fork their dependencies, so as to make a fork with a lower min_grain price. What coherent norms could we build around that?

tl;dr: I think putting a price on open-source is a bad approach.

8

the cred of any contribution may change over time

Does this happen automagically, or via some sort of voting mechanism?


Once you get grain for your cred, it’s “locked in”, and is tradeable, etc.

How do you get grain for cred? Who/what mints the grain, and how does the conversion happen?


What if the min_grain parameter only engaged for close source projects (or projects that are for-profit and not FLOSS), but not open source ones?

1 Like
9

The cred of every contribution is always changing over time, because it continues to earn more cred in the future. For example, your post might earn a certain amount of cred in this week, and then later if newcomers to the forums like it or quote it, it will earn more cred in the future week too. That said, this is really just accumulation (it earns X cred in january, Y cred in feburary, and so forth) and not really a problem for fungibility.

However, as currently implemented, the “weight” of a node is a timeless property (i.e. it describes the node itself, and not a connection with that node for a particular time). So in the example of the over-valued PR, maybe it got a high weight initially (whether through voting, or the maintainer set it, whatever), and then later its weight was lowered when it proved deficient. In that case, its cred retroactively decreases.

In this particular case, it was not very automatigical. However, in many cases the retroactive updates may be more automatic. For example, suppose that a project adds a new heuristic for valuing Discourse posts–that Discourse posts with a lot of text get more weight than posts that are very short. Then the heuristic can automatically apply retroactively.

The project issuing grain will set up a minting policy that determines this. One idea would be: the project tracks your lifetime total cred, and your lifetime total grain minting, and then works to slowly equalize these. So, e.g., every week where you have more lifetime total cred than lifetime total grain rewards, you receive 1% of the difference as a grain reward. This is sort of a “vesting policy”; it means that if your contribution was initially over-valued, it gives the system a lot of time to correct rather than overpaying you.

10

Really like this idea. Vesting over time is proven and understood, but I think having a simple mechanism that is also easy to understand but dynamically interacting with you could be more enticing. For instance, at a normal startup, the vesting schedules typically starts at 1 yr. For many open source projects, you may not be looking for that kind of time commitment, especially if it ends up being more sustainable to “project hop” looking for niche opportunities that match your skills. Also could smooth out volatility in the price, as you wouldn’t have “employees” dumping all around the same time like you do with many IPOs.

11

I still think setting a fixed price for using software is … inelegant. Prices are great for rationing access to scarce resources. But software has zero marginal cost, so… whatever price you set, it will price some people out of using the software, and that’s deadweight loss.

I like the Harberger Tax framework better. I imagine the tax almost more like a “subscription” to having access to the entire open-source ecosystem. Then there’s no marginal cost to using more open source software, you can depend on all of it if you want. The issue is then we need a (fair, trusted, open-source) mechanism for splitting the tax revenues between projects.

Also, even if min_grain limited to closed-source projects, a lot of the issues I described still apply. E.g. under what circumstances can someone fork a project and lower its min_grain rate?

1 Like
12

Love this thread! :heart_eyes:

Agreed, this is the underlying motivation for me in pursuing the Harberger license route as opposed to using something like https://licensezero.com where each dependency is given a specific price and the ultimate license price depends on the prices set for all dependencies. This is elegant and practical in its own right, but I don’t really feel that it is really aligned with the ethos of open source software and as you point out it makes the commons less accessible (at least for commercial derivatives).

This was the problem and conclusion that I’ve come to regarding the harberger license as well, it seems really challenging to come to global consensus on weighting of contributions across dependencies. Something like sourcecred can work well within the context of a specific project, but it seems really difficult to objectively determine attribution across projects without some sort of top-down governance structure that is tuning specific parameters.

The approach that I’m currently pursuing, is to route all funds generated by the reciprocity fees of the license into a non-profit chartered to support the “commons” that is established by the license, and then have that non-profit operate grant programs with a preference for bottom-up allocation methods. For example the CLR mechanism described by Vitalik, Glen, et al in Liberal Radicalism or possibly a one-person-one-vote weighted implementation of conviction voting (tried to link to the medium article by giveth here, but as a new user It would not let me).

The goal being to take a step back and say we don’t have a good way of weighting cross-project dependencies, but we also know all the funds shouldn’t just go to the project that is at the very tip/end of the decency chain. So instead lets treat all projects under the license as eligible to receive grants, and rely on a decentralized mechanism to prioritize allocation to various eligible recipients.

Once the funds reach a particular project, the cred mechanism seems like a suitable way to distribute those resources to the project’s contributors.

EDIT: It is also worth noting that directing the funds in this way can also help address another issue with the license which is that since paying someone’s self assessed valuation doesn’t grant the payer exclusive rights to the software but instead adds it to the commons, there is less of a direct incentive for individuals to pay and a common resource pool that can be directed could also be used to “yank” these upstream changes back into the commons.

3 Likes
13

So… what if I’ve already exchanged my Cred for Grain and then cashed that out on an exchange or against a bonding curve? The point is that it rewards contributors with a token, and then that token has to be fungible, so how do you retroactively decrease the balance of a fungible tokens that has been traded?

I must not be understanding this correctly, but again… if cred and/or grain is to be exchanged for any other assets at any time then how does this work? Does the SourceCred system then put you in debt and give your account a negative balance if you sold off your grain, then it rebalanced your grain and realized you don’t have enough tokens?

Seems like a huge upgrade from most grants programs

Yeah this would make much more sense on a local scale within a project than a global scale of linking all projects together

14

You can’t retroactively decrease the token issuance. The vesting mechanism adds a time delay between earning cred and issuing tokens, which will probably prevent over-issuance in most cases. But sometimes people will just get overpaid; I don’t see how to avoid that entirely.

Cred is not fungible and cannot be exchanged. So it’s just the grain that’s getting issued.

Let’s go with a concrete example, where you earn 10 cred in the first month, the project always pays out 10% of the difference between your total cred and the total grain that was issued to you. And in the 3rd month, we re-evaluate your cred down by half.

| Month | Lifetime Cred | Grain Issued | Grain This Month | | – | – | – | – | – | | 0 | 10 | 0 | 1| | 1 | 10 | 1 | 0.9 | | 2 | 10 | 1.9 | 0.81 | | 3 | 5 | 2.7 | 0.23 | | 4 | 5 | 2.9 | 0.21 |

You can see in this case, even though your cred was down-evaluated by half, you still never get overpaid, because of the slow vesting. Alternatively, if the cred had been evaluated down to 1 in the third month, then you would have been overpaid. At that point, you’d be in “cred debt”, meaning that the next ~0.9 cred would not earn any new grain for you, as you’d have to get to the point where your lifetime cred was above your lifetime grain issuance before you’d get issued any more grain. (Vulnerable to Sibyll attacks, so we’d want to avoid this situation coming up very often.)

15

We can do a little better than this; we can at the very least say that when revenues should flow within the dependency tree of the projects that brought the revenues in.

E.g. if a project that depends only on Node and React pays $10k, then it’s reasonable to split that money between all the transitive deps of Node and React, but none of it should go to Go or Haskell or Angular.