In Free Software, it’s okay to be imperfect, as long as you’re open and honest about it
Humans are fallible. We all make mistakes sometimes. Most of these mistakes affect only ourselves or those close to us, but sometimes we make mistakes that affect more people. Work in a Free Software project is one of those areas where a mistake can easily affect many people in a community, or thousands of users.
The same is true for organizations in the proprietary software or service world, but it feels to me that two things play an amplified role in the Free Software world; openness and honesty. While users/customers of proprietary software or services also do appreciate if a vendor openly admits a mistake, honestly apologizes for it and promises to make up for it, the default expectation is rather that they don’t. Or if they do, that it’s a calculated PR effort, done because some suits crunched some numbers and decided it’s better for the bottom line.
In the FOSS world, people seem more likely to really see the person, not just the community they belong to. And from a person, they expect that they really and honestly feel sorry if they made a mistake. And they seem to be more forgiving if a FOSS contributor admits a mistake and apologizes than if a proprietary software company does. It’s not only individuals, though. It seems like even companies in the FOSS field are expected to be more open and honest than those in the proprietary software field.
Exhibit 1: InstallerGate
A case which many readers on PlanetKDE – which are likely to also be interested in Qt – are probably familiar with is the issue of the Qt online installer forcing the creation of a Qt Account in order to continue the installation (since it seems to be hip to call everything that is even the slightest bit scandalous “[something]gate” these days, let’s call it InstallerGate). As the comments on the blog post announcing the change may hint at, the reactions by Qt users and contributors to it were not pretty. At all. People claimed that Qt is becoming “less free” or that “pushy greed is determined to ruin Qt and turn decades of efforts into a waste”. And those are the comparably harmless comments.
And it wasn’t just on the blog post itself, people from all corners of the internet started attacking The Qt Company. Of course reverting the change and making creation of a Qt Account optional was the obvious reaction, but The Qt Company did not stop there – a very wise decision. In the blog post announcing the change, Tuukka Turunen, Qt’s R&D Director, after thanking the community for their feedback, said “We clearly ill-calculated how asking for a Qt Account with the online installer would make our users feel. A mistake. Sincere apologies.”. That does not sound like marketing-bullshit, that sounds like someone who has realized that he (or whoever made that decision) screwed up. Later in the post he thanks the community again: “So, thanks again for your feedback, discussions and for guiding us in this tough endeavor.” He admits that The Qt Company needs guidance through their endeavors by the community. Pretty strong statement.
And the community really appreciated that honesty, expressing it clearly in comments like “Thank you! Apart from the technical merits of Qt, it’s also nice they hear their users and developers (I’ll however create a Qt Account for myself! ;-))”. Of course the actual decision is the most important part, but open and honest communication about it goes a much longer way to maintain or rebuild trust than just reverting a change.
Exhibit 2: ShowDesktopGate
Of course community Free Software contributors make mistakes, too. Like me, for example. This March, I was asked to provide user experience input on a review request titled “Show Desktop feature: refurbished“. It was a quite big change, with quite a few changes in the interaction with the feature to comment on. One question was what to do with the panel when showing the desktop.
A big issue there is that if one clicks on a task in a task manager while in Show Desktop mode, there are different things that could happen, each with its own drawbacks: The appearing window could “break” the Show Desktop mode, returning to the previous state before it was activated. This works, but may confuse users because clicking one task suddenly brings back all windows that were visible before Show Desktop was activated. Alternatively, only the window which was clicked on could be shown. That would cause the least surprise initially, but would leave things in a poorly defined state (What happens if one leave Show Desktop now? What happens if another task is clicked? Or the current one is clicked again? Which windows are shown or hidden in which modes?), which is prone to cause confusion as well as bugs. Simply hiding the window belonging to the task behind the desktop like all other windows would be logical from a technical standpoint, but very confusing for the user (“I clicked on that task, why can’t I see it?”).
With that in mind, this is what I replied to the question: “Panels: I’m a bit torn here. The thing is that we have not defined what the dashboard is supposed to be used for. If it is only for glancing at or quickly interacting with desktop widgets, then panels would only be distracting. If it is for interacting with the workspace in general, then of course panels should be accessible. One argument against showing panels would be that clicking on a window in the task switcher would break the mode (the window should not go below the dashboard, as that would be inconsistent with switching via alt-tab). Still, I see valid arguments for both alternatives, so I’ll leave that to you. Just make sure that either panels are fully visible and can be interacted with, or are hidden/dimmed/faded and cannot be interacted with, as any mix of the two would be confusing.”
I thought that since in Show Desktop mode the focus should be – as the name suggests – on the desktop, we could avoid the issue that the taskmanager can cause by just not showing the panel at all. Problem solved, right? What I had completely missed, though (since my mind was focused on triggering Show Desktop mode via alt-tab), is that another common way to activate Show Desktop mode is by a Plasmoid. In a panel. The unfortunate part is that now as soon as one clicks that Plasmoid in Plasma 5.3, the panel is hidden, and the Plasmoid with it. Boom! Impossible to leave the state in the same way it was activated. Confusion! Panic! Usability bug.
I screwed up. Yes, I could hide behind the fact that I didn’t explicitly advise for hiding the panel but left the decision to the devs, but it isn’t their job to detect usability bugs in the making, it’s mine. And they trust me on that (which is great!), so if I say that something is okay, developers think they can safely assume that I’ve thought it through and there are indeed no issues. Only that this time I didn’t.
Of course when people noticed the problem, I was informed immediately and agreed with the developers that the panel should not be hidden in Show Desktop mode after all. This problem will be fixed with the first bug fix update of Plasma 5.3. However, I still have to sincerely apologize for the confusion this change will likely cause to users in its short lifetime, and to the developers for not living up to the trust they put in my judgement in this particular case. I will think things through more thoroughly before the next time I comment on a review request as complex as this one.
In the meantime: Can you be mad at someone who gives you this?
I sure hope not.
Openness and honesty as a criterion for choosing a FOSS product
Openly admitting mistakes and apologizing for them isn’t the only occasion where openness in communication is important in the FOSS world, though. As I learned from my interview with a user and contributor of the open source NoQSL database ArangoDB, the team’s – in his opinion (even compared to other open source NoSQL databases) – very open communication actually was one of the main reasons why he chose it for his project. He sees it as an important plus for them that “They are open about their shortcomings” because “If I’m going to build a product on something, I want a relationship with the makers and users of that something. In every relationship I want honesty. Openness by a product maker is as close to honesty as I can get.”
So even if you haven’t screwed up yet, it is beneficial to be open about what you do (including your product’s shortcomings) right from the start of an open source project, because that builds confidence and trust. Trust is important for end users, but probably even more important for people who build their products on your software.
Now, dear reader, I’d like to hear your take on this: How important is openness and honesty of a product’s creators for you? Do you, too, feel that it plays an even more important role in the FOSS world than in the proprietary software world, or do you think it’s the same? Let me know in the comments!
Disclosure: No, I did not get sponsored for writing this article. I included the reference to the interview because I think it fits the theme that I observed with the Qt installer and FOSS projects in general.