Speaker
Description
On OSS Funding
It's well known: OSS is underfunded. That has a lot of implications in several levels, which I won't discuss here. Just for the sake of completeness, I'm gonna point a few of them:
-
OSS maintainers need to eat. Since OSS doesn't usually let people make a living out of it, they end with other day jobs. That means OSS projects are always at risk of becoming unmaintained, and increases the bus factor of projects a lot.
-
While OSS maintainers aren't able to monetize their work, big companies usually do, which is at least problematic.
-
That also means the culture surrounding Linux is "everything is free", so it's less attractive to new developers which want make a living out of their programming. That means a smaller app ecosystem, with a lot of abandonware.
People are not money-grubbing
The truth is, people want to pay for things! And software is no exception: see how well the AppStore or Steam do in that regard, so what's the issue with OSS? Why people don't throw money at developers?
OSS is a model based in charity
Say donations, say charity. Even if factually donating $5 to SomeApp and buying that app for $5 is the same, psychologically those are two very different things
On the perceived value
We live in a capitalist world, and we cannot omit that in our analysis. In capitalism value and perceived value are by no means the same thing, and perceived value scales with the price point put to something, not by their inherent value. Even more important, the price point doesn't necessarily need to match the price the customer ends paying. That's why sales work as a commercial strategy: you put the value with the original price tag, and by making a sale you offer customers the idea that they may get the same value by paying less.
If OSS is offered without a price tag, people just will assume its value is lower than the same product with a price tag, even if you allow to not pay anything at the end.
More on that: even if we hope to value an app by their inherent interest, that valoration will never be accurate. Developers don't know how to predict how many hours of development a task will take, regular people even less. Since things Just Work TM is easy to assume that things were easy to develop. The strategy of putting an "hours invested in this" is widely used in web products, I think we can assume with some success.
Friction and expectations
Even if the user knows the value of the app they want to use, probably they won't donate to it a cent. This is due to two things: friction and expectations. I'll talk first about the latter.
While a donation-based model lowers the fear of loss you may have in a payment-based model, it ups user expectations a lot. Why is that? If we think about other donation-based models they're usually built around the idea of "we're doing a public good and we need your trust and money to keep doing it". Well, trust is a hard thing to give, and you usually want the money you donate to be well employed. Not only that: money given to donations usually is a low-priority, highly constrained part of your typical budget. If in the mental model of someone there is X money for groceries, Y money for non necessary things, and Z money for charity, you're directly competing for a quite constrained budget with some high moral non-profits. Not the best place to be for a text editor.
Then you have friction, and it affects both charity-based and payment-based models. It's easy: given two paths, people will always follow the one of least resistance. And friction plays a huge role on that. If it's easier to pirate than to pay $2, people will pirate.
It suffices to say that having a donation link inside an About dialog which opens a new window and then asks you to input your credit card, your PIN, then check your mobile to confirm the transaction... won't work. Is way easier to just keep using the application. If each time you want to buy an app in Software you need to do about the same, people will avoid selecting paid apps.
The path to a frictionless paid ecosystem
Say we implement payments on GNOME. That needs to be done on a Platform level, for several reasons:
- We need the payment system to be trustable
- We need it to be a fairly centralized system who offers an API to applications -> again, trust
- We need it to be frictionless: you put your payment data once, and after that if you want to make a payment you just press a button.
- We need to offer incentives for entering the payment data:
In all seriousness this could be a very interesting point for GNOME to offer some services (config backups, secure mail, cloud services for enabling apps to have cloud capabilities such as sync of data, who knows)
And on top of all of that, we need to put a price to our apps even if we go a pay-what-you-want route, and/or showcase how much work goes into making them.
