Various points around snap monetization

1

Hello,

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)
  • Ads
  • In App Purchases
  • Time ran per user
  • Donations
  • 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:

  1. 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
  2. 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.
  3. 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:

  1. 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).
  2. 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.
  3. Again, will be addressed with Federation. I personally would love GitHub login. Fast, simple, distro-neutral, not hard to obtain, ubiquitous.

Ads
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
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?

2

While I appreciate the discussion being kicked off here, can you please take care not to make sweeping statements of fact on behalf of the store, snapd or snapcraft teams. It would be better to discover the facts first from the teams involved, and then make a post about them, rather than stating as a fact with caveats such as “as far as I know”.

As we haven’t yet fully launched the snap purchasing system, some of what’s being worked on is not set in stone. So to claim that there is ‘no protection’ on an as-yet un-launched product feature is misleading.

“takes a 20-30% commission
 which goes to Ubuntu” is not something I think you can speak with authority on. While Canonical is the lead sponsor of the Ubuntu project, and there may well be paid apps in the store in the future. Those applications come with commercial arrangements between Canonical (the company) and the software publisher, not with Ubuntu as a project. Saying that the 20-30% (or whatever the amount is) “goes to Ubuntu” is misleading.

Note that in the External repositories thread you linked to the Ubuntu T&C when the snap store has their own T&C, which is linked from the bottom of every dashboard page. These documents have different wording. The snap store document should be taken as the T&C for the snap store, not the

image

The confusion between these two pages should be cleared up however.

The store team have done some work already to de-brand the snap store. You’ll notice it doesn’t show Ubuntu branding everywhere that it used to. We’ve still some way to go, and we appreciate people pointing out those places where we can improve.

Thanks again for raising these issues.

3 Likes
3

Thank you for continuing the de-branding effort. I was merely pointing out current information as I and (I believe) most of the community know, using the Terms and Conditions that I found, info that had previously been around online, et citera.

The line “takes a 20-30% commission” came from the Ubuntu TOC. Due to the confusion between stores, it was not clear (to me at least) whether the Ubuntu terms applied. I understand know, and the old Ubuntu Developer TOC should probably be deleted or archived.

There are several other things that need changing:

  • The Ubuntu SSO to “snapcraft” login or something similar
  • Tutorials on how to use Snap are on tutorials.ubuntu.com
  • Various images use Ubuntu color scheme

Those applications come with commercial arrangements between Canonical (the company) and the software publisher, not with Ubuntu as a project. Saying that the 20-30% (or whatever the amount is) “goes to Ubuntu” is misleading.

Would be “goes to Canonical, which funds Ubuntu” be more accurate? The idea of a commission which goes to Canonical could really make distributions uncomfortable
 However, if this is addressed with Federation in a fair, distro-neutral way, then this isn’t really a problem.

Also, commercial arrangements? If buying snaps comes, there should be a way for developers to assign a price without a commercial arrangement. This may seem obvious to you, just pointing it out.

I would like to hear what the Snap team thinks of these monetization ideas when you can, because the actual ideas in my post were not mentioned in your reply (despite, you might want to talk to others on your team first).

4

No, I think “goes to Canonical, which funds Ubuntu” is needlessly specific. It would likely be more accurate to say that funds raised via the snap store will help fund continued development of the infrastructure, tools and services around snaps. Saying it funds Ubuntu is just using the fact that Canonical sponsors Ubuntu as a stick to beat the snap store with IMO. Canonical funds way more projects than just Ubuntu, so calling it out isn’t accurate.

Currently, if you put a paid app in the store, you’re explicitly entering into a commercial agreement with Canonical. As per the T&C, Canonical will (in the future) take the payments, and do whatever revenue split has been decided, passing on the publisher portion as necessary. That’s a commercial arrangement.

I didn’t address the entire mail because it was gone midnight on a weekend when I replied. :wink:

I just wanted to clarify that I didn’t think your initial assertions were fair. I won’t speak to the other things because I don’t know what the impact would be on other teams.

However, in my personal opinion while I’d love to see IAP, crypto-currency support, pay-what-you-want and/or ad-hoc contributions, all these things come at a cost. The snap and snap store developers would need to work on those things, and none are trivial to implement properly. They’d likely need significant development effort, review, QA and legal oversight.

2 Likes
5

This is entirely correct. Today, purchasing of Snaps is not supported although we are working on adding one-off payments and that will land sometime before 18.04 is released. Any more complicated purchasing methods such as all of the above are great but need to be explored further before the Store team would commit to delivering them and at the moment they are fully loaded bringing other great features to the platform. So while the discussion is encouraged for the benefit of soliciting demand for any future roadmap features lets phrase it just like that to avoid any confusion.

6

@G.S.1 It’s difficult to have a productive conversation when there are so many topics being talked about at once. DRM, ads, margins, in-app purchases, donations, cross-distribution concerns
 I just cannot do justice to any one of those topics when we’re covering it all.

With that in mind, let me try to help by providing the general feeling that is part of all of our conversations: it’s only reasonable that people making and distributing software get properly paid for it so that they can do more of it. That includes both the application developers and the distributions that enable end users to have a platform on which applications can run on.

So far our focus has been on creating the motivation for everybody to get together behind a modern packaging system based on its merits. But we understand that it is in everyone’s interests that such a platform should allow users to provide that kind of direct monetary incentive. We will be working on that and we will gladly share the platform’s success with those involved in making it so.

1 Like
7

Hi,

The tutorials branding will be addressed in #233. Can you file GitHub issues for the images you see that use the Ubuntu colour scheme here?

Thank you

1 Like
8

Would you like it if I split everything into seperate topics?

Agreed. I am just thinking in the future here.

Done.

I didn’t know snap buy can’t do anything yet. I thought it was implemented. What does it do right now then? The Store people are busy with amazing things, for sure. I was and am trying to start a conversation to understand what they will probably think / do when the time comes to add these features.

9

The only sane way to have a productive conversation is to discuss independent subjects on their own thread. Otherwise you’ll find various people responding to small and different portions of your points, and they are all on topic. Soon nobody knows what’s being discussed anymore, and we go back home empty-handed.

That doesn’t mean it’s a good idea to create 10 different topics on 10 different subjects at once, though. People will struggle to keep up, and you’ll get responses of lesser quality than they might have been otherwise.

It is implemented client side, and it’s half implemented server side. We just deprioritized it while we worked on more interesting aspects of the platform. We also have some interesting preliminary designs for entitlements, which may lead to in-app purchases at some point.

10

There are 6 topics here, not 10, which is a bit more reasonable. However, I am not sure about the economics of #4, so that can wait. Leaving 5 topics. I will consider a split.

I would deprioritize it from all the interesting stuff on the roadmap too. Entitlements, care to give out some ideas on how that works? (How about on a separate thread)

Actually, that is what I will do. I will create a thread for each of the topics, but only one at a time. Then, when a suitable answer / a decent discussion has occured, then the next one. In a series.

1 Like
11

First in the series:

12

Currently, there are several methods developers monetize their apps, and paid apps are one of them.

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, and paid apps are one of those methods.

Currently, snap supports snap buy command for monetizing apps, however the server-side has not been implemented yet for this. There are several issues with this though that I believe need to be addressed with this, or they (at least) have not been talked about yet. Namely:

  • snap buy offers no protection to prevent a user from copying a snap and sending it to a friend, without permission (does it?)
  • Will Snap take commissions? If so, where do they go?
  • Bitcoin/Ethereum?

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

  • Where does the commission go? All commissions should clearly go to improving Snap, and nowhere else. Is there a clear way to get this point across / prove commissions are going where they should go?

  • Could Snap theoretically support Bitcoin/Ethereum payments?

I know that the Snap community has not written or is ready to write the source code for buying Snaps yet. However, there is no harm in planning or thinking about it.

13

Again, the Terms & Conditions don’t state 20-30% anywhere. You’re likely looking at the wrong document.

Canonical is a privately held company with numerous revenue streams, as you’d expect. Like most well run private companies we don’t generally have a policy to enable random people on the internet to dictate internal revenue allocation. :wink: I know of no other privately (or indeed publicly) held companies which do that. While it’s possible that Canonical may ring-fence revenue generated from one product towards financing that department’s activities, I don’t believe that’s something we’d get into publicly.

Sure, it’s simply a matter of programming (QA, testing, legal review etc).

14

Woops! I initially posted this in a separate topic, where it turns out there are an old and a new Terms of Use floating around, the old one on Ubuntu.com, the new one on Snapcraft. My bad for putting it in again by mistake. Edited.

Of course. What I meant by this was to show to the community that if Snap takes commissions, Canonical isn’t going to funnel them to Ubuntu (making Snap payments benefit Ubuntu instead of being distro-neutral). I just mean, it would be a good idea to show that funds are going to Snap (or at least, say that somewhere) and not favoring one distro over another. Again, if Snap takes commissions.

Finally, my thoughts on a non-invasive DRM
 do you think this is a good idea, or should it be stronger/weaker?

15

To understand where you are coming from - have you ever shipped software for sale like your life depended on it?

16

Actually no. I am more “hobbyist” right now, but that will change


However, I have sold a few programs I have worked on. I will say that.

@niemeyer I split the topic because I thought making multiple topics would be better. However, if you want it to be on one, OK then.

17

@G.S.1 Sorry, but I’ve moved the conversation back here. It sounds like it’s almost a copy of the original post above, still covering DRM, comissions, buying, etc. So no need for a new post.

18

Entitlements may allow advising the snap about the status of payments, whether that’s for the whole snap or for more specific entitlements that the snap publisher defined. We still need to finish the design and work on details about that, though.

The Snap Store will have a shared revenue model as usual on that kind of platform. What each party does with their own percentage is not the Store’s responsibility to arbitrate.

Yes, in theory that’s certainly possible.

19

It was, but I set the topic for “Paid Purchase (buy)” and removed Ads / IAPs / Donations / Variable ideas. Still a little broad, perhaps, though.

Like there are add-ons to Snaps? Or is this similar to In-App-Purchase?

I was asking if the Store has plans to take commissions. It will, you just said (shared revenue model). “What each party does with their own percentage is not the Store’s responsibility to arbitrate.” - Yes, absolutely. I just want to ensure (to other distributions and myself) that this percentage/split will go to Snap development/hosting and not toward, say, Ubuntu Desktop refinements.

20

We’re still working on the details, but my own goal is to have a mechanism that is general and doesn’t force the snap to use it one way or the other. The tooling will handle the boring mechanics and the snap may decide how to use them.

That’s what I’ve tried to answer: it does not make any sense to prescribe what each party does with their own money (yours, Canonical’s, or anyone else’s). We’ve never (ever!) talked about that. That said, quite obviously the primary goal for this feature is to support the project itself.