
GitRoyalty–The First Open Source Paywall - dubcanada
https://medium.com/@sdrzn/introducing-gitroyalty-the-first-oss-paywall-42833efa0d42
======
ktpsns
Interesting decision -- make users to pay for the configuration scripts so
their language ecosystem installer works. Basically they pay for their
laziness of setting up such a file on their own.

I like the honesty that "pirating" projects is really easy and not even tried
to deny.

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

~~~
ktpsns
Oh, that was not even my point. You are talking about the possibility of
passing data _after_ having paid. I think there is no way to prevent people
from doing so -- the industry has decades of years experience with pirated
licensed software. So you better don't waste your time for implementing
"preventing forks" on your platform --- if I pay on your platform for getting
access to a repo which I can clone on my computer, I will push my copy to some
other remote, of course.

------
witten
While this is pretty ingenious, and "solving" open source funding is a noble
goal, there's a pretty practical impediment to GitRoyalty working in the real
world: For new or existing projects, a big draw of open source is the on-
boarding process.. You can download, install, and start playing with a library
or application to see if it meets your needs with almost zero friction. And
that's a big part of the selection process for any new project.

But with GitRoyalty, you can't even install the software to see if you want to
use it or take a dependency on it.. without at minimum ponying up a credit
card and signing up for a free trial.

My take is that this roadblock will turn away new users in sufficient numbers
that it'll hurt projects with this paywall in place. Users will leave in
droves for competing projects with less install friction. Not because they
don't believe in paying, but because they don't know if they want to pay
_yet_.

The projects that can afford to turn away users like this are the well-known
ones with big-name maintainers, corporate sponsors, and thousands of GitHub
stars. But these also happen to be the projects least in need of funding.

As difficult as it is to implement, a better place for a paywall would be
after the user has installed the software, evaluated it, and decided to roll
it out in production. That would bring the payment closer to the point of
value, and also keep the on-boarding friction nice and low.

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

~~~
witten
Yup, totally understood about the second subscription. The challenge is
getting that first subscription though, when a particular user hasn't yet
signed up for (or even heard of) the service. At that point, it's a fair
amount of friction from where I'm sitting.

