In Free Software, it’s okay to be imperfect, as long as you’re open and honest about it

Saying “sorry” and really meaning it goes a long way towards maintaining or rebuilding trust, especially in the Free Software community

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.

7 comments on “In Free Software, it’s okay to be imperfect, as long as you’re open and honest about it”

A willingness to admit shortcomings, more than anything else, is what makes the best projects successful. It clears the cultural cruft out of the way so the work can progress and goals can be met. Very cool post Thomas!

Regarding the InstallerGate, the way the issue is “resolved” and the uncertainty around the real reason why this feature was introduced in the first place leaves a bad taste.

Although it is, now, not a must to provide Qt Account credentials to use the installer, it is not obvious that one can skip logging-in.

There is a “Next” or “Continue” button depending on which platform you use the installer, and such buttons usually become clickable when one fills in the form on the screen. The fact that the Next/Continue button can be clicked to skip the logging-in or registration is not mentioned on the dialog.

This doesn’t seem like a “sincere” solution that corresponds to the sincere apologies you referred to.

The way I interpret the InstallerGate event isn’t based only on the Qt Account issue. Considering how qt-project.org web site is replaced with qt.io, the way qt.io is designed, how you need to try really hard to find a page on qt.io to see the Qt Project gets mentioned (except the Twitter account name, which is now at odds with qt.io), IMHO, the why and how of introducing the now-reverted mandatory Qt Account requires a more comprehensive analysis.

Please compare the language of the responses to comments in the original announcement post from the writer of that apology post to the language of the apology post. The responses to comments are “unfiltered” and more “sincere” in my opinion. They are a company representative’s efforts to ignore the issue that’s being raised by the commenters and almost cut-and-paste canned responses from the post. The apology post, therefore, seems more like a damage control than a sincere apology.

I would like to listen or read what Lars Knoll thinks about this issue as The Qt Company CTO and as the Qt Project Chief Maintainer. I think the Qt community, if there is one, deserves an explanation about why this “One Qt” initiative seems to erode the Qt Project and pushes it into the commit logs on code.qt.io.

Thank you for telling us your take of “InstallerGate”. This shows that even the sincerest apologies do not convince everyone if the actions taken do not match them 100%, but seem somehow “half-arsed”.

Regarding the “One Qt” approach I can say that most or all of the reactions I heard from contributors to the Qt Project so far was that they support the general approach and welcome that it reduces the separation and confusion between resources for the Free and commercial Qt versions.
What I heard some people being critical of is the resulting uncertainty about which parts of the actual code belong to which, and which contracts and agreements apply to which. This is something that has still to be cleared up between The Qt Company and the Qt Project community.