I had the good fortune to to be able to interview Donna Benjamin and Leslie Hawthorn, both of whom are world-renowned community experts.

Leslie is a developer engagement strategist who works at Red Hat and sits on several key nonprofit boards. In addition to running her own company, Donna also sits on many boards and does much of the thankless work to put on excellent open source events in Australia. They each bring over a decade of experience with open source to their work, and their upcoming talk at OSCON titled, I am your user—why do you hate me?

You two are collectively familiar with FOSS communities on a few different continents. Do you think some geographic communities are making more progress than others when it comes to their users?

Donna Benjamin (DB): Culture plays a big part in all social interactions in particular. It’s been shown that our cultural background informs how we relate to power and authority more than we might expect. Geert Hofstede’s work on Cultural Dimensions gives a really useful lens to explore a range of factors that impact how we related to others. It works whether you’re talking about geographical borders or organizational ones. Most open source projects wouldn’t think of themselves as organizations, but they are!

I don’t know if any one geographic region is doing better at this than others. But I’d be curious to know if there is. Now I’m wondering how we might start to collect and analyze that kind of data.

The talk Leslie and I will be giving at OSCON is rooted in our own experience of being involved with developer communities, and hearing the way developers speak about and interact with users. We are both users of open source software, not developers. We’re powerless to respond to that common invitation to participate exemplified by the phrase “patches welcome.” On the other hand, we’ve seen damage done to developer enthusiasm and morale when a particular kind of whiny and entitled user demand filters through to open source teams. So there is a real challenge here. That baseline is an unresolved conflict woven into the fabric of user/developer relationships. I’m kind of fascinated by that challenge.

When you talk to projects that are prickly toward their users, what percentage of this behavior do you think is intentional vs. unintentional?

DB: It’s mostly unconscious and unintentional. However, there are some projects that pride themselves on being prickly as a form of filtering. This means only the “best” people get through, having passed hurdles that prove they are tenacious, productive, and excellent. The Linux kernel comes to mind. PHP internals seems to value this “truth” about their reputation.

On the whole though, my sense is this is just not top of mind. People involved in the production of free software are often focused on the software itself (and rightly so). When you know something intimately because you’ve built it, then how it works is obvious to you. It can be frustrating having to explain obvious things. And making things “easier” for other people is subjective. If you don’t see a problem, you can’t even begin to fix it. If you don’t understand their needs or perspective, it’s hard or impossible to cater for them.

Have you ever encountered a project that had absolutely no idea that their behavior was probably alienating users?

Leslie Hawthorn (LH): I don’t want to name names, but I’ve actually encountered quite a few projects that didn’t realize their common practices caused people to not contribute to their work and, in some cases, to not even use their software. More often than not, alienated potential users and contributors aren’t going to tell the project maintainers about their concerns; they’ll simply vote with their feet and tell their friends to steer clear as well.

I remember one lunch at a popular open source software conference talking to a friend over lunch about projects to avoid and she talked about a particular web-focused project she had chosen to leave. After a few minutes, someone else at the table apologized for eavesdropping and expressed shock that she’d left the project. From his perspective, the acerbic communication style was just normal and he didn’t understand why she’d find it off putting. Unsurprisingly, that project has pretty much died on the vine since that conversation.

Is there any kind of red flag that tells you right away that you’re interacting with a project that doesn’t care about its users?

LH: If the project’s public presence isn’t particularly newbie friendly, that’s often a good indication that they don’t value their users. If you can’t find a useful about page or project description, that project is likely fairly insular and focused on its developer community. You can confirm that by joining their other communication channels and seeing how questions are received. Are you told to RTFM immediately, even when you mention you’ve read the manual? Best to spend your time and energies elsewhere.

DB: I very much agree. Unless the project has some direct and specific value to you, don’t waste your incredibly valuable and precious energy trying to fix it. On the other hand, if fixing a project is part of your job, or you want to because you think the project deserves your attention, then take a look at OpenHatch. There’s a lot of great resources there on what makes an open source project more welcoming to new comers.

Are there any companies or projects that you think do an especially good job of listening to and incorporating user feedback?

LH: I think there are any number of companies and projects that do a great job listening to their users. To take a look outside the open source software world, think of just how much people love Slack. Not only does Slack implement frequently requested features regularly, they also make their platform somewhat hackable so users can create bots that improve their experience with the software. And they have an incredibly user-centric model for educating their users, with simple tips that appear each time the software loads in the browser. These tips are quick, easy, and just let you know there’s more you can do with Slack. They’re also non-intrusive because you have to wait for the application to load anyway. This approach explains a great deal about why they’ve had such a huge increase in number of users even when they’re implementing functionality that exists in any other number of applications, from IRC to HipChat.

DB: Yes, Slack is a great example. It’s fascinating how some parts of the open source community are adopting it and others are vehemently rejecting it. I’m beginning to think it’s a canary in the coal mine. Of course, Slack isn’t an open source product or platform, and that is one of the reasons it’s being rejected. But the common reason I hear from those advocating for its adoption is around how user friendly it is. There’s a strong perception that Slack lowers the barrier to participation.

Do you have suggestions for software builders that are ready to stop hating their users?

DB: The thing is, on the whole they don’t really hate their users. As users, we just feel they hate us because it seems like they don’t care. It seems that our challenges aren’t important to them or simply aren’t seen as a priority. We need to meet in the middle. We need to learn, understand, and come to grips with the cause of this sense of disconnect between users and developers.

I think the open source dynamic means this is fundamentally different than the relationship between manufacturers and consumers. Every user of open source software has the potential to contribute to the production of open source in some capacity. That’s a very different power dynamic. I’m now thinking of Kathy Sierra’s work about empowering users to be the best they can be.

Are there people who you can hire to help you understand your users? Or maybe some key blogs people should be looking at to help them improve their users’ experiences?

DB: Kathy Sierra has published a book called Badass: Making Users Awesome. This distills what she’s been saying in talks and blog posts for years. It is a good place to dive deep into thinking about the real people who use our software. She also made an amusing book trailer for it.