“You can use it that way, but don’t expect it to work well!”
One of the basic freedoms defined by the GNU project is the user’s freedom to use the software in any way they want. I am a big proponent of that freedom and I prefer it over the very comfortable golden cage that e.g. Apple users so love to live in. However, there is a catch: As creators of the software, we can – and should – focus our product on clearly defined uses. An all-purpose tool almost certainly doesn’t do a good job for any of the many uses it supports.
This is why mobile apps are so successful: They usually do one thing and they do it well. This need for focus applies to Free Software as much as it does to proprietary software. The difference is, though, that if e.g. Apple does not want users to use their product in a certain way, it has pretty effective means to keep them from doing it, whereas we as creators of Free Software do not have – nor want to have – those means.
As mentioned before, this is a good thing. What’s not good, though, is that when users use a product for a purpose it was not intended for, they still think they are entitled to complain to its creators if it doesn’t work well for that purpose.
For that reason even though we do not force users to do or not do something, Free Software projects have to define and communicate the purpose of their product very clearly. And if people use their product for something else, they do not get to complain, period.
I remember two situations of that kind with Plasma Active.
Plasma Active’s vision is to “Create a desirable user experience, encompassing a spectrum of devices.”. However, you have to start with something, and the Plasma Active team chose to make tablet computers that starting point. So right now, Plasma Active is optimized for tablets, and for tablets only. It assumes the presence of a touchscreen, the absence of a mouse and keyboard, and a comparatively small screen.
Now some people think “Hey, I have a touchscreen built into my laptop, so why not use Plasma Active on that?”. They then ask on Google+, in the KDE or Plasma Active community, if and how they can make PA run on their laptop. That’s where I, being a grumpy party pooper, come in and ask them “Why do you want to do that? It’s optimized for a tablet, it will be neither much fun nor very productive on your laptop.” In both cases, their reaction was along the lines of “Why do you tell me what I should do or not do with Plasma Active? This is free software, I can do whatever I want with it!”. Of course I could not object to that, but I felt that I should make it crystal clear that if they do install Plasma Active on their laptop and it’s not much fun, they should not blame PA or its makers for it. If they install PA on a tablet and the experience is bad, that’s probably our fault (unless it’s because the hardware isn’t supported properly) and we deserve all the criticism we get, but if people criticize us for the bad PA experience on a laptop, then that’s unfair criticism.
This does not only apply to Plasma Active, of course. KDE applications in general are prone to create such situations due to their flexibility and power: When people can do so many things with an application, they may think they can do anything with it. This is why especially very versatile products need to explicitly state their target audience and intended use. If everyone knows what a product is intended for, it’s more difficult to blame it for failing at something it wasn’t.
For that purpose, I strongly recommend to every project team to set up a user research profile for their product. These profiles serve two purposes:
The main purpose is to guide the interaction design and development by keeping everyone in the project team on the same page regarding the product’s target users and intended uses and contexts. This makes discussions a lot easier and prevents implementation of features which are not consistent with the profile.
These profiles can however also be used to publicly communicate the product’s target users and intended uses, in order to keep users form complaining if it does not work well for uses not in the profile or from asking for features which are not consistent with the profile.
So, again, I recommend all projects to follow the example set by Okular, Gwenview and Kopete and create your user research profile as soon as you can!