sdrzn

GitRoyalty works for transitive dependencies as well (dependencies of dependencies) by ensuring users are subscribed to all transitive dependencies before installing the direct dependency. So in this way this model not only still allows building a collective public project, but also compensates each developer that's involved in it.

You're absolutely right this should not be a clause in our ToS. I've just removed it and notified all repository owners of the change.

There was a misunderstanding of what 'Content' entailed on my part–it was meant to encompass anything without a license already attached in order to grant us rights to distribute unlicensed software. Our ToS should have been more specific, I apologize.

Very interesting thought–I'd love to see how this dynamic actually plays out. I personally would welcome more contributors v.s. doing their work myself.

I think if a project maintainer were to act maliciously in terms of earnings share, developers would call them out and less people would contribute as a result.

We measure contributions using a project's git history (i.e. # of commits) every time a release is published. I realize this is terrible and it's my #1 priority to improve this after we get some engineers on board. I'm currently talking to the owner of SourceCred to see how we can use their protocol: https://sourcecred.io/

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/

> rather have an own GitRoyalty account

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.

Great idea and you can do this with GitRoyalty! You can hide any files you want behind the subscription–it doesn't have to be the manifest or build script. So in your case you can hide a docs.md file.

I think companies will hop on board if it means saving engineering hours. OSS has monetary value to these businesses, enough to make a small subscription to support the tremendous development efforts behind it. In most projects, OSS makes up the majority of the codebase, so it is "big/important" IMO.

As for the legal aspect, permissive licensing like MIT/Apache 2.0 allows developers and consumers to distribute and use code pretty freely, which is what makes OSS so great and why GitRoyalty doesn't impose any other licensing.

One of the driving factors behind making GitRoyalty was the corporate mentality I've experienced where management will pay for whatever is necessary, but think twice before sponsoring anything (especially transitive projects).

GitRoyalty just hosts a git remote repository that you pay to get access to. NPM and almost all other package managers support installing from git URLs, and too many people rely on this functionality for it to ever be removed.

The purple dollar value on the Discover page shows the Individual price of the repository, not the total profits.

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.

We whitelist common dynamic IPs, for example CI, CD, and deployment IP address ranges including:

* AWS

* Heroku

* GitHub

* Circle CI

(this whitelist is a WIP and I'm open to adding more)

Also since the goal of rate limiting by IP is to limit # of users, not necessarily # of machines, we allow you to remove any previously used IP addresses from your subscription's history. This way if you hit your limit, just go to the payment page, hit 'Manage IPs' and remove any unused IPs.

See this doc for more details: https://gitroyalty.com/docs/faq/how-do-subscriptions-work

If the transitive project's owner agrees to letting anyone use your license key freely, we can certainly do this.

However I recommend setting up your own project on GitRoyalty since we automatically replace your license key with a bundle identifier (i.e. bundle:<repo>). This way, before users can download your project, we confirm their IP addresses are associated with active subscriptions to all your transitive dependencies.

I wrote a bit more about transitive dependencies here: https://gitroyalty.com/docs/faq/how-do-transitive-dependenci...

Thanks Feross!

GitRoyalty is an experiment that allows OSS project maintainers to hide a package’s manifest file (or build script) behind a monthly subscription. This way users will have to subscribe in order to install the package using dependency managers like NPM. The idea is that with low prices and the power of numbers, both popular and transitive OSS dependencies can sustain development instead of relying on a few enterprise sponsors that could influence the direction of the projects.

After setting up an Individual or Team subscription, users are given a license key which is used to install a package with their dependency manager:

  npm i git+https://<license>@gitroyalty.com/user/repo#semver:^2.0.1

* GitRoyalty works for projects with permissive licenses like MIT or Apache 2.0, but not copyleft licenses like GPL (which most companies like Microsoft avoid completely)

* While this isn’t FOSS, it keeps the best parts of open source in place (open GitHub collaboration, permissive licensing) while incentivizing users to pay contributors

* Although some wildly successful OSS projects can sustain from donations, only core contributors get paid anything, when in reality there are hundreds or thousands of other developers. GitRoyalty distributes subscription earnings to all developers based on their contributions.

* The barrier to subscribe and install a package is quite low, especially after adding a payment method once. Login with GitHub, hit Subscribe, install. All subscriptions come with a 2 week free trial and are charged in aggregate the 1st of every month to keep processing fees low. https://imgur.com/3WpwBUz

I just set up my own 2.6k star GitHub project with GitRoyalty and have 6 subscribers so far, for a total of ~$10/month for me and my contributors.

https://gitroyalty.com/saoudrizwan/Disk

I hope to get more subscribers as I release more updates to my project, since any previous versions before GitRoyalty will always be free (due to the fact that previous manifest/build scripts will be in git history).

Let me know what you think! I’d love for more people to try this out with even completely new projects so we can see if this experiment has potential. Obviously this won’t work for everyone but I hope it can be a solution for projects that desperately need funding and can’t find sponsors.

> without at minimum ponying up a credit card and signing up for a free trial

You're right, there's a bit more friction before you can install and use a project, but I think if a user gives enough value to a certain open source project then that friction shouldn't be enough to deter them from using it altogether.

It's also worth mentioning that once you input credit card information and connect your paypal account, you never have to do it again for future subscriptions. You just go to a payment page, hit 'Subscribe' and install the package, all in a matter of seconds.

Here's a bit more information about how subscriptions work: https://gitroyalty.com/docs/faq/how-do-subscriptions-work

Thank you ktpsns! You're exactly right, anyone can create free forks after accessing the complete repository once, but that becomes a security risk as new versions are released with bug fixes, security updates, etc.

I think paying a small subscription fee as little as $0.50/month for the convenience of not having to make free forks over and over again is worth it, especially for tech businesses that can usually afford it.