Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitRoyalty – First OSS Paywall

gitroyalty.com

Post reply on HN
Print view View original

1–10 of 52 posts

Re: GitRoyalty – First OSS Paywall

#2

Post by sdrzn »

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://@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.

Re: GitRoyalty – First OSS Paywall

#3

Post by Null-Set »

Am I allowed to make a subscription url publically available? Say I write a package which has a paywalled package as a dependency. If I want to publish MY package freely on npm under an MIT license, can I pay the subscription fee and commit the resulting fetch-url with my license key into github, and transitivly allow users of my package to use the paywalled package?

Re: GitRoyalty – First OSS Paywall

#4

Post by krapht »

Null-Set wrote: post #3

Am I allowed to make a subscription url publically available? Say I write a package which has a paywalled package as a dependency. If I want to publish MY package freely on npm under an MIT license, can I pay the subscription fee and commit the resulting fetch-url with my license key into github, and transitivly allow users of my package to use the paywalled package?

I hope not. That would go against this project's purpose of trying to find a funding model for popular, transitively-used packages.

Re: GitRoyalty – First OSS Paywall

#5

Post by sdrzn »

Null-Set wrote: post #3

Am I allowed to make a subscription url publically available? Say I write a package which has a paywalled package as a dependency. If I want to publish MY package freely on npm under an MIT license, can I pay the subscription fee and commit the resulting fetch-url with my license key into github, and transitivly allow users of my package to use the paywalled package?

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

Re: GitRoyalty – First OSS Paywall

#6

Post by rjzzleep »

Maybe I'm wrong(I hope I'm missing something, if I do please elaborate), but given the unpredictable behavior of package managers caching behavior and general dynamic IPs the individual license is basically meaningless.

I can't even begin to imagine the headache and potential problems of having to deal with this. Isn't there a better way to handle supporting open source projects?

But other than that looks pretty with more or less clean execution.

Re: GitRoyalty – First OSS Paywall

#7

Post by sdrzn »

rjzzleep wrote: post #6

Maybe I'm wrong(I hope I'm missing something, if I do please elaborate), but given the unpredictable behavior of package managers caching behavior and general dynamic IPs the individual license is basically meaningless. I can't even begin to imagine the headache and potential problems of having to deal with this. Isn't there a better way to handle supporting open source projects? But other than that looks pretty with…

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

Re: GitRoyalty – First OSS Paywall

#8

Post by nine_k »

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 "paywall" will be plainly forked, with a build / manifest / whatever file maintained manually.

Re: GitRoyalty – First OSS Paywall

#9

Post by sdrzn »

nine_k wrote: post #8

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.

Post reply on HN