
GitRoyalty – First OSS Paywall - feross
https://gitroyalty.com/
======
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://<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](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](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.

~~~
joepie91_
> * 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

No, those aren't "the best parts of open source". The best part of open-source
is building a collective public commons, which this model does not allow for.

~~~
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.

------
elcritch
Not sure hiding/removing the project build or manifest is the best approach.
Documentation seems like it’d be a better target. Use the software free full
OSS but non-simple or extensive documentation for a subscription fee. It seems
a number of OSS devs make money by writing books, and it could incentivize
good documentation as well. There’s been many times I’d not want to pay for a
license but would’ve begged for in depth documentation.

~~~
sdrzn
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.

~~~
Gys
Accessing the documentation is more like a one time thing. I could always copy
it somewhere else for later reference.

~~~
antpls
Like any file that you would hide with GitRoyalty, you could always share the
full repo once you have access to it (probably illegally)

I believe documentation would become outdated sooner than build scripts with
new releases, and would require effort to maintain (more than build scripts),
which would better justify to pay.

Anyway, the idea of GitRoyalty seems not to make technically impossible to
share the payed content, but rather to propose a way for honest people to
remunerate honest developers and library maintainers.

------
freedomben
I very much sympathize with the goals here (I'm deeply concerned about open
source sustainability), but this doesn't strike me as a good solution. Not a
single company I have worked for would allow a dependency like this in their
repo (and I wouldn't blame them). Not only is it legally gray, but somebody
has to maintain that subscription. We do buy licenses but only for
big/important stuff. Something like this could work for a project of
sufficient magnitude, but I don't think it will for smaller stuff.

~~~
sdrzn
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).

~~~
latchkey
Have you ever dealt with the purchasing department at a large corporation?
Hint: They really don't care about saving engineering hours.

------
rgbrgb
> 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 will get paid what they are
> owed, no matter how small their contribution.

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...](https://gitroyalty.com/docs/faq/how-do-open-source-developers-
get-paid#earnings-split)

~~~
sdrzn
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/](https://sourcecred.io/)

~~~
rgbrgb
ah . sourcecred looks cool, but the current solution sounds a bit like
counting klocs.

congrats on the launch though, i'm really excited about incentivized
cooperation without dedicated managers!

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

~~~
sdrzn
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](https://gitroyalty.com/docs/faq/how-do-subscriptions-work)

------
ryukafalz
From their ToS:

>In addition, Content found on or through this Service are the property of
GitRoyalty, Inc. or used with permission. You may not distribute, modify,
transmit, reuse, download, repost, copy, or use said Content, whether in whole
or in part, for commercial purposes or for personal gain, without express
advance written permission from us.

So anything obtained through this service is proprietary now. After reading
this, it's clear why this doesn't work with the GPL.

If software obtained through GitRoyalty remained free software, I honestly
might have been fine with it. But as is, no thanks.

~~~
sdrzn
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.

------
PudgePacket
"8 profitable repositories"

Profitable is a strong word for making 75 cents a month, which is the highest
of all the repositories.

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

~~~
PudgePacket
Oh, fair enough then. It seemed to line up with less than $8 total payout,
which itself I don't quite get because the minimum payout is $20..??

I took it as the equivalent of looking at a list of "Patreon" projects and the
total contributions they make, rather than a storefront with sticker prices.

------
cjonas
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?

~~~
sdrzn
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/](https://sourcecred.io/)

~~~
cjonas
Just seems like the incentive structure is a little bit misaligned with the
best interest of the project:

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.

~~~
sdrzn
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.

------
wilt
Isn't this going to get banned by npm like those ads did?

~~~
sdrzn
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.

~~~
imposterr
How do you stop someone from forking the project on GitHub, adding in a
manifest, and then pushing to a package repository like npm?

Is there a risk of popular projects that are distributed through GitRoyalty
having unofficial versions with malicious code on the package repositories,
similar to now typo-squatting works?

~~~
hnruss
There are a few reasons to not rely on unofficial forks. The chance of
malicious code is one. Also: unwanted changes, missing updates, maintenance
confusion...

These issues already exist in the world of open source, as you note, and the
only way that I know of to stop it would be to have a more restrictive license
(and to pursue any violations).

------
knolax
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)?

~~~
hnruss
What is the incentive for someone to pay to access the manifest file and then
maintain a free fork that includes it?

~~~
knolax
I feel like a manifest file is not that hard to write yourself. It's the same
incentive as any other FLOSS work.

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

~~~
sdrzn
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.

~~~
nine_k
This is indeed an interesting problem! It looks like a way to sell a
commercial license in effect, without selling it in any legal terms.

I wonder how funds acquired via GitRoyalty get distributed, from the legal
standpoint, and what makes such distribution different from distributing a
share from a sale of a commercial license.

------
aaronsnoswell
This is a very interesting idea and looks like a promising execution - I may
try this with one of my repos. I have a question: it seems the only license
options are IP-locked. What if a developer wants to issue non-IP locked
licenses to paying users? This is a feature I would consider enabling - is
that something you will support in the future?

------
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?

~~~
sdrzn
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...](https://gitroyalty.com/docs/faq/how-do-transitive-dependencies-
work)

------
pcr910303
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 the process of using GitRoyalty package as dependencies are too complex, I'm not sure if anyone would like an experience of searching (a git-committed) package-lock.json, changing all of the GitRoyalty package links, installing the packages, and removing the license keys when committing an updated package-lock.json. There should be a more straightforward way (preferably without any file changes, e.g. using environment variables) to install dependencies.

Also, I'm pretty impressed with the beautifully done website. May I ask what
the site/docs are made of?

~~~
sdrzn
> 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.

------
cjonas
Do contributors get a pass on the licensing fee?

