As part of the External Repositories discussion, I had an idea Snap has not implemented yet, which may be useful.
Currently, there are several methods developers monetize their apps:
- Paid purchase (buy)
- In App Purchases
- Time ran per user
- The Variable Paid purchase
I know that many of us here would greatly prefer having an Open-Source ecosystem, but the fact is that developers need to make money, somehow, to make quality apps that make the Snap Store beautiful. I would like to address each method and my thoughts for it.
Paid Purchase / Buy
Currently, snap supports snap buy command for monetizing apps. There are several issues with this though that I believe need to be addressed with this. Namely:
snap buy offers no protection (as far as I know) to prevent a user from copying a snap and sending it to a friend, without permission
- Every snap purchase, according to the developer Terms and Conditions for the snap store, takes a 20-30% commission… which goes to Ubuntu, which could harm the distribution-neutral aspect.
- Also harming the distribution-neutral aspect, you must make a Ubuntu Store account… and sign in with it.
My thoughts on each of these issues:
- DRM is a horrible thing, and it would seem hypocritical to support it in a FLOSS stack. However, without it, many developers may be reluctant to support Snap Store, or might raise the price to include potential illegal copying. My suggestion is that, rather than create a whole DRM-debacle, we make a pop up, similar to “This software was illegally copied. Though we won’t stop you, won’t you please just pay $2.99 (or so) for the whole app, legally?” Another improvement would be to say, “you must use the terminal to install this app without permission.” In other words, the GUI won’t help you cheat (it must be manual).
- I would argue that Ubuntu should have an equal ability to get paid for Snaps on commission as any other distribution. How this may be accomplished is of doubt, and will probably be addressed when Federation is. However, in the end, Ubuntu should be able to get commissions just as much, as, say, Fedora (running their own Snap Store), as a potential option. All I will say for certain here is that, to be truly distro-neutral, Ubuntu can’t take all the commissions.
- Again, will be addressed with Federation. I personally would love GitHub login. Fast, simple, distro-neutral, not hard to obtain, ubiquitous.
Advertising is the bane of any game, but it makes considerable money. You can currently embed ads through an iframe, or methods to that affect. My idea is that Snap should support an unobtrusive ads service. What do I mean by this? The Snap Store would run their own advertising service. Each ad must be non-political, non-offensive, and follow the unobtrusive advertising guidelines set up by AdBlock Plus. These ads would be non-invasive and allow developers to gain critical income. They would also not track users (even better).
Ideally, when Federation is addressed, each distribution could theoretically run their own ad servers, with varying rates. Each Snap install (included with the distro) would say which server to get ads from. If ads cannot be loaded, then use Google AdSense or something else.
In App Purchases
We all hate it when developers require a lot of money to buy invisible “coinage” in a game. However, In App Purchases are now in almost every game, and allow for things like “$2.99 - No Ads”. My idea is to allow Snap to use In App Purchases, but have restrictions on how they may be used to prevent them from being obtrusive. They (for example) would be:
- You may include up to 3 In-App-Purchases in your game. If you want more, the community must approve AND you must have an in-app-purchase to disable ads.
- No In-App-Purchase may cross $10.00 without community permission.
- You may not constantly nag the user for In-App-Purchases, or charge “by chapter.” If there is an IAP for moving forward, it must be an In-App-Purchase for all levels. You can’t charge, say, $1.00 per chapter. Exceptions from community.
All In-App-Purchases would be charged through a payment provider of choice, and would be shared among distributions, with each distribution co-coordinating with (some) custom policies. Again, to be addressed with Federation on how to be distro-neutral.
Time ran per user (Amazon Underground model)
If you are not aware, Amazon has a payment method where all In App Purchases are free, and there are no ads. Instead, the developer must provide unlimited IAPs and no Ads, in exchange for Amazon paying out $0.0006 per minute per user playing their game / app. So if 100 users played for 100 minutes, you get $6.
This doesn’t sound like much, but very, very few people convert to In App Purchase-buying customers, and ads detract from the experience tremendously (paying almost the same). Amazon does display one ad when the application loads, but that is it.
Honestly, I do not know how the economics for how this would work, but it would be an interesting monetization concept if it could be pulled off.
Donations should be easy to pull off, so there should be a Donation API. If the developer has no In App Purchases in a game, he can request a Donation pass. If approved, he can use a “Donation API”, which works just like an In App Purchase, but Ubuntu or other distributions would take no commission (only minimal processing fees).
The advantage of this is traditional donations would take the user filling out credit card info, etc. If it was simple as an IAP to donate, perhaps donations will go up.
Of course, traditional donations also work just as much as ever, it just won’t be nearly as convenient as “Donate $10.00? Yes/No.”
The variable purchase price (e.g. Elementary)
Elementary OS AppCenter has a novel concept: Instead of charging a fee for a download, the price button says $1.00, but the user can click a dropdown button next to it and change it to $0.00 (free) manually, or donate a higher amount. Ideally, this would also remind the user every week or so to donate (if the user likes the app). Would work like Donation API, but is actually at “get time”, rather than in the app.
Thoughts on these ideas?