I'd like to introduce to you Lesley Hausen, who was responsible for making Google's Summer of Code great again.

And especially responsible for Google Code. After some time at Lestic, she now works for Red Hat and there is part of the Sandoz team. And she will talk about how open source projects handle their users, how they work with their users,

and how they can improve on making their users happy. So, a big round of applause for Lesley.

Thank you so much for that introduction, Scotty. Hello everyone, thank you very much for coming. I'm honored to be back at FrostCon again this year. This is my second FrostCon and it will certainly not be the last. I'm here today to talk again, as Scotty said, about the way that open source projects interact with their users and why certain behaviors are extremely problematic

and why they can contribute not only to a lack of user happiness, but I believe to a lack of adoption of open source. And I feel very strongly that this topic is important because I think that we are at a crucial time in the evolution of technology where people are aware enough of the implications of the choices that they make

about what software they run and what tools they use and how those have a greater social impact and an impact on themselves and their freedoms. So, when my dear friend Valerie, who is a teacher, a high school teacher,

so students in their 11th year of high school, who are recent migrants from Haiti and the Dominican Republic, and who inevitably, every time I see her, hands me her mobile phone and says, can you please make these notifications go away? They're horrifying me and I discovered she hasn't done a software update in two years since I last saw her.

When she calls me and says, Blondie, what is this open source stuff because I think we're being spied on and that's not good, then I know we're at a critical time to be able to bring more users into the free and open source software fold and to help them understand why it's important that they use free and open source software.

So, unfortunately, I don't think that we do a very good job of welcoming people into the open source world. Although I have to admit, every time I come to FrostCon and have a talk to give that rants about how we don't treat people really well, I am reminded that this is probably the worst audience in the world to give these talks to because everyone in this community is so welcoming and so cool

and is so invested in helping other people learn that I then am grateful that at least there's a video, so maybe this will be useful to folks who are not in this particular audience. So, this talk is actually, hey, slides, why do you hate me?

All right, you just, there's so much hatred. Do you want to do a thing? You do want to do a thing, excellent. So, this talk actually started as a very private rant between myself and my dear friend Donna Benjamin and this is actually a 10-year long sort of bubbling thing inside of ourselves

where Donna and I would get together at various conferences and have the I am your user, why do you hate me rant. So, Donna Benjamin is not a developer. Donna Benjamin is a content strategist. She is a community organizer. She's been responsible for the adoption of open source software

across a number of governmental departments in Australia, in her province of Victoria. She lives in Melbourne and works extensively there with the Department of Education. She's migrated them off a proprietary CMS onto Drupal. She's helped them to get courses on open source software

into computer science and IT curriculums in universities there. And so, obviously, very accomplished woman has been involved in the open source community for many decades. I'm also not a developer. I'm not a lawyer. I'm one of those people who helps folks deal with their squishy human problems and also creates mentoring programs or mentorship opportunities

to help get more people involved in open source development, be that programming, be that design, documentation, et cetera. So, we were sitting together at a table and something happened that generated this epic rant. And when we got together 10 years later to finally give this talk,

we sat down and both sheepishly looked at each other and said, do you remember why we started ranting about this? And she didn't remember either. So, there was some whiskey involved, mistakes were made, but at least this rant came out of it. So, effectively, we would consistently,

after that when we met up, we would look at each other and we would say, I am your user, why do you hate me? And what we were referring to was this, to us, this very odd pattern of behavior amongst our friends and colleagues who were open source developers who just seemed to have this deep contempt for the people who were using their software. I mean, for a long time, once upon a time,

I was dating a systems administrator and every day when he would be done with work, he would come home, flop down in his easy chair and say, users, every single day. These were the first words out of his mouth, right? And I couldn't figure out why there was this deep level of contempt.

And, you know, obviously, there are many stupid questions to be asked and I think I've asked a few of them, but it just seemed to me to be so outsized. And I was frequently, along with Donna, in conversations where these kinds of rants against stupid users and their stupid ideas and their stupid bug reports

and like, why don't they just figure out, and we would kind of sit there sheepishly very quietly and then folks at the table would notice that we were being very quiet and they'd say, no, no, no, not you, we love you, you guys are great. But the people you're describing, the behaviors you're describing, like not a developer, not a maintainer of an open source project,

these things applied to us. So we were thinking, we're your user, too. Why do you hate us? Why is this happening? And I think it starts off with our understanding of what a user is. So a user is somebody who just uses a computer network or service, right?

Someone who lacks the skill to be able to develop a particular system is a user of that system. Okay, fair enough. This is accurate. But I wonder about this particular part of the definition. Without the technical expertise required to fully understand it, does anybody here actually understand everything about how their computer works?

Excellent. Not a single hand has been raised, and there are no doubt many computing experts in this audience. The idea that our users are somehow lacking in intelligence and are not worthy of our respect because they do not fully understand the systems which they use is ridiculous.

None of us actually understand fully how all of our technology works, which I think is actually a fairly scary proposition. So let's talk about some of the ways in which we display sad, sad behavior towards our users. I am personally a big Shakespeare fan,

and his sonnet, How Do I Love Thee Let Me Count The Ways, so he is the inspiration for our five ways we can show deep hatred towards our users. Ah, this one is great. This software is just for Brainiac Me. I do not care about your needs. I am not here to make this work for you.

Now, there is something to be said for the fact that it is very fair that open source is motivated, again, to use the common phrase, scratching your own itch, creating something that you yourself need, and that's great. There's nothing wrong with that. The idea that if someone comes along and has improvements to contribute,

has questions about how something works, or effectively wants to get involved but they don't quite know how, and the response that they receive is basically something along the lines of, there's the door, thank you very much, except usually it's said with many more swear words that I'm not going to use because we are on video. That would be inappropriate. So the idea that the software that we create

is only for people who are just like us, people who are super geniuses, people who are highly, highly technical, people who fully understand the systems that they're using, and if you're not cool like me, you don't get to do this. This is not for you. This is not something that you need to be involved in,

and I don't need to care about your needs. And that's really, again, that's very sad because it denies us the opportunity to help more people get involved with open source software and understanding the value of it, not just from a technical perspective, but also from a social perspective. If it's only something for the wizards and the magicians and the genius programmers of the world,

it's not accessible to everyone, and not everyone can benefit from it. Ah, stupid user memes. I have to admit that I may have engaged in some stupid user memeing once upon a time because I was the accidental techie for my recruiting department when I worked in HR once upon a time where I decided that I really liked talking to nerds all day

about their technical ambitions, but wow, did I not want to work in human resources ever again. So we create these ideas that our users are idiots, and then we trade pictures online about how they're all dumb, or we have admittedly, I think, hilarious TV shows like the IT crowd

about how all users are stupid, where the guy picks up the phone and all he ever says is, have you tried turning it on and turning it back off again? If it were just that easy all of the time, I think we would have less difficulty, although I have also been told by someone in the audience last time we gave this presentation that I was giving people far too much credit, and I had clearly never worked a help desk.

And I said, actually, I had worked a help desk. I had worked a help desk for our applicant tracking system once upon a time in that stint in human resources, and I actually found that more often than not it was a lack of vocabulary on the part of my users. We just weren't using the same words for the same things, but I still occasionally engaged in mocking them.

But we have this idea that our users are dumb, like immediately upon approaching them, right? We think that they lie, that if they say that they are experiencing a particular problem, they're not really experiencing that problem, they just want to call us up and vex us and piss us off, or they just want to file a useless buck report and complain and bitch. And I just don't feel like that's accurate,

and I think that immersing ourselves in these kinds of images and memes about how our users are stupid, useless, and terrible doesn't help us create empathy with the people who are using our software. This one is the bane of my existence. No, no, I know better.

How many of you are maintainers of a Free to Open Source software project? I see a couple of hands in the room. How many people come to you with feature requests that are silly? Ah, yes, okay. John's like, I get all the silly feature requests, all of them. So admittedly, there are times when people will ask for something of you

or of a project that doesn't make a lot of sense. My favorite example of this is, once upon a time, I used to share a cubicle with a gentleman by the name of Carl Fogel, who wrote the seminal work producing open source software, how to run a successful free software project. And amongst his many accomplishments,

Carl Fogel was one of the original developers of the Subversion version control system, which some of you in the room may remember as being the cool thing before we all had Git. And it might still be cool, but apparently not, because the kids these days have never even heard of it. So the Subversion project said in their mission statement that their goal was to create a compelling alternative to CVS,

to the CVS version control system. Great. So one day, some wonderful human being showed up on their mailing list and said, I know what you guys should do. You should just sit there and stop working on the Subversion thing and just work on CVS, right? That's going to be great.

Not really. That was not what they intended to do. And I'm not talking about those moments of not listening to people who do drive-by, random, ridiculous requests of you, because those are drive-by, random, ridiculous requests. But if someone comes to you with an idea that's largely sane, maybe you just don't want to implement their idea,

maybe you just don't want your software to work in that particular way, but it's still a sane idea. Simply not listening to them because you know better is really a problem. I know that it can be exhausting to interact with other people. I have a hard enough time dealing with myself,

let alone other human beings. But actually taking the time to explain to someone why their idea may not be the best for the project is a great idea. Or assuming that they might have something to teach you, actually letting them explain to you what their issue is, why they're experiencing it, and what they would like to see different

is actually I think a very fruitful source of dialogue. So it may be that you don't want to do exactly what they're telling you to do, but you can get a great deal of information about why what you have created is suboptimal if you just listen to their frustrations and what problem they are actually trying to solve. And I found that to be a hugely fruitful source of information

when working on software projects and trying to help people with, say, user experience design, because folks will come and tell you that what they want is, and this is a very common phrase in the United States, I want a faster horse when really what they want is a car. But if you walk through what their use case is

and what their needs are, then you're actually going to get useful information that can be beneficial to you, the maintainer. My other favorite, you're just not technical. How often have you had someone who is not a developer, not in the tech industry come to you and ask you if they will fix, can you please fix my computer?

Okay. And how often did you just want to just tell them, like, no, I will not fix your computer? Yes, okay. So now, did you get frustrated with them immediately because you were thinking, like, you're not technical, you're not, you know, you're just kind of an idiot

and, like, I don't want to deal with you, another set of people who are, like, not technical and idiots yet again? Yeah, okay, that's totally fair, right? That's human, that is a completely human thing to do. I am personally deeply offended by this phrase for a number of reasons. One, I think it is ridiculous to define someone by what they are not.

Right? If all we can do is understand the people that we're interacting with in the context of what they don't do, what they are not capable of, we put them in this very sad space where they can't improve, they can't become better, they can't acquire knowledge,

they can't interact with us in a way that is mutually beneficial because they are not something. They are this other thing, they are this not technical thing and this not technical box over here is something that you can never escape from and nothing will ever be good inside that not technical box.

And I also find it very frustrating as a phrase because it is completely meaningless. What does this mean? What is not technical? So, is an astrophysicist not technical because that person is not a computer scientist? I don't think that we would necessarily think that. I have been told that my mom is not technical

because she still calls me and I remind her to turn the computer on and off again. My mom was one of the first Unix programmers. She hasn't kept up with her technical skill set but I would never say that she was not technical just because she does not eat, sleep and breathe software development anymore.

The idea that we can simply dismiss someone's concerns because they are somehow not like us, they are not a developer or maybe they are a developer but they are a developer in a different language and those PHP people are silly or those Ruby people are silly or you are not as good as I am. It creates a really sad dynamic in our interactions with people

and again we cut ourselves off from the opportunity to learn something useful from folks who are taking their time and energy to give us feedback when we simply put them in this box and say you are not technical, there is nothing useful that I can learn from you. Then we have this idea of kind of like, this is more of a meta idea

but the users as faceless icons. How many folks are developing anything that has a graphical user or a face? Okay, so a couple hands in the room. Mostly systems programmers in this audience I would assume are system ins, yeah? I see some nods. I see some people nodding off to sleep, that's fair too. So we have seen over time and I actually find this to be

a really compelling development. We have seen over time this kind of evolution from the idea of people pictures and our software going from these like weird little kind of chess pawn nebulous things in weird colors, smurfs are blue, people are not blue, just in case anyone was wondering,

to actually icons that look like people and this doesn't seem like it's that big of a deal until you start reading things like the explosion of excitement on social media when they created emojis that were not showing people with white skin tone,

for example. Suddenly people were saying, hey, someone finally created something that looks like me, I feel so good about this, this is great. So when we actually take the opportunity to build into the appearance of our software, the idea that there are actual people using it, not weird chess smurf things, then we actually create an empathetic relationship with our users.

We care about their needs, we want to meet them, and their needs matter to us. So we're moving away from this kind of era of our users are these faceless icons, they kind of don't exist, they're this fictional element of stupidity over here while we make something beautiful and hope they don't screw it up too much

and we thank God that we are not on call, because when they screw it up, we don't hear about it. I think that this is all kind of wrapping up into a nice little package of generally prickly attitudes around open source software projects, and this is clearly not true of all projects, but there are some that are notorious, shall we say, for prickly attitudes.

Before I was presenting at FrostCon, I was presenting at the OpenSim conference in Berlin, which is an academic conference about the study of open source software by academics, and I was honored to sit in on a presentation by a professor named Megan Squire, and she had done a linguistic analysis of the Linux kernel mailing list,

which shows that she was a very brave woman to begin with, and what she wanted to know was, was there a difference in communication style amongst the participants in the Linux kernel project, because it was well known that this was a, you know,

you enter the LKML only with asbestos underpants on and maybe not even then. And it was very interesting, because the thing that has stuck in my mind the most was, she was doing a measurement of the number of times that people said thank you, or the probability that if someone said thanks in an email,

who would it be? And if the word thanks was used in email, comparing two of the top folks in the project, and I'm not going to name names here, because I'm not trying to slam any particular individual, just making a point. Maintainer A, there was a two percent likelihood that he said thanks, whereas maintainer B, who was a little bit further down the food chain,

the percentage possibility that he said thanks was 98 percent. So, you know, again, we have this ingrained in our culture that it's OK to be rude, to be offensive, to be very, I don't know, if there is a non-swery word to say this,

to be very a-hole-ish in our discussions with other people. And it's OK to do that, right? So one of the projects that I'm most excited about having worked on was the Google Coding Program, which was a way to introduce students who were in high school

and even younger to open source development, and not just software development, but also documentation, user experience, design, marketing, all of the aspects of creating software. And for the very first year, we had some participants from the Plone Project, which is a Python-based content management system, which I'm not sure if anyone is using it anymore, but hopefully they are.

So these folks were having a conference at Google at the same time. I also used to host a bunch of open source software conferences back in the day. And it just so happened that one of the students who had participated in the program with the Plone Project lived three or four miles away. And he noticed that all of his heroes,

all the people he'd been working with were going to be in town. And he emailed me and asked if he could come visit. And I thought that that was a great idea, and I checked around with the conference attendees, and they also thought it was a great idea. And so Jonathan came down to the Google HQ and met everybody. And so, of course, this being a 14-year-old young human,

his mother drove him to Google HQ. So that was really cool, and it was great. And there was photo ops, and everyone was really excited to meet him. They thought he was really brilliant, and it was great. It was a really touching moment. But the best part of the day was when the lead maintainer for the Plone Project

all of a sudden just sort of stops what he's doing, kind of looks around, eyes shifting left to right. And then he goes over to this young man's mother and says, Ma'am, I don't know if you've ever read our mailing list. And she said, What do you mean? And he said, Well, you know, we call each other idiots a lot

and say that the other person's a moron and that their ideas are stupid, and we don't understand why we're not very nice to each other. We're really not very nice to each other. We just want you to know that that's all a joke. We really like each other. We really care for each other. We're all friends in real life. We go out and we get beers and we go to each other's weddings

and we go over to each other's houses for barbecues, and we just want you to know we're not really like that. Now, the best part was her response, which was, Oh, please, son, I have another son who's a gamer. You're fine. But again, we are so acculturated to the idea

that if we are amongst friends that we can be very vitriolic, very unkind in our speech to one another, and this tends to boil over into our discussions with everyone, even people who are not close enough to us to understand that maybe this is just kind of the family in-joke, family rivalry, right?

We have acculturated ourselves to the idea that it is OK to be rude, to be unkind, to be unwelcoming, to be prickly like cacti, right? And again, this is unfortunate, because it cuts us off from the opportunity to learn more about what our users need from us and to welcome them into the fold of using and contributing to open-source software.

Now, I want to talk about the people that you probably think I don't know about giving this talk, the whiny, entitled, demanding, terrible people. How many of you have dealt with whiny, entitled, demanding, awful users? And almost every hand in the room goes up. And I bet when you deal with those folks,

your immediate response is to say, you know, I work on this during my free time, or I certainly don't get paid enough to deal with you being a big jerk to me, please, you know, forward yourself to the nearest, like, wastebasket over there, thanks. I'm not here to advocate that anyone put up with bad behavior from their users.

If someone is treating you with disrespect, if someone is coming to you and suggesting that you spend your free time developing a feature that they require for their business enterprise and they can't even be bothered to say thank you when you actually develop that feature, like, forget it. Like, this is not behavior that I think anyone should be putting up with.

I recently read a very, it was just super sad to read it, a post from a maintainer of a very popular library who basically said that he was looking for a maintainer for the three libraries that he was working on because they had grown in popularity much more than he had ever expected. He had just put them up on GitHub because they were useful to him,

and suddenly there were all kinds of people relying on what he had built, and that he basically talked about the stories of, you know, he was married, he'd recently had a young child, and, you know, he had just gotten off of a stint where his day job ended on Friday,

and he had literally worked from the time he got off of work on that Friday all weekend without sleep, without spending any time with his wife or his young child, because someone had filed an issue and said, this bug is taking down our website. We are losing sales. If this doesn't get corrected, I am going to get fired.

Please, please help me. And this is a good person, right? This is terrible. I don't want this company to go under. I don't want these people to lose their jobs. I don't want this person to get fired because their manager doesn't understand it's not their fault. So he works tirelessly for more than 48 hours to fix this bug.

He commits the fix. He puts a note into the GitHub issue that it's been fixed. Please try it out. Let me know that it works. I hope that everything is going to be okay for you guys, like I wish you the best of success with your business. And he never heard a word. Not even a it works, not even a thank you, just nothing.

Now, I under no circumstances suggest that anybody should put up with that kind of behavior. I want to talk about creating a reciprocal relationship of respect, compassion and empathy between developers and users. If people are coming and are refusing to contribute with at least their thanks,

if not money for pizza or even heaven for Fend, you know, money for your living expenses, for hard work that you do in your free time, you don't have to put up with that. That is not okay. And by no means am I suggesting some kind of asymmetrical relationship is okay just because we all have to have hands across the world and be nice to each other.

So I just wanted to make that very clear in case anyone thought that I was suggesting that the software developers of the world suddenly had to become like the world's unpaid therapists. Like, that is not your job. Ah, poor documentation. This is very sad. How many issues do folks realistically think are the result of poor documentation?

Okay, show of hands. How many people believe that no one reads the manual? This is very sad. Okay, so about half the room thinks no one reads the manual. Of those who said that no one reads the manual, how many of you believe that no one reads the manual

because there actually is no manual? And about half the hands in the room go up. Okay, very fair. For those of you who think that people do read the manual, how often do you think the manual is actually filled with current information that talks about the current release of the software?

There's one hand. Oh, my goodness, you poor, deluded soul. It is not true. It is not true. We create, I think, this feedback loop of sadness with our users because those who are the most motivated to create software are the least motivated to document it, right?

And fair enough. Again, if you are working in that paradigm, it is very sad to have this kind of poor attitude towards folks who are not software developers, who are not technical, who are doing things like technical writing, because clearly technical writing is not technical, who are creating documentation for our projects

and helping people be better able to use what we're producing, right? And for some programmers, for some projects, a lack of documentation is like a badge of honor, right? Well, yeah, there's no documentation, but you can just read the code, right, and then you know how it's working. Well, yeah, sure. I mean, that's true for some people.

I have waded into source code a number of times trying to figure out why something was broken and going like, why am I feeling stupid and inadequate and going like, why can I not make this work? Well, you know, every once in a while you get validated because you're like, hey, wait a minute, I think I found a bug. Like, oh, yeah, you're right. That doesn't work because of dah, dah, dah, dah, dah, dah. It's not you.

Well, wonderful. Thank you. And I'm so excited that I had to pour through like, you know, 2,000 lines of source code to figure out that it was your bug and not my stupidity. Like maybe if there had been a manual, I could have said this does not work as expected. Unfortunately, in order to figure out what was expected, I had to go and perform checkouts and things that I did not want to do.

So poor documentation, I think, is a source of a lot of consternation. So if you are not motivated to document what you are working on, make friends with someone who loves to document stuff. And believe me, those people do exist. And they like whiskey. So just, they really do. So, you know, get whiskey and old books.

So if you can find a used bookstore that has cool stuff in it and a nice, you know, whiskey bar, you're in heaven, right? Go make friends with those people, and they will help you out immensely. Now, let's talk about the current industry darling and how this is the polar opposite of what most people are experiencing with open source software.

How many folks in the audience have heard of Slack? Wow, okay. Have heard of Slack and wish they had never, never heard of it. So there are some free software implementations of the same kind of functionality that Slack has, Mattermost being one of them. So Slack has gained in popularity to a ridiculous degree, right?

So first of all, the startup that has created Slack is now worth something like a billion dollars, which I think is the byproduct of creating a great product, but also Silicon Valley insanity. And, but if you look at Slack as a tool, merely as a tool,

Slack has a core value of helping their users be more effective with using the tool built into the product, right? So you pop open Slack and there will be suggestions for keyboard shortcuts while it's loading, right? And they're not intrusive because they're just all part of the load screen, right?

It's not as though, you know, it's one of those irritating feature tours that will not turn off no matter how many times you say, never show me this tour at startup again. And yes, you click that box and no, it just ignores you. That's not what's going on, right? They have understood that there are non-intrusive ways to slowly but surely remind and educate their users about how to be more effective with what they've created.

Now, this to me is a great development. This is a wonderful and important thing, but it frightens me because there are a number of free software projects who have stopped using IRC altogether as their communication mechanism, and now they're using Slack solely for their communications.

Now, this is problematic for a number of reasons, not the least of which is all your logs belong to some company, which I actually, I have great respect for the folks who work at Slack and I think that they're doing a great job, but I find that development to be problematic, right? We've had this open communications tool since forever and now people are not using it and they aren't using it

because they find that their users and people that they are trying to integrate into their project communities find IRC too hard to use. So how many folks in the audience are IRC users? Okay, about half the hands, maybe more than half the hands are going up. So do you think using IRC is easy?

Yes. Anyone think using IRC is hard? One, two, okay, three. Okay, wow, brave souls who are willing to admit that this is true, that IRC is hard. So I had a very recent experience where I was working with a young woman who wanted to volunteer as a member

of the Open Source Initiative. So I am on the board of directors for the Open Source Initiative. They are the nonprofit organization that approves new open source software licenses and who protect and promote the value of open source software worldwide. So I'm a volunteer there and I was working with someone who wanted to volunteer

to help us find more volunteer help to do work that was good for the OSI, like documenting best practices for open source employment practices and things of that nature. So she came to me and she said, you know, well I have this volunteer plan and here's what we're gonna do and we're gonna set up this Slack channel and we're gonna invite people in for office hours

and it was a good plan. It was a very good plan but I did point out to her that she probably wanted to rethink the plan in the context of using IRC because as the OSI, as the Open Source Initiative, using a proprietary tool for communications with volunteers could potentially send the wrong message and maybe that wasn't the way

that we wanted to go about it. And she said, so what do I do? And I said, well, do you like talking in the browser? And she said, yeah. And I said, okay, great. So there's this tool that's proprietary but if you wanna use it, that's fine. It's called IRC Cloud. You go to IRCCloud.com, you sign in and then, oh yeah, well, okay. So that's great.

So you're gonna sign in with your email address and that's wonderful but then you have to pick a NIC. So a NIC name, okay. And then you have to authenticate to NIC serve and then you have to set your flags so that if you wanna not listen to someone in the channel and like, oh yeah, no, if you just type these commands you can get the manual and she just looked at me

and she was like, why are we not using Slack again? And I felt like I didn't have a good answer for her. Like this is so much overhead for so many people and we're in a place now where it's not like it once was where those who are the creators of technology are over here in their own bubble and there are very few consumers, right?

People who are the consumers of technology at this point are everyone and if we make it difficult for them to get involved in the discussions that we have, we're going to drive them into the arms of something that makes it very easy for them to participate and where it's easy to participate, the rest of us who are deeply concerned with issues

like can we have the logs of the discussion of the software project forever, is this some place where academic researchers studying FOSS are able to get this information and query it, right? If we lose that, there's a problem and we're not losing that because users are stupid, we're losing that because the tools that we use

seem to be so arcane to them and then we turn to them and we tell them, no, no, no, no, no, it's easy and it is not easy, right? There is all this knowledge that we have had in our heads for so long because we've been doing this for such a long time that it just seems easy when really it's not. So we have ridiculously steep learning curves

in open source projects. I love this, this has been, this diagram has been used for all kinds of things. This particular incarnation is a MMORPGs but this I was first introduced to as the learning curve for Drupal. So, and Drupal is considered to be

one of the more user-friendly content management systems out there, right? So we think of steep learning curves as something to be proud of, right? Well you have to work really, really hard and eventually you become a master at what it is that you're doing. And fair enough, right? It takes a certain amount of time and energy invested to become skillful.

We know this to be true. But it's almost like this bizarre hazing ritual, right? Like, well you know, I had to work really, really hard and no one helped me and there was no manual when I did it and you know, it took me forever to figure it out and I had to read all the source code myself. This is not something to be proud of, right? This is not something,

there is no badge of honor in making someone suffer as you have suffered. That's just sad, right? Instead of having these steep learning curves and being like woohoo, yeah that was really hard, we're really proud of ourselves. Again, making it easy for people to engage with us. Not that they should have to do no work, not that they should have to have no investment,

not that they should have to have no effort, but to lower that barrier to entry so that it at least becomes possible for them and they're not one of these poor little people falling off the cliff or hanging themselves at the thought of using your software. Like, no one wants to be at the software project where the cute little stick figures are hanging themselves. It's like XKCD just had a sad moment right there. So, and things that are, I love this one.

Not that I'm a VI user, I'm thinking the Emacs learning curve is great. So, now think about the things that we say are easy, right? So text editors are easy, right? It's so easy, you just want to type some text

and then save a file and you're done and hallelujah. Okay, and then we make fun of people for using tools that are too easy, like Notepad, oh man, you're using Notepad, you're not using like GEdit or, once upon a time I was a happy VI user and now I have submitted to GEdit,

but we talk about people who are using the quote-unquote easy versions of these, the ones where some of the complexity is abstracted away as being idiots or they're using the easy tool but the rest of this stuff is easy too once you just figure it out and this is not, this is not fair. Our users don't care about various key bindings

and learning arcane commands that really made sense 25 years ago, they just want to type a text file and hit save and be able to print it out and not have it go off the piece of paper and wonder why that happened because they do not know about the line wrap, right? We cannot consistently think of things as easy and have contempt for people

when they can't figure it out themselves. It's just ineffective. Instead of getting people through these steep learning curves, I want to get them through what Kathy Sierra, the author of a book called Creating Passionate Users, calls the kick-ass curve, right? So how soon can you help your users kick-ass?

How soon can you help them to be ridiculously productive and doing all the things that they wanted to do with your tool? And as you can see from this awesome diagram, which I mostly like just because it says kick-ass in it, there is a suck threshold, right? There is always going to be a time when you're learning something new that it sucks.

It's not fun. You feel stupid. You wish you knew more, right? These things are just not awesome. But that's fine. The idea is getting somebody through that suck threshold as quickly as possible so that they are kicking ass and then they become passionate advocates for what you're doing and they become contributors. People who feel good about the technology that they're using

will tell other people to use it. People who feel good about the technology that they're using will say, we hope, thank you, if they don't send them to me, and I will explain why they should. People who feel passionate and good about what they're doing are just happier users, and our happy users are going to create happy communities because there's going to be more folks

participating in free and open-source software projects because they understand its value and they feel good about being there instead of feeling foolish or ashamed or like people think they're stupid. Well, that is very fair. So the gentleman has remarked,

and I do not know that I can necessarily disprove his claim, that many people are stupid, so people are passionate about stupid technology. And if anybody was attending Mr. Hawley's keynote yesterday, there was a great deal of stupid technology on display, including the Bluetooth-enabled pregnancy test. Which was not good.

Also, apparently, things I learned, did you know that your Fitbit broadcasts information to any device that is trying to collect Fitbit information? So if you're all wearing a Fitbit and I sync to the cloud, I get all your data. People really like their Fitbits. I could call that stupid. I don't know that we are going to solve the problem of people doing silly things.

I think it's just part of the human condition and why we are always learning. But at the very least, we can assume that people who are passionate about stupid things, like, you're not working on the stupid things, right? So if you're not working on the stupid things, you don't have to spend any time with those people. So at least that's better for you, right? Unless you're getting paid to work on stupid things,

in which case, like, you know, that's cool. You can get a different gig. So I think one of the reasons why we have this issue within our community where we're unkind to our users is because we have this relentless pursuit of perfection, right? We want to create the most amazing possible thing and something that is not stupid and that people will not be passionate about using something stupid.

And this is not only not good for our users, but for the user community. I don't think it's good for us, right? Like, how often have you ever, like, either at work or even working on a free software project, like, worked with a developer who just will not stop working on that feature over there on their own in private because they don't want to show anyone

their work in progress because it's really embarrassing. No hands? Wow, people have really emotionally evolved in my 10 years of experience with this stuff. Okay, so there's like five hands. Okay, well, clearly we have improved and that is lovely. But in my past experience, at least, I've seen a great deal of people who simply,

because there is this relentless emphasis on quality or even this fear of being mocked or shamed or, you know, told that you're an idiot if you submit the wrong feature to the mailing list, right, for discussion, that, you know, people, we have this adversarial approach because we are so focused on everything being so great, right?

The perfect becomes the enemy of the good when really we want something that just works. This is sad and I don't know what it says so we're just going to skip it and say quality is good. We like quality. So I want to conclude with a story that I think illustrates everything that I've been talking to you folks about today

and this is the story of a young woman by the name of Angela Byron. So once upon a time, Google Summer of Code was created and Google Summer of Code, for those who are not familiar with it, is a program in which Google pays university students to work on open source software projects and they work with a mentor from that open source project.

The open source project is usually not technology that's used by Google or any particular company and the idea is simply to give students access to real world software development experience so that when they show up at companies, they haven't only worked on lab projects with like two or three students involved with them and that never had to be maintained, so they get real world experience.

So Angie had always been interested in this whole open source thing. It really jived with her political views as a young woman. She really thought it was cool that there was this notion of free speech as part of the software development process, but she never thought that she would be good enough to be an open source developer.

Those people are geniuses, not like me. She was a community college student. I don't know if there's an analog here in Germany, I guess like trade school, like you go to university for like two years instead of four years. So not as prestigious as a university education. And so she thought it was super cool, but not for her. And then this program came along and it was like,

well, wow, hey, if they're saying that it could be college students, I could do that. I want to apply, I want to be involved. So as part of the first ever Summer of Code, Angie was asked to work on the Drupal project. Groovy. So she wanders into Pound Drupal and says, hi, I'm really excited to be here. My name's Angie and I'm one of your Summer of Code students

and I'm really looking forward to this and I've been writing PHP for this long and I think it's really great and I'm really excited about open source software and this is all going to be super cool and like this is going to be great and I'm really excited and this was the response she got. Go away, this channel is for serious developers only. Now mind you, this is someone who had been invited to participate in the project

as someone with very little experience. This was, this is very suboptimal. Like this is, these pictures by the way are a comic that Angie drew years later to talk about her first experience interacting with the Drupal project. So this is from the horse's mouth as they say. And this was her reaction.

And I love this because she's hiding under a blanket which is, this is supposed to be a blanket. So she just had a miserable time and she was very sad and it was horrible and she went away and were it not for the fact that she had committed to do this like super fancy program with the Google people, she just would have stopped doing open source period. So that was once upon a time in 2005. Today Angela Byron is one of the cornerstones

of the Drupal project. She was the maintainer for, if I remember correctly, Drupal 7. She has been working as a community advocate. She has tirelessly helped to get more people involved in open source software, particularly through onboarding mechanisms like Drupal's Dojo project

where newcomers to the project are paired with a mentor and kind of pulled through that steep learning curve that many people are proud of. And again, if she hadn't had the benefit of that experience that she had to keep going because this was some big fancy project with Google,

we would have lost her. We would have lost her because we would have said, go away, you're stupid, this channel is for serious developers only and you have nothing to offer us. You are not technical, you are not cool enough, users are stupid, go away. And this is why I keep advocating that when we carry these attitudes within ourselves

and this is how we behave, we cut ourselves up from the opportunity of finding the Angela Byrons of the world. We cut ourselves off from the opportunity to learn, to grow and to potentially find people who can completely change the face of our project. And I just want to end with a quick plug too.

When we carry those attitudes, more often than not, that attitude is, you are not enough like me to be cool. You are not a developer like me, you do not understand, see like me, you do not do systems programming like me, et cetera. When we carry these attitudes, what we're really doing is effectively saying, you're not like me so you're not good enough. And when we think that people who are not like us

are not good enough to help us be better, they're not good enough to give us good feedback, they're not good enough to give us something that is valuable and worthwhile, we create stuff that sucks and it sucks because it's only good for us and ostensibly we'd like it to be useful to the much wider world,

otherwise why would we release it to the wider world? And that my friends, is my rant. I am your user, please love me. Thank you.

I love FrostCon because this is the only conference where I actually manage to speak for the appropriate length of time instead of speaking really quickly Oh, I should have told everybody about the international symbol of slow down. If I'm speaking too fast, you should slow down. Well, obviously that's not useful for now.

Excellent. Well, bug filed. I'll announce that at the beginning next time. Folks, are there any questions? Beep beep. Beep beep. Nice man on the stairs. What is your question?

Paper is made from trees. Okay, just checking.

It's easy to say the users have done, they want the wrong things. We're doing something much cooler. Yes. But obviously that's not going to help. That's going to drive people away. And as you say, you're going to end up making stuff for the people making it. How can we get past that to maybe somehow more general?

Okay, so I think to call us that question, the question is how can we interact with our user community

so that they are, instead of asking us for a faster horse, they are asking us for a car. So I think that that really goes back to education, right? And this again is where poor documentation bites us in the rear end. So somebody expects you to work on a compelling, you know, expects you to work on CVS when what you really want to do is create something

that's an alternative to it. You know, the only way that you are going to help nudge them in the right direction is to explain to them very clearly what it is you're doing and why you are doing it that way. And sometimes this is as simple as like a one-minute video tutorial that's like a screencast of going through some common commands using your program so that somebody understands like, oh, this is what I need to do. Often people come to a new piece of software

with a lot of legacy assumptions about how it's supposed to work because of everything that they've used before. And if what you're providing them doesn't look familiar to them, they go, wait, no, no, no, no, I want what I had before. Forgetting all of the pain points that sent them screaming from this horrible thing before to the new thing, right? So, again, taking people through kind of the feature set

and the whens and the hows and the whys, even if it's just really briefly, like it's very easy to pop open your video capturing software of choice or if you're okay with using proprietary software, you can just open up a Google Hangout and say like, here's what I'm doing. Here's why it works this way. Here's why I think this will help make you more productive

or why it will be easier for you to use what I've created this way. Thanks so much. And then you can point people back to that. If someone comes along and says something to you that's very silly, you just, you know, excellent. I see that maybe you have not watched the video tutorial and the video tutorial will take two whole minutes of your life and that is all you need, so go watch it. Education is key, I think. And, you know, sometimes people are going to just ask you for silly stuff

and the best way to nudge them is to nudge them towards somebody's project that you don't like. No, wait, I would never advocate that. Any other questions? Yes, nice man sitting right there.

Yes, okay, so this is an excellent question. For technical users, how do you move them from being users to contributors? So I'm going to start with the horrible lawyer answer of it depends, but I think that one of the ways to make that possible is to make sure that your users are most fully empowered. And actually rather than trying to go into a very long explanation of this,

I would like to refer you to a piece by a gentleman by the name of and the different layers of involvement. And their specific plan for moving users to contributors

had a lot to do with their governance model and how they encouraged participation in the project. So if you were a bug reporter and then you were encouraged to submit a patch and, you know, people would mentor you through the process of creating one, making sure you knew about the style guide. So it was a combination of advocacy, education, and, you know, telling people that they were appreciated.

I think a lot of getting people from going from, you know, drive-by random comment to sticking around is letting them know that you care, right? Like, I actually appreciate the fact that you're there and in turn I would like you to appreciate the fact that I've worked really hard on what I've created. I do not remember the article title, but I will get it for you. I think it's awesome.

Other humans who want to ask things. Machines that want... Ah, up in the back. Hello, nice person. Yes.

So the question is, in order to make sure that people are effectively able to participate in the open source community, do we need to put the user first as part of the design process? Because that seems very rare. And I am going to say yes, yes, absolutely. I think that this is a great idea and we should totally do this. And I appreciate the point that you made about having a responsibility to do that

because I really feel like if we do not put a focus on the end user as part of our software development processes, exactly as you said, people will not use free software. I think Benjamin Mako-Hill's essay about the fact that for a user of free software, the most important feature of that software is that it is free.

And I respect that a great deal, but I cannot go to my family and tell them, please, please, please make use of free and open source software because it's so important because it's free. You know, it respects your freedom. They're going to say, yes, that's great, Blondie, thank you. I just need to edit a text file, right?

And so without that relentless focus on the user and quality for the user, we're going to lose people and I think that has sad implications for us as technologists, but I think it has sadder implications for the way the world works. So thank you. I appreciate your point. Anybody else? Because if not, we can all go get coffee, which, you know, is compelling.

Thank you very much for coming. Appreciate it.