Two weeks ago, I wrote about how free and open source software is failing its users. In the discussion afterwards, @kofish provided an insightful thought
I don't see free software as for end-users. I prefer a free software community of people creating software that they want to use and pushing limits. It's knowledge sharing that sometimes produces end-user friendly software. - @kofish
This of course, goes somewhat contrary to what the FSF and Richard Stallman consider free software: "Free software means software that respects users' freedom and community. Roughly, it means that the users have the freedom to run, copy, distribute, study, change and improve the software." (my emphasis) 1
I believe it's the interaction between users and developers which explain where free and open source software excels and where it fails. And it fails, emphatically, exactly in the areas where most observers ask: why aren't there any free and open source solutions in this area?
Any software project is in need of two things: developers and users. There's a bit more to the mix than that of course, but you do need at least these two bits, and a working relation between them. For some software, such as infrastructure tools, the user is the developer, and as such, there is no conflict between them.
It is in areas like this that free and open source software projects excel. When the user is able to participate in the project as a developer, it helps forge a bond of deep user engagement. For some users, this isn't possible, and there needs to be other ways of engagement.
Paul Boddie hinted at this in a response to some of the thoughts I outlined in my previous post.
Users do need to be able to engage with Free Software projects within the conventions of those projects, of course. But they also need the option of saying, “I think this could be better in this regard, but I am not the one to improve it.” And that may need the accompanying option: “Here is some money to pay someone to do it.” - Paul Boddie
Hiring someone to do the work for you isn't always easy. Even with money in hand, finding someone to actually do the job isn't trivial. There's often no one to call or email. Sometimes there's not even a mailing list to join. Even if there is: sending your request for (possibly trivial) help to a group of people you don't know is daunting to say the least.
When user's aren't able to get the support they need in ways which they are comfortable with, even if they're willing to put up the money for it or engage with the project to support it, the relation between developers and users break down, to the detriment of both.
Let's look at three examples of where free and open source software excels and consider what the user relation look like in each.
Infrastructure: We've already mentioned this, but I'll repeat it. In infrastructure software, to a large extent, the user is the developer, and is able to interact and relate to the developer community in a way which is comfortable for both.
Automotive: I'd be hard pressed to name any new car which doesn't contain some free and open source software. But there's no expectation of that you, as the driver, should interact with the community having developed the software used in the car. You'd turn to the manufacturer of the car for this. So from a user perspective, you know who to call when something doesn't work.
The manufacturer may or may not be able to help you, but regardless, there's an established protocol for this relation and on average, it tends to work. When a manufacturer accepts there's a problem which needs fixing, it becomes their problem to fix it. And regardless of the underlying cause is in a free and open source software component or not, there's a support structure in-house to fix the problem and deliver an updated version.
Software as a Service: Think Gmail, Github, all of these service offerings that are sprawling across the Internet today. Here again, I'd say that the vast majority of these are powered by free and open source software. As there's usually no requirement for the provider to offer the source code to the service to the user, there's also no expectation of, as a user, being able to fix a problem you have with the service by patching the source code.
That option just doesn't exist, and your only ability to influence the service you're getting is typically to buy the "professional" version of the service which may or may not include some support option. Here again though, we end up in the same situation as with automotive: user relations become customer relations and once problems are identified and agreed to be fixed, the in-house support structures of the service provider take care of fixing the problem regardless of in what software component it exists.
In neither of the two latter cases though, the user has any significant freedom. In most cases, the user is simply taken out of the equation and turned into a customer. And any company or organisation delivering software know how to manage customers.
I'm making the claim that where free and open source software fails, is where there's an expectation of the user contributing to the software, but where there's no ability for the user to do just that.
There are very few accounting software packages as free and open source software, not because there's no need for them, but simply because our current model necessitates the user being the developer, and there just aren't that many software developer accountants out there. The packages which do exist tends to cater exactly to the group of people who are or employ developers. Free and open source software on the desktop is similarly languishing because most users' of desktops can not contribute to the development.
Our reaction to this can be one of two.
We can accept that most users of the software developed will be customers and setup our projects to manage customers, not users. Doing this means providing the source code in a Git repository isn't enough. We'd need to actually deliver software, and design the interaction with the users as that of interactions with customers. And we'd need to accept that for most users, getting software under a free and open source license isn't going to be terribly important.
Or, if we do want users of a software to be able to enjoy the freedoms offered by the licenses we love, we need to change the development model to enable user's to really and truly contribute to software development. This is certainly possible, but it's an arduous task and my gut feeling is that even if we did, most of our users would actually want to be customers any way.
The two aren't necessarily mutually exclusive: we can (and should) make it easier for users to contribute to software. And we should keep offering software under free and open source licenses. Those who can and want to engage in the development can get the software under an open license, and participate in the development community. For those who do not want or can, we need to provide them with the option of being a customer.