Android, FLOSS and end user support
I’ve been using Android based smartphones for a while, spent most of the time ever since the mid-1990s using GNU/Linux and SoftwareLibre applications and kept on trying to do the same on Android. While it generally works, thanks to a bunch of great Free applications available both in Google Play Store and independent software stores such as f-droid, one core issue remains: Support. I learnt quite some lessons on that, throughout the last couple of years…
Support for “paid independent applications” in Google Play.
Had to try this with AquaMail, F-Stop Gallery, Podcast Addict, Footej Camera, PowerAmp and a couple of others, most of these in their early days. Trying to avoid “gratis” and ad-driven apps and instead actually throw in some money to support independent developers, I’ve been with these apps and a couple of others for quite a while. In some cases I ran into real blocking issues (such as early AquaMail versions not working with our corporate mail server), in other cases these were just feature requests or questions on how to use the software (like in case of figuring out how to use PowerAmp to listen to audio books while keeping track of listening progress in individual tracks).
In all these cases, support has been a breeze: Use the contact data in the Play Store application description. Write a few lines of e-mail. Send. Wait. In most of these cases, I received a response within less than 48 hours, and in pretty much all cases, my problems were solved within a few days, even including (in case of AquaMail) testing apks being mailed around in order to make sure a certain issue really was fixed. It always felt helpful and straightforward, and in some cases (like F-Stop) even on the “free” variant which in the end made me buy the “paid”, ad-free version of these.
Support for “Libre” applications.
Talking about FLOSS applications, on the other side, support experiences were and still are way worse in the majority of cases. It usually works like this: Look for the application in f-droid, usually there’s some link where to report issues. Next: End up on some issue tracker. In most cases, it’s just a github project. In worst case, it’s some other issue-tracking environment. And of course submitting an issue requires an account. So down the usual road: Register for an account, wait for a while until the mail confirmation makes it to your mailbox. Maybe check back two hours later to try send this mail again, until it finally arrives multiple times thanks to e-mail servers greylisting some of the traffic. Finish your registration. Then, try to navigate through the project structure or issue tracker to figure out where to actually report whatever problem you have. Non-technical users will be lost at least here. In best case, again, you end up with a Readme.md before that, pointing your way to various online resources such as matrix.org chats, some particular /r/whatever subreddit and maybe a mailing list of some kind where you also might get in touch with people that might be of help. Given some time, you find a way where to get rid of your question.
And then you wait. Results will, by then, differ, depending upon which channel you did choose. Most likely people will be just simply “ignoring” you because no one knows how to answer your question or doesn’t understand your issue at all. (The AntennaPod forum is a very interesting example for that: Apparently, AntennaPod has had a press appearance as a rather good podcasting app at some point in recent history, which ended in a bunch of new users and a couple of these also “flooding” the AntennaPod help forum. What to say… most of these requests have remained unanswered ever since.) In some other cases, especially if you added reports to a github issue tracker, people will more or less politely tell you that they can’t do anything about your problem because they’re unable to reproduce it since you didn’t provide any information or debug logs to see what happened. Worst case will be a more or less rude response that your request is pointless and you shouldn’t bother asking again.
Eventually, some day you will have your issue fixed. But chances for that, at least in my very personal experience, are way smaller than receiving meaningful help in case of using a paid app with a dedicated maintainer. Of course, in both cases there are exceptions from that rule, like the f-droid client app or fedilab which both have very active and friendly supporters hanging out on the fediverse or specifically mastodon. Or Marcel Bokhorst, known for tools such as Xposed or FairEmail, who pretty patiently answers questions mostly in several XDA forums. But unfortunately, in the majority of SoftwareLibre apps I felt the need to request help, I would have been totally lost as an end user not knowing about things such as “issue tracking”, github, reddit or logcat.
The problem…?
Well, I’m sure that’s a very personal point of view. But I’m more and more concerned that trying to convince end users to use SoftwareLibre is getting more and more difficult because the “gap” between an end user and a SoftwareLibre developer and user is getting bigger and bigger. When I got into GNU/Linux (emphasizing GNU here) in the mid-1990s, the crowd using computers still was somehow homogenous. For sure, there were different kinds of crowds focussing on different aspects, but there was a certain level of knowledge you just could expect people to have – like knowing what an operation system is, knowing what application source code is, that kind of stuff.
Nowadays, people using technology are way more different. There still are computer enthusiasts, people who use some arcane Un*x derivative on their computing environment, people who exclusively work on the command line and consider everything beyond that horizon to be redundant and bloated. On the other side, however, there are end users who don’t even know about software, computers or “the internet”, people who neither know nor care about the difference between instant messaging, e-mail and web, the kind of crowd Apple and Google successfully are catering and building products for, the kind of people who say they don’t “need internet” on their smartphones and actually mean they don’t use “the web” (while obviously making use of “internet based” services such as WhatsApp, Instagram or the Google search engine). This user group does have totally different expectations towards computing, software, features, support. And this is what makes suggesting virtually any SoftwareLibre solution to those people really really difficult: The way most of these projects are maintained, right now, simply is not up to supporting a vast load of really untrained end-users with very basic questions. Other way round, getting even basic support, to an end user in such an environment, is way too difficult and . And this is likely to make FLOSS even more unattractive to a bunch of these users, especially assuming most of this crowd doesn’t benefit very much from the freedoms provided by SoftwareLibre licenses. That’s really bad, because for a whole bunch of reasons, these freedoms now seem more important than ever before.
And now…?
There could be a bunch of solutions to that problem, possibly. One of those, for smartphones, might be /e/ and their approach to provide an end-user-ready aftermarket “operating system” to work on Android devices and come with an app store of its own. Another one, targeted towards desktop users, could be elementary with its focus on privacy and being “Libre” while at the same time offering an app store with the option for developers to charge downloads of their apps, which might be a way to provide a “professional FLOSS” ecosystem. Maybe, too, we need more structures, organizations, foundations who are dedicated to funding FLOSS projects in a way so that some developers can professionally build and support these applications.
But, after all, an important and different part of solving this “issue” will be people who are both into FLOSS and into development and ready and willing to fill this gap. With more and more “non-technical end users” making use of software and technology, we will have to rethink our idea of software that comes without “fitness for a particular purpose” and rather think about in which way to help making sure software actually does have a purpose to an end user – who would be choosing any of the large, free-of-charge proprietary solutions out these days otherwise.