Paid features in opensource apps

@uniqx just made a point to me that I hadn’t fully considered before. Payment requirements can be undemocratic if they are too high. But of course there is a big grey area there, since basically everyone in the world could afford 1 Euro a year to use software. F-Droid has not limited itself only to the ethics of Free Software. We mark tracking and advertising, both which are 100% compatible with Free Software. So to me, the original, overarching idea that started this thread is still an open question: should apps requiring payment be marked?

  • If an app is 100% free software, then anyone who objects to the payment requirement can fork it and remove that.
  • Would we mark apps that required users to click through a payment prompt, even if it allowed the user to enter 0?
  • How about if it required them to pay $0.01 in a fully anonymous, free software method?

If there a clear line somewhere to draw? I think it is also important that F-Droid is not anti-commercial, since developers will write better software if they can make a living doing it. So it is hazardous to mark all attempts to make a living from free software as an Anti-Feature.

I still think F-Droid should require all users to click through a payment prompt, with a default value set by the developer, and the option to set it to 0.

2 Likes

Listing whether an App contains paid features is certainly useful information for users. So I’d actually be happy to have this listed. But if we do so, we definitely should not do so as an Anti-Feature. There is no harm for users financially supporting App developers.

Having a note like “contains paid features” well separated from our Anti-Features is totally fine for me.

Here’s an edge case that peeked my interest: Conversations is free to use XMPP App, but it helps users signing up with the developers XMPP servers for a little subscription fee to sustains continued development. Is this what you would label as paid feature? I wouldn’t because all features of the App are totally working without ever paying anything to the developers.

2 Likes

EteSync was mentioned above, I wanted to add that note… given that Fastlane is used… I’d have to PR upstream directly… let’s see how that goes. :wink:

1 Like

Just dropping my $0.02 as a long time open source developer/maintainer, user of f-droid, and creator of an app that would be affected by this change (EteSync).

I’m not familiar with the original app that triggered this discussion, so I’ll just focus on the proposal regarding paid features in open source apps.
FLOSS is about user freedom, not costs as illustrated by the famous Stallman saying: “Think free as in free speech, not free beer”. Following that line of thought, any app on F-Droid that is not fully open source, that is, restricts your user freedoms should be marked as such, and guess what? They already are. It’s the class of “Non free X” anti-features.

A good example of this is Telegram: it’s non-free when in comes to libre (server is closed-source and network doesn’t support federation) but it is free when it comes to gratis. Is this any different to a competitor that would charge you $1? $0.01? Not in the context of F-Droid, because again, F-Droid is about FOSS, not about money. Both cases are equally bad.

Two good examples from the opposite point of view (and I’m sure there are many) are Conversations (as mentioned by @uniqx) and my very own EteSync. EteSync is completely FLOSS. Client and server. You can host your own and I actively help and encourage users to do so. Conversations is a free XMPP client that you can use with whatever server you want for free and no restrictions, but you can also use the XMPP server maintained by its creator.
In both cases the extra services provide additional value to users without restricting any of their freedoms. It’s a bit ridiculous to mark EteSync or Conversations with anti-features because they are trying to offer services that make it easier for users.
Also, in the case of EteSync, the “official” hosting is the only one available for public registration (that I’m aware of). How should we mark EteSync the app if it’s removed and another person, not associated with the project offers paid hosting, should the anti-feature be there?

On a personal note, I we should encourage the sustainability of open source software, not discourage it. The offering paid enterprise support (like in the case of Red Hat) or offering paid-hosting in addition to supporting self-hosting are great ways to do that. Let’s not ruin it with scaring users away or considering them as anti-features.

6 Likes

I think this is an unfair statement. You don’t have to give away money. You are more than welcome to self-host. You are only required to pay if you are using the hosted service where I’m paying for your bandwidth, data, maintenance and support.

So no, EteSync doesn’t only work with money. It’s fully FLOSS. Client and server.

Furthermore, the information about EteSync costing money when using the hosted version is clearly visible in registration process, and is also mentioned in the app description. See my other comment though, FLOSS is not about money, it’s about respecting user freedom.

Disclaimer: I’m the creator of EteSync.

4 Likes

I respect RedHat and its great to see how they built a profitable business model around free software, while also being a substantial contributor. So it is a good example for sustainable free software business models. But I don’t think the RedHat business model is compatible with the F-Droid community in general. The RedHat business model is entirely focused on “enterprise”, meaning large companies, and F-Droid is pretty much the opposite. Requiring payment per downloads, per-instance, etc. fits in well in “enterprise”, it is quite incompatible with the much more individual nature of F-Droid users.

GitLab is perhaps a more relevant model: selling services to “enterprise” while allowing cost-free use of its “open-core” product and gitlab.com. I’m opposed to supporting “open-core”, what I think is relevant there is that only a small percentage of users actually pay anything, and that is enough to pay the bills. GitHub is built on a very similar model (though not free software): a tiny percentage of users actually pay anything.

Nextcloud and Owncloud are better examples, they are 100% free software. They require no payment to download or use their software. They make money by selling services and support to “enterprise”.

F-Droid of course is not really the same situation as any of those. It conceptually feels like an “app store” to most users, since iTunes and Play dominate when it comes to getting mobile apps on mobile devices. So there is a common assumption based on that experience that F-Droid is the place where a payment should happen. I think we can build upon that expectation to financially support free software developers while respecting the idea that access to software needs to be open and democratic.

One random idea would be to mark apps that require large payments. What large actually means is really a judgment call, and will be quite different in different contexts (countries, social class, etc). I suppose there could be a settings slider that lets the user set what level is a “large payment”.

I think there is also a common misconception on the side of developers who are charging for their apps: users who do not pay do not provide value to the developer. It is almost always true that even users who work to avoiding paying are providing some value to the app developer. That comes in many forms that are usually hard to quantify. Things like bug reports, beta testing, network effects, free promotion when users tell people to use an app, etc. Companies like Nextcloud and GitLab have figured out how to put that into a working business model. gitlab.com is free to use because those users are the free QA testing. Nextcloud spends very little on promotion since the users who install it themselves without paying then talk about it and what to use it in their jobs, etc.

All that said, I think that the payment model that best suits F-Droid, and the apps in it, is one where the user sees a prompt to pay the developer with a suggested amount, but the user has the option to specify any value, including zero.

4 Likes

Tried latest Fdroid client 1.5beta, the stamps per app are nice and fancy, wouldn’t be possible to use mini-tags to systematically show :

  • '$ for paid options
  • '# for root features
  • '! for READ-LOGS permission granted

All these 3 aren’t anti-floss but they should trigger a [report] button so end-users could anonymously warn others about any abuses.

A what? Warn who? How?

FYI:

1 Like

I totally understand the cost of being able to sync calendar and contacts.
The developer needs to pay bandwidth & data, but putting Etesync at the same level than Nextcloud app (previously mentioned here) is wrong: not the same experience without using money.

I just consider the F-Droid warning at the EteSync entry: ‘In order to use this application you need to have an account with EteSync (…)’ This is not enough to avoid some people downloading the app, try to register, and uninstalling it after the money request.
Said that, users should be forever grateful with FLOSS developers.

While bandwidth and storage are expenses, don’t forget maintenance and support which are much more significant.
Additionally, how are nextcloud and etesync not the same experience? You need a server for both. I’m genuinely interested in understanding the difference as you see it. I mean, there are obviously many subtle differences, but what’s the main difference that makes the comparison wrong?

As for the app listing, I agree the wording there wasn’t explicit enough, and have since changed the wording.

Edit: just to re-emphasise my previous point: I’m not against apps that require a server having some indicator to mark them as such. That’s why EteSync has included such wording from the very beginning. I’m just against marking it as an anti-feature (if the server is also floss) or discriminating based on a price-point (free vs $1 vs $10).

3 Likes

I think the problem about the pro features is the currently Fdroid don’t have amount of option in some programs for the user can choose and more for basic apps, if all app starts with the model of purchased for basic things Fdroid will be a store with a lot of purchase apps where the user always need to purchase outside and where the user loses the control about you privacy and how to work that transaction, in debian, linux-mint, archlinux etc and also ubuntu is strange to find an application like email or something like that required a purchased pro-features, I think in the mobile world should be more like a desktop experience about the free/open software.

Gilab has a more different focus, like red-hat the are focused to the enterprise part, red-hat makes money whit the support for the companies, so that examples don’t require money for the final user to use some characteristics for example fedora doesn’t have a “pro” feautures.

1 Like

It has, it’s called RHEL :slightly_frowning_face:

yes, but is for companies not for final user, but the “pro” RHEl is only about support don’t block/unblock any feature in the OS

1 Like

Maybe we could add a new setting in the privacy category:

  • Include commercial versions
    (this denomination is not really correct but don’t find better)
1 Like

most like, “Include purchase apps”, and yes, should be included as privacy settings due F-droid don’t have control over the transaction and normally is an external site that could be have with privacy concerns (cookies, no https, play store etc)

“Include apps with paid features”

2 Likes

after that commit things are getting clear. :slight_smile: Great!

Yes, but the mentioned app allows the user to pick up an already running server and start benefiting the service.
This calendar & contacts sync and storage app are not the same when the later allows the user to get served without pulling out bank card or crypto wallet. User might not have any of these.

Anti-feature might sound a strong, but some kind warning is needed.

The direction F-droid is going is increasingly disturbing. I’ve recently installed a bunch of apps and almost all of them had ads, “premium” locked features, or nag screens at startup. This goes against the Libre spirit of Free Software. The argument that it’s “open source” is null and void when the intention is blatantly obvious.

F-Droid is not a platform for Shareware and those who want to sell their products have a suitable home at the Google Play Store.

1 Like

F-Droid client should be able to hide the anti-featured apps, there’s a switch for this.

Though desirable per-anti-feature filter not yet implemented, see https://gitlab.com/fdroid/fdroidclient/issues/564