Seems like a really hard problem to measure contribution automatically. Anyone know how you'd do this?
[0]: https://gitroyalty.com/docs/faq/how-do-open-source-developer...
31–40 of 52 posts
Seems like a really hard problem to measure contribution automatically. Anyone know how you'd do this?
[0]: https://gitroyalty.com/docs/faq/how-do-open-source-developer...
Ok, I'm pretty fond with this, and it looks like a great model. Some things that bugs me: * I wouldn't term it as an 'OSS paywall'. I would rather term it as an 'package paywall', or 'repo paywall', or something else. * I would prefer not using GitHub accounts, and rather have an own GitRoyalty account. I would like to have multiple login methods (like GitHub, GitLab, Google, Facebook, GitRoyalty account). * I think…
This is definitely on the roadmap and eventually we'll expand outside of GitHub and allow repos from other hosts like GitLab.
> ... changing all of the GitRoyalty package links, installing the packages...
You should always commit your GitRoyalty license keys and share it with your teammates. This way you never have to deal with your package.json/lock files directly, just `npm install` and you're good to go! (This takes care of updating for you as well)
> I'm pretty impressed with the beautifully done website.
Thank you! I just used bootstrap and made the docs myself.
If it's truly OSS what's there to prevent someone from simply forking it to make a version where the manifest file is distributed freely (in both senses of the word)?
What is the incentive for someone to pay to access the manifest file and then maintain a free fork that includes it?
How does it distribute fairly based on contribution? If you just go off number of lines added/deleted that's going to cause major issues. Maintainers will be less likely to accept PR's as it will dilute their cut. Not to mention, not every contribution is equal in effort. If I submit a bunch of readme changes or add type defs should that count the same building out some new & complex feature?
I had to check that today is not April 1st. If you badly want my money, sell me your product honestly, under a commercial license, and don't call it OSS. There are other "source available" licenses. If you want a donation from me, show your tipping jar / patreon / whatever else link. If you want your software be OSS, well, don't conceal the source. I suppose that a project of any significance that would use such a "p…
The problem with non-permissive licensing is that a lot of employment contracts strictly forbid them. That and commercially licensed OSS projects have no way to distribute funds to arbitrary contributors in a legally straightforward way. And I personally have not had any success with donations, whereas 2 days after setting up my project with GitRoyalty me and my contributors are making $10/month.
If it's truly OSS what's there to prevent someone from simply forking it to make a version where the manifest file is distributed freely (in both senses of the word)?
What is the incentive for someone to pay to access the manifest file and then maintain a free fork that includes it?
How does it distribute fairly based on contribution? If you just go off number of lines added/deleted that's going to cause major issues. Maintainers will be less likely to accept PR's as it will dilute their cut. Not to mention, not every contribution is equal in effort. If I submit a bunch of readme changes or add type defs should that count the same building out some new & complex feature?
This is a tough problem and something we're actively working on improving. I'm currently talking to the owner of SourceCred to see how we can use their protocol: https://sourcecred.io/
1. Rewards bigger, more verbose contributions 2. Punishes maintainers for accepting contributions
Contributors will optimise for the largest impact and core maintainers will end up spending most their time trying to reduce that impact.
> GitRoyalty looks at a repository's contributions history and determines each contributor's relative work on the project based on various factors. Even if a developer only made a contribution that we've deemed to be worth 0.001% of the total contributions, that user will get 0.001% of all subscription proceeds. Project maintainers cannot control who gets what share, so developers can rest assured knowing that they w…