GitRoyalty – First OSS Paywall | Hacker News Reader

GitRoyalty – First OSS Paywall

gitroyalty.com

41 pointsfeross50 comments

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.

I think this isn't very open, and it would be nice for you to invent a different name than OSS to describe it.

As for barriers to subscribe, are you sure it's low? What do companies think of this? Aren't they going to treat this exactly the same as proprietary software? With full pre-qualification of the vendor?

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

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.

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.

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.

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

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.

I love this idea.

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.

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

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

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

This opens the door for bad incentivization, I'd be afraid people optimize for what pays better, be it more small commits, fewer larger commits etc...

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/

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!

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.

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

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.

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.

"8 profitable repositories"

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

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

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.

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/

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.

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.

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

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.

More thinking if you have to mess around with license files to get packages to work they will remove the package.

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?

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

social pressure?

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?

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

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.

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.

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.

What is the difference between your open source repository and this one. I am assuming that the model is having 2 repos one open source and the other with gitroyalty with something extra (edit I see it uses sub modules)

> If you want your software be OSS, well, don't conceal the source.

That's what struck me as odd too. #2 of the OSI "Open Source Definition" seems useful.

    The program must include source code, and must allow 
    distribution in source code as well as compiled form. 
    Where some form of a product is not distributed with 
    source code, there must be a well-publicized means of 
    obtaining the source code for no more than a reasonable 
    reproduction cost, preferably downloading via the 
    Internet without charge. The source code must be the 
    preferred form in which a programmer would modify the 
    program. Deliberately obfuscated source code is not 
    allowed. Intermediate forms such as the output of a 
    preprocessor or translator are not allowed.

So charging for a reasonable reproduction fee is fine, but a subscription would seem to violate the spirit of this, since the subscription isn't being paid to github for their cost of reproduction. AFAICT, the fee is paid to the developers, not to anyone that does any actual reproduction.

Charging money for OSS is perfectly kosher under FOSS definition.

FLOSS doesn't require that you give your software away for free. It's totally fine to require payment.

(Now, the traditional 'sell copies of software' doesn't work so well for FLOSS, since every customer of yours can start selling it themselves, or give it away to anyone, which is why this approach is rare. But it's still FLOSS)

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?

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.

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

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?

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

Do contributors get a pass on the licensing fee?

Reply on news.ycombinator.com