Paywalls on software repositories

[freakboy3742]

Python has PyPI; other languages have analogous repositories of software.

However, that software is all free to use. There's no way to charge for access.

Adding a way to "license" access to content on PyPI - either by pay per download, monthly subscription initiated as soon as you download, Pay per version, or some other model,

The key is to make it as easy as possible to possible to collect small amounts of money each time a piece of software is used, and turn that into a bill that companies using open source can roll into their budgets.

Wordpress is a good model of a community that does this well.

[buddylindsey]

I have been thinking about this off and on since @freakboy3742 did a talk on it a djangocon. Of all the ideas I like this one the best. It allows for entrepreneurs to really dig in and create great products/libraries, and be paid for their work.

Something most good software devs like to do is, write software. We do it for free because we are passionate about it, but most of us would love to be paid for it, even if just a little. I think taking this approach is good, but I see it being more of a wordpress model. Let me articulate why, and some of how I think it could work in the python community.

One of the things that makes wordpress successful is how easy it is to install, and install plugins. As much as I like django alternatives if I need a blog or super quick site I turn to wordpress because it is so easy. One of the successes inside of that is the plugin ecosystem.

The great thing is you can browse many plugins either through their plugin site or through the wordpress admin. However, you can also just google for tons of plugins. Because you can either install through the admin portal or upload new plugins then that opens the gate for premium wordpress plugins. Once this was figured out the flood gates of new projects opened up.

A lot of developers that had ideas could write a plugin nights and weekends and get paid for them. After a while they got paid enough to quit their day job and work full time on the plugin. This means better support for bugs, and better code as devs are spending more time on the plugins.

The great thing about the plugin architecture is that when you install a plugin it tells you when a new version is available for you to upgrade. So you can click a single button to go from version 2.1 to 2.2. If it is a premium plugin and depending on how the dev built the project they would show you a link to 'Upgrade Now to 3.0'. You click that link buy the new version and download the new one. Or go back to your plugin page in the wordpress admin and click upgrade to get version 3.0. This keeps it super simple for users and limits the number of purchasing steps for users increasing sales.

I see this as something that could really benefit the rest of the OSS world as a whole, but sticking with just python community. I see a couple of different models that could tie closely to the wordpress model, and allows for people to more easily sell their projects.

I think if there was a library that allows people to setup their own PyPI you can host one as a parent company that would act as an Package Store where if you didn't want to host your own PyPI you just register your project with this Package Store pro.pypi.com. There you can go through a showcase of projects and choose the ones you want. You add them to your cart, and simply purchase them.

Once purchased you are given details in your account section of how to get the code either via direct downloads, or given a string to put in your requirements.txt file. The requirements.txt file line would need some sort of UUID to register the project, version, and you all together. Now when you do what ever you need it will install the proper package anywhere. And you will always have access to that version you purchased. From there you can handle new version releases in many different ways.

Having the Package Store and hosting it as a central spot you can have a 5% per sale fee to it to help pay for it. This would be great for people that want to release projects, but don't want to go through the hassle of hosting their own ProPyPI.

The next step is to allow people to host their own ProPyPI easily. That way they can retain all the revenue from selling their product, but it costs them in other areas like hosting, customer support, bandwidth, payment gateway, etc. People can either implement their own or someone could sell ProPyPI package for $200. Great thing there is the ecosystem is already starting to work for itself. This would take ProPyPI development really far eventually making it super easy for people to use once they pay for it. One of the complicated things about FOSS is some libraries/packages are hard even for smart devs.

With all that said I think this is a great approach for getting budding entrepreneur developers out there to start writing code for projects they always wanted to write, but never did because their job paid them to write code for them. It would also get higher quality projects to emerge and stick around longer reducing burn out. If the project got big enough the developer could go full time making it, and even higher other developers.

There are many challenges to this. One of them is how does it help existing large projects. That one is a hard problem to tackle. One possibility is to offer premium version of existing software. There are a lot altruistic developers that will purchase the library knowing it will continue to help development move forward. An example is offer django on a ProPyPI and and on PyPI any purchases would go directly to the DSF for what they need, hopefully for more fellows.

Anyone else have thoughts?

[jerel]

I think there are a couple big issues with this approach: it's developers like you and I that discover software, experiment with it, recommend it to corporations, and contribute bug reports and patches back. I'm not interested in the friction of paying a fee every time I pip install, juggling license keys, etc. It seems like the free-as-in-speech ecosystem is hard to grow without first having free-as-in-beer.

However the bigger issue I see is that a developer working on a bootstrapped business should get a free pass (they should discover bugs and contribute patches) or pay a few dollars while an enterprise who only consumes software should be paying in the thousands.

A few months ago I watched a demo of some closed source enterprise software that cost $100k+ and the web component of it only ran in IE (with ActiveX). Enterprises have the money to spend but they need to be invoiced for it. Patrick McKenzie talks about this occasionally: https://twitter.com/patio11/status/563237491939885056

[jayfk]

The WordPress plugin eco system is more or less a PyPi with an interface in your WordPress installation. There is absolutely nothing that supports you as a dev to make money with the plugin you offer there.

I have a WordPress plugin available that comes with a monthly subscription and I'd argue that the only reason you can make money with WordPress is the fact that it has a ton of users. If you want to be listed on the plugin directory your plugin has to be free, otherwise the plugin won't get accepted. You have to come up with a split model that gives some features away for free and some in a pro version that you can unlock with a license or whatever. You basically have to write your own payment processing and bring your own infrastructure that supports this to actually make some money.

I don't want to go into too much detail here, but just because some people make money with WordPress don't mean that the underlying system is the reason for that. Not to mention the fact that you have to use SVN to use it :)

Apples App Store is a good example for a working eco system that supports developers with payment processing and even with infrastructure like iCloud. Sure, it comes with it's own problems but in overall it's okay.

[freakboy3742]

@jerel Agreed that there's gold in them there enterprise hills, and most enterprise software doesn't win because it's good - it wins because they have great sales departments, and they have those because they charge millions for a license... and so the cycle continues.

They key is how to structure an invoice so that an Enterprise will pay it. Is it literally as simple as selling a "ProjectX Pro" license for $$$, where "ProjectX Pro" is just "ProjectX", but with a price tag? (Refs #12)

Regarding the try-before-you-buy aspect of open source - agreed that this is something that needs to be managed. "First month free" subscriptions, might be one way to do this. Another would be to have the process be entirely optional - but make sure that there are good guidelines in place for what you "should" be paying - say, a wizard that takes number of employees, revenue, profit etc and computes a magic "monthly subscription" value, and then sends you an invoice for that amount. The funds would then be distributed between the projects you actually use each month.

[freakboy3742]

@jayfk I'm not intimately familiar with how the Wordpress ecosystem works, so I won't defend it as a specific implementation. I was more pointing at the fact that there are tutorials etc out there on how to make a living selling WordPress plugins - so there's both a community expectation that some things cost money, and there's a set of mechanisms in place to manage taking that money (although based on what you're saying, that process might not be as smooth as I thought it was).

[jayfk]

@freakboy3742 The point about community expectation is a good one. For paid plugins the term premium is pretty established which tells a lot in this context. The expectation that good things cost money is very well established there. I believe the main reason for this is the userbase. When I take a look at some the comments about @ipmb's High Performance Django at reddit, or the harrassment @audreyr and @pydanny received for Two Scoops of Django we're not quite there yet as a community.

[nanuxbe]

Seeing the same issues as @jerel I am not sure this, in this form, is a good idea.

People in the python community have been waiting long enough for a working packaging tool (although some may argue it is still not perfect). With tools like npm, bower, ruby gem and php composer, if I have to pay for using pypi, why wouldn't I switch to/learn another language instead?

I also believe that: a) the people doing the most pip installs are people not getting paid for it:

• people learning: when you're learning it's easy to have to rebuild your venv 10 times because you messed domething up
• people creating other open-source libraries and testing them: every time you test your python library with travis- or gitlab-ci it pip installs all your dependencies
• people maintaining an existing application in a large company don't pip install much, they often don't even upgrade dependencies unless they really have to and they use other CI software like jenkins where they can build upon an existing environment b) the companies with the most money to spend usually don't like to rely on the internet and even have lots of servers without internet access and therefore don't use pip install as often c) those companies often have some closed-source internal packages and therefore use an internal pypi server (like devpi) and therefore would avoid the cost of pip installing most things

Going further with point c), npm offer a dedicated enterprise version of its service. IMHO if pypi would need to become a paying service, this is most probably the kind of service it should use to get paid rather than in the pocket of students/"regular" people/non-profits/small businesses.

[buddylindsey]

@nanuxbe In my proposed solution for this I actually solve that issue you buy it once and it doesn't matter how many times you install it because it is based on the string in your requirements.txt file to authorize it. There could be other solutions besides a custom string in requirements.txt, but that is a quick temporary solution.

Also you can still release stuff as OSS for people to find and try, but when you are ready to go to production you use the pay for version. Could be combined with a new FOSS license that says you can dev and learn, but when you push it out to a production environment which somehow makes you money you use a licensed version.

[buddylindsey]

@jerel juggling license keys, etc

One way to resolve that is to use a ProPyPI along with pip and when you request a package you have some sort of auth package with it to authorize you pip installing that version of package. If it fails then it errors out tells you why. Also tells you and links to an upgrade if a new version is up. I kind of talk about a ProPyPI in my reply above.

[nanuxbe]

@buddylindsey not sure it's doable if people can still download the package freely as long as it's for dev/learn. As far as I'm aware, the only way to enforce GPL at the moment is either go to trial yourself or donate your code to the FSF so that they can start legal actions regarding an infringement.

So basically, anyone would be able to use my "small open-source package" for free while the only packages which would actually be able to have this respected are projects backed by large companies which already make a lot of money?

[freakboy3742]

One suggestion that has been made to me is to tackle this, not at the PyPI side, but the pip side. So, as an organization, I can choose to use "pip pro"; this is a fork of pip that does exactly the same thing as pip, but it keeps a log of what packages I use, and reports that usage.

Pip Pro is managed by a third party organization who keeps the logs, and does monthly billing based on usage numbers (and maybe some demographics - how big is your company? What's your annual profit? Your monthly license fee for the Python community is X).

The Pip Pro organization sends invoices for these license fees, and distributes the funds to projects that nominate that they can accept them (something that could be added to setup.py metadata).

So - it's opt in, and provides a way for an organization to factor in their open source usage. The same organization could offer npm pro, gem pro, and so on, and be a single hub for redistributing funds.

The question - how to encourage people to use the "pro" version, other than altruism?

[nanuxbe]

As you can see in #17 there are people who are willing to donate. NPM Pro is already a thing btw (with a slightly different approach):

• https://www.npmjs.com/private-modules
• https://www.npmjs.com/onsite

[beltiras]

Here's a refinement of the idea. How many would donate 10$ per months divvied up by your pip usage, Spotify style?

[tomchristie]

Funding at the point of PyPI makes a lot of sense to me. I don't think that downloads/month are a good metric to use tho, rather have devs who want to issue a fee set a monthly cost to allow use of their packages.

And yes there'd need to be a 'free for personal use' and a 'paid for organizations' style.

[beltiras]

"allow use" is antithetical to OSS. The whole endeavor is based on freedom and the solution to the money problems has to be based on voluntary donations. I think downloads is also the wrong metric to set.

I'd like a service accepting monthly donation, I install a cron job which inspects my virtual environments then divvies up the allotment. That way I could devote different percentage according to how much I value each system (and/or production/development).

As contractors and employees it would be our duty to push our companies to put money into this system. As a maintainer of an OSS you would register with the service and be able to see the upside of taking the funds before taking the plunge. The service could even put your allotment into escrow for some period of time while you contemplate if you should make the switch (say 3 months or so). If you don't, funds get distributed to the projects that would have gotten the funds.

[beltiras]

My example of a 10$ donation is just based on where I was coming from: Thinking about Spotify and PyPI. I'm thinking that big companies would see benefit in a bigger donation (tax-deductions).

[tomchristie]

I think downloads is also the wrong metric to set.

Agree.

I'd like a service accepting monthly donation

I think 'donation' is likely to produce the wrong effect. I believe we should be talking and thinking about paid products, and that it's more a case of framing the tiers so that there is typically a free tier available for personal use, and charity/educational organizations.

Also probably that we should think of tiering more in terms of 'seats' rather than is the organization profitable. (Plenty of well-invested startups, that oughta pay their way but may not be profitable.)

[beltiras]

While I agree that this is a business model that makes sense in many situations, I categorically disagree with taking OSS in that direction. We don't build products. We build components that can be made into products. Plenty of money is being made from the components. All we need to do is educate the stakeholders.

[cjrh]

Spotify is a great example, with the caveat that I would prefer to choose among which projects my monthly subscription gets divvied, rather than allocations being made automatically in the background, using downloads or some other similar load metric.

All we need to do is educate the stakeholders.

I think the stakeholders already know all this.

[pydanny]

I agree with @tomchristie about download count should not determine the intrinsic value of how much a package is worth. It's terribly inaccurate, especially in this day of automated deployments.

For example, Cookiecutter has about 400 downloads per day. Seem low, right? However, unlike deployed packages like Django, Django-Rest-Framework, and Requests, which are deployed en-masse by the cloud, Cookiecutter's download count is a near 1-1 relation between Developers. In other words, for every 400 downloads, we estimate about 350-400 Python coders installed it on their machine. :cookie:

Also, I know people write tools to bump up their download counts on PyPI because that serves as nice resume material. :disappointed:

[cjrh]

@pydanny My PyPI packages, for example misu have non-zero download counts (in this case 13 per day), but I'm pretty sure no real person is using them. I have no github issues, no pull requests and no traffic. I've just assumed these were automated downloads from some kind of indexing service or something. I suppose that in a subscription system the automatic downloads would stop. Do you know what fraction of your download count is real people currently? Just curious.

[tleeuwenburg]

I think companies would pay for an open source repository if the software that was on it was of higher standard for corporate needs. Examples would include code review, security review, uptime guarantee, security patch guarantee. That would be an easy sell.

[ghost]

Configurable Limitation of Bandwidth for specific packages on PyPI via payment with BitCoin/PayPal can be cool, with PIP integration, and third party PyPI mirrors doing the same via API, helps PyPI servers also.

Example:

• Free you get 10 Kb/Sec max download speed.
• Pay you get Unlimited Speed max download speed.