[remram]

I don't understand why you would want this to be in the code. That is just not compatible with how source code versioning works.

If you, a contributor, want to change your funding preferences, you have to file a PR with the project? If you update your preferences, other branches of the same project can still have different preferences? If you fork a project, you have to put a meaningless commit in there to change funding to your fork project, a commit that will have to be reverted if you ever merge upstream or you subvert upstream funding?

[jka]

I'm not sure it's the perfect solution, for reasons that relate mostly to the (necessary, useful) ability to modify and adjust rewards on a long-term and after-the-fact timescale, but I'll offer one reason why this could be a good idea:

It codifies the social side of enterprise ownership.

Not just for the participants in the enterprise itself, but for potential investors, users of the service, collaborators and business partners as well.

I've spent a bit of time wondering how to effectively measure and assign share value to FOSS project contributors, and have always looked to technical solutions. Things like metrics and weightings and machine learning models built in aggregate based on customer success, company growth, and revenue metrics across a wide range of projects, with the resulting models then used to evaluate individual market entrants.

It has never felt like that is a workable approach: every enterprise is different, and some would be unfairly overvalued as a result, and some would be unfairly devalued. It also might not generalize well to non-profit and community-interest companies.

And so the technical approach might all be too complicated: perhaps a better solution, as offered here, is simply to commit the ownership structure into a repository and then allow that to be edited like any other code.

[wizzwizz4]

> It codifies the social side of

There's the problem. The reason the thing you're replacing is so complicated is because it tries to codify some aspect of human behaviour. If your solution for handling (e.g. money) is radically different to the existing (financial) system (which this is), it will probably blow up in a big way.

[jka]

In practice I think it's likely that most law firms and jurisdictions who configure and accept business ownership structures enforce their terms in a nearly-as-restrictive manner. No doubt there are exceptions; a file format can be adjusted over time to handle those equally.

The file format should -- and to some extent, is already -- separated from the mechanism(s) of payment.

Version-controlled software development is social and provides history, evidence, and allows code to evolve over time; I like that this approach leverages those properties.

[remram]

I have nothing against it being written down, or even written in a structured format. I just think putting this in the source code repository is inadequate.

[rndhouse]

Changes to the lock file (`OPENFARE.lock`) need to be reviewed. The lock file needs to survive a project fork. Changes to the lock file need to be tracked on a contributor level. The lock file needs to be signed by those who care about the project.

> If you, a contributor, want to change your funding preferences, you have to file a PR with the project?

Yes, or, a bot could track your funding preferences from some repo and submit a PR for you. (Cryptographic verification permitting.)

> If you update your preferences, other branches of the same project can still have different preferences?

Yes but those other branches will be outdated and git will make that clear. Only the commit from which the software package is derived matters. Donation schemes are derived from software packages.

## Forking a project

Contributors could get a share of donations by proposing a change to a project's lock file via a pull request. Or they could fork and make a change. But their fork would have to stand on it's own as a software package.