Meet People Where They Are: Four Ways to Spread the Four Freedoms.

In November 2018 I presented this keynote at the freenode #live conference in Bristol, UK. This is a transcript of that keynote.

You can watch the video of the talk and download the slides here on Internet Archive.

Click on the slide images in this transcript for a larger version of the image.

	Hello freenode live. I am incredibly honoured to be the final speaker at freenode live. And it's also kind of intimidating, you know? Because we've seen so many amazing speakers, and inspiring talks. I mean, Neil just before this. Having to follow Neil? Are you kidding me? I'm very honoured to do this. I will probably not go the full time, so we can either do some Q&A or you all can bugger off and go to the pub. But this is me, and for those of you in the audience who know me (or know of me), you will probably not be too surprised that I have _Opinions_. So because of that it's possible we might go the full time. I dunno. Let's find out! Let's learn together! So exciting! Regardless, though, of whether I go the full time or not, hopefully this presentation will give you something to talk about later in the pub. Now, I'm going to start nice and easy with some softball questions to the audience. Three of them, starting with number one:
	By a show of hands, who here believes in open source and free software? OK. Everyone else, I'm guessing, is just posting on their Mastodon.
	So, next question, 2 out of the 3: who here would like to see more free software in the world? Yes, this is the audience participation portion of the talk. Hands down. Big surprise, pretty much everyone…as far as I can see, because I'm going blind up here.
	Now, third question, third and final question: Who here knows what free and open source software is? So, hands down. It might seem like a weird question to ask considering the audience here. And hopefully y'all playing along at home on the livestream were raising your hands too. So it is a weird question to ask in this audience, but…I'm finding out, more and more as time goes along, that it is something that I need to ask, because it turns out that it's knowledge that we need to revisit and we need to refresh. Because as Kyle pointed out earlier, there are a lot of people in our midst who haven't been doing this for as long as I have. I've been using free and open source software and contributing and participating for like thirty years now. There are people who haven't been doing this for as long as he has, or Christel, or any of us. They're new people, and they've kind of been learning this as they go along. We, who've been here for a long time, we understand what free and open source software is, but others may not. They *do* have a sense of what free and open source software is, but they've gotten that through a sort of telephone game of the definition, and they learned it from someone who learned it from someone who learned it from someone who learned it from someone. And at the other end you end up with a message and a mission which is not quite the same as the way it started at the beginning. So it is more important than ever that we all start today—and, I guess, since I am at the end of the conference—on the same page as far as what free and open source software is, and that we revisit it. So guess what? We're going to do a little revision here. Here's a quick refresher course before I get started with the actual content. Because it's going to inform everything going forward.
	Number one: What you see behind me in a great big screen—isn't this beautiful!—what you see are huuuuge Four Freedoms. These are the four freedoms as defined by Richard Stallman and as defended by the Free Software Foundation and by anyone who believes in free software. Now, I don't think it's a stretch to assume that everyone in this audience probably knows these. They may not be able to rattle them off at pub quiz or something, but you know them.
	So, you all know these, but what I'm learning is that fewer people are familiar with this. What you see here, this is the Open Source Definition. It's maintained by us at the Open Source Initiative, and it is accepted round the world as the single canonical definition of open source. Yes, there is one, believe it or not. Now, the Open Source Definition is buit upon the Four Freedoms, they're right there at the very beginning of the Open Source Definition, but it's also built upon the Debian Free Software Guidelines. So thank you, Debian community, for really blazing that path for us. We're really very grateful to you. Now the OSD—the Open Source Definition—it details what it required of any software that calls itself "open source." This defines what the term "open source" even means. You have those four freedoms at the top there. Your free distribution, you have to get the source code, you can create derived works, you also have to maintain the integrity of somebody's creation, so you can't take their work, strip their credits out of it, and present it as your own. That's not open source. You can't disciminate against people and how they may use the free and open source software project, the open source project. You can't discriminate on how they use it, or what they do with it. So an open source project cannot limit someone from using that project in a way that the maintainers may believe is incorrect according to their ethics and their beliefs. An open source project must allow the freedom for people to make money off the project. All of these are freedoms that we're ensuring that everyone will be able to use. As the software is distributed, you absolutely have to have alicense in there, otherwise nobody knows the responsibilities they have under that license, and they can easily transgress and do something that's counter to the license if you don't have it there. But that license itself, it can't be specific to a project. It can't be specific to a product. It can't be specific or otherwise restrict software. So you can't, for instance, release a piece of software, call it open source, and then say it's not allowed to be run on Windows. That's not freedom. That's not giving people the freedom to use the software as they need. That license must also be technology neutral. So if there's something you don't believe in—perhaps, say, missile guidance systems—that's a technology that free software and open source software must be allowed to run on. And it's very difficult, something we have to deal with in free and open source software, how our projects will be used. But that's part of freedom, allowing people to do these sorts of things. Software that does not provide for every single one of these ten items—none of them are optional—but software that doesn't provide for that cannot be called—literally by definition, it violates the definition—it can't be called "open source." And this is something that we have a big problem with in our world right now. That people provide the source code, so therefore it's open, right? No, because you don't get ensured these freedoms, that come with open source software. Now, the way that you can ensure that the software that you're using, that the software you're releasing is actually open source software is by making sure it has an OSI—an Open Source Initiative—approved license. Now why is that an assurance? Because people come to us, and they give us a license, and they say, "Hey, can you review this?' and we're, like, "Sure! This is what we do! We got this." So we take your license, we take the Open Source Definition, and we compare them. Does your license provide all ten of those items? Is it a match for the Open Source Definition? If so, then we approve it and you know that any software that uses that license provides these things. If they don't fit, we don't approve it. You can still use that license, but there is no guarantee that it will provide these things. So the only true guarantee is to use an OSI-approved license and then you know—you and all of your users—get everything on this list.
	So that's pretty great, right? Everyone in this room probably agrees that the Four Freedoms and the Open Source Definition, these are great! These are good things, yay! And as good things, they deserve to be widely adopted, and widely used, by aaaaall sorts of people. All of us, we feel this way. And we, all of us, in this room and watching on the livestream, we share a mission to increase free and open source adoption across this world. All of us. And it's great.
	But…despite that…as the overall movement, we keep tolerating and accepting things that work against that mission of spreading free and open source software. It's not doing us any favours. You've heard a lot of the speakers in the past two days talk about this, and I'm just sorta here to wrap them all up.
	For instance, it is unfortunately typical for projects to be horrible to their contributors.
	The things I'm showing you on the screen, these are just a few of the stories people have shared with me about their experiences trying to participate in a variety of free and open source software projects.
	Now, I really do wish I could say that these stories are outliers, that they are exceptions to the rule, but the majority of the stories—almost all of them I've received, not just recently as I was gathering information, but over my thirty years—they're like this.
	The sad truth is that each and every one of you in this room, watching the livestream, you all either have heard of or yourself unfortunately experienced stories just like this.
	But that's not all, because as badly as many projects have been known to treat contributors, there are even more projects that—intentionally or not; frankly it doesn't matter—but, they are downright hostile to the people who are trying just to use the project, not even contribute.
	It's safe to say that the user experience of many pieces of free and open source software is not optimised for the users, but rather for the developers, for the people writing the code rather than the people using the software.
	This developer-centric perspective, it often leads to this weird disparate mismash of user interface paradigms and reinvented wheels, and an abundance of user confusion, so people are turned away from even using the software.
	This "by free and open source software developers, for free and open source software developers" mindset, it limits the number of people who can reasonably use our software. And what makes sense to a developer, may not make sense to others. And sometimes? It doesn't even make sense to other developers.
	As well, we have a tendency to vias only for people using free software solutions. By limiting our support only to free software, only to systems running free software, we have similarly limited the number of people who might use and eventually even support free software. All of these stories I've been showing you, each and every one of them, point to an area where we can do a better job. Many areas, where we can do better jobs bringing people into the free and open source software fold and sharing free and open source software with more people. One of the things that has really stuck with me from the talks I've heard in the past few days was John Sullivan yesterday. He was talking about—sorry, John, to call you out there, but it's a good thing—he talked about how people keep saying "Yay, free software has won! Open source has won! We've got corporate adoption, woo, go team!" But he pointed out that that's not actually the mission of free software. Free software isn't winning until everyone is able to experience the freedoms that come with it. And we have fallen very, very short on that. A lot of that is our fault.
	A lot of you out there, sitting there thinking, "Not me. I do a great job. My project is awesome." You're thinking that, and I'm just gonna get right out in front of it and go, "Yes! I know that." There *are* FOSS projects and people who are amazing, who are doing a really good job of this. They're bringing in new contributors, and they're being kind and helpful and mentoring. And they're writing excellent documentation. And they're studying usability, like Neil said for GNOME. They're actually doing usability testing. Lots are starting to look at accessibility testing as well, to capture that 25% of humanity that has some sort of disability. Twenty five percent, and we ignore them. However, enough projects *have* been that bad, and it's been going on for so long, that it's given the entire movement a bad reputation that we all, each of us, can work to improve. Now I know this because most of my work is outside of the movement. As a freelancer, I help companies understand, use, contribute to, and release free and open source software in a way that's both good for their bottom line—because they have fiscal responsibilities—but also for the community. And they look at us, and they don't understand. They want to understand, but they have a bad reputation associated with us. My job is to help correct that, and I do it one company at a time. It's good, and it's helping, but even if you're really good at this, I'm sorry, but you're being painted with the same "bad reputation" brush.
	So, we can do this, all of us can help to improve the reputation of free and open source software. I mean look! "Improve" is right there! In the Four Freedoms! Improve! We have the freedom to improve, so we shouldn't just apply it to our software, but also to our movement itself. These freedoms up here, and these benefits here that I've listed among the others of the Open Source Definition and the Four Freedoms, they're as important and relevant today as ever, if potentially not more so. Fighting for the freedoms and resisting in the way that John mentioned yesterday.
	These are so worth sharing. They're so worth spreading. But by turning a blind eye to discrimination, to unkindness, to poor usability in our projects, and in the projects that we ourselves use… In tolerating this. we are what we tolerate. By tolerating this, we, each one of us, we are all guilty—myself included—we're guilty of holding free and open source software back from meeting its full potential.
	But…every single person in this room, we're all positioned to do something about it. We all have the knowledge and we all have the passion to do something about it. If each one of us just lifts a little bit, we can all lift free and open source software up to its full potential. We can do this. It doesn't take much. Baby steps are still steps. Every small positive you do adds up in a massive way.
	The very first thing we should do though, is we need to start recognising that a ton of free and open source software is carrying so much baggage, and that baggage is known as Privilege. I listen to people constantly talk about this and all I can do is go, "You're not looking at other people's perspectives. You're holding free software back by not admitting and recognising the privilege of free and open source software." It is a Privilege to have the free time to learn how to program, or the resources to afford to go to university or hacker school to learn how to program. Many people don't have that time or those resources, but without programming knowledge it's completely impossible to learn how to use a lot of free and open source software, even the stuff that's consumer facing and supposed to be user friendly. It's not. The first time something goes wrong someone is in the deep end and they're going to drown. It's a Privilege to learn how to use free and open source software, to have that time. It's also a Privilege—it's a massive Privilege that we in free and open source software that we really need to address right now—it is a Privilege to be able to make the choice to use only free software solutions. It's a huge Privilege to say that, because most people in the world are not in a position where they can dictate what software they use to make their living. They don't have that freedom. They have to keep food on their table. They have to keep a roof over their heads. In America they have to pay for healthcare for crying out loud. And if whatever job they have requires they use proprietary solutions, well by gum if they're not gonna use proprietary solutions. They're not going to stamp their little princess foot and say, "No, this isn't free software." No, they're going to use proprietary solutions and they're going to feed their family. The freedom to choose FOSS is a Privilege. Please recognise that not everyone has it. So we do need to stop and step back and look at the perspective of all of those people who aren't using FOSS. Why not? Why aren't they using it? Acknowledge the privilege we have to make the choice to use FOSS, and figure out how we can start sharing that privilege with others. How can we make it easier for them? How do we reduce that privilege barrier? Because FOSS, as John said, it's never gonna win until all people can experience the freedoms that it can give you.
	So where do we start? It's actually really easy. There are four things—four—four places I think we can apply our actions, our care, our passion. Obviously there are tons of things that we could do, so many to increase the understanding and adoption of free software outside of our little bubble, where it's currently staying. There's lots of things we can do, but right now we're in a bubble where we know where it is, we understand, but others don't. How do we spread that out? If you don't know where to start, start with these. And, yes, I'm going to go into these in more detail because just four nouns, who cares, right? Nouns, yay.
	So, Applicability, Usability, Inclusivity, Humility. Thse are great, but before I go into telling you what they mean, I need to make sure, again, we all keep this in mind. This is the goal of everything we should do in free and open source software. This is it. We have to increase FOSS usage and adoption if we want people to experience those freedoms, if we actually want FOSS to win. Yeah, we could do things like focus purely on contributions, or government, or whatever. But where I think we can make the biggest splash is in your common folks. The people who bag your laundry, the people who are making your cupcakes, these are the people who don't understand and can actually get a lot of benefit out of open source software. How do we bring FOSS to the broader population? Well, it's in those four words, and I'm going to start with the one at the top because that's the way I roll, with Applicability.
	Now how do we make FOSS more Applicable to more people outside of our little bubble? We all know how we can apply FOSS to our own lives; we do it all the time. But how do we do it for others? Right now, many—but again, not all, but many—are built by FOSS developers for FOSS developers. And that's gotten us really far to this point, but it's time to branch out.
	What do non-developers, what do non-technical people need in their software? What do they need? If we target those less technical users, then people will like us. It'll be great. So target them. Try to figure out what they need. These people may sympathise with the philophies with free and open source software. They may actually sympathise with that, but they don't care. Now why don't they care? Because they have problems they need to solve, and the FOSS isn't solving the problems that they need to solve. So we should take the time to learn how to communicate—as Kyle said earlier in his keynote. Learn how to communicate with people not like yourself. Listen to them. Don't _speak_ to them, _listen_ to them. Listen to what problems they're trying to solve, and then build solutions to solve those. This, this people is how you win hearts and minds. Not with the philosophies and the mission of free software and the Four Freedoms. Most people don't care about that. They care about their problems. So if you solve their problems then you'll have an in-road, and now…now they start to see how Free Software can help them. Now you can start talking to them about the philosophies of Free Software, because it's real for them, and they'll understand.
	The next of our four little words is Usability. As you are looking to solve those problems, make sure you do it in a way that makes sense to those less technical users. Believe me, you will also be helping the technical users as well. Neil was talking about how GNOME is actually designed for usability. They have UX people, UI people. This isn't just for big desktops. This is for all projects. One of the great things that we're starting to see in free and open source software, and as Neil alluded to in the answer for his final question, one of his final questions, is that they're starting to see different kinds of contributors. Now this warms the cockles of my heart, because it's something that I try to do. I wrote a whole book to try to get new types of contributors to free and open source software. But it's something that you can do. So actively recruit UI/UX people. They're out there, and they probably want to help, but you gotta ask them. Because to this point FOSS has looked entirely by devs for devs, where the word "devs" does not include UI/UX, doesn't include infosec, doesn't include accessibility, doesn't include a lot like technical writers. We're starting to get those people on board, but you gotta go ask them. And then they'll realise that, "Oh, I am welcome; they do need my help."
	But if you can't find them (because there's not a lot of these people and they're probably quite busy, especially after all y'all go out and start recruiting them), at least consider this: Consider this principle in all of your interfaces. Command line, API, graphical user. I don't care, it's an interface. Don't surprise people. Oh my gosh, the number of times I'll pull up a piece of software and go, "Where…how do I…uh…this isn't like the the proprietary thing everyone knows already…" Because you're trying to be original. We don't want to be like the proprietary shit, do we? No! We are FOSS! I'm sorry, but other people know the proprietary stuff. They're familiar with it. Use those UI paradigms and people are more likely to use your software. Kind of interesting, isn't it? People will use the stuff that they know?
	Another piece of usability that we are sooo bad at is documentation. And everybody knows this. We keep beating the documentation drum, but it never seems to sink in. I know writing is hard, and writing well is very difficult. But…writing user-facing documentation, simply about how to solve those problems with your software…writing that? It allows the users to do a lot more things on their own. They don't have to come to you and ask questions. That increases your bus factor because you're not the one constantly being pinged with "silly" questions about your difficult to use software. So write the user facing documentation. People can then self-service. You know what's great about non-technical users self-servicing in free software? It's that they feel accomplished. "I did a thing! I solved a problem! And I didn't have to ask anyone! I didn't have to go to my technical cousin to get this solved. I did this on my own. I am badass." If they feel badass, they feel well disposed towards your project. They're then not only more likely to continue using it, but they're going to tell all their friends, and their family, and they're going to continue feeling badass because they can help other people. But you have to allow them to self-service and documentation allows you to do that.
	Word number three: Inclusivity. Now, there are billions of software using individuals on this planet. Billions of them. Tons. We want to welcome them to Free Software. Well, if we're going to welcome them to Free Software, we have to _WELCOME THEM_ into Free Software. This means understanding and accepting that others outside of our little bubble have different experiences, different needs, different skills. It means considering those experiences, those needs, those skills and putting them before our own if we want to bring these people into the fold.
	For instance, please stop bashing Windows users. Platform shaming is terrible. Windows is far and away—like light years away—from any other operating system as far as adoption. It's huge. Don't argue with that; it's a fact, Jack. So just accept it and support its users. Support people who are using other platforms. If you can build your FOSS projects so that they work on Windows and so they're easy to use and they solve the problems…you know what you've just done? You've infiltrated, and you've opened the doors to a potential flood of new Free Software users. But if you only limit yourself to things that run on free platforms, you will shut those people out and they will never experience the freedoms of Free Software.
	I do a ton of work with people who want to be new contributors to FOSS. It probably—unfortunately—isn't a newsflash to anyone in this room that we have a terrible reputation. Even projects that are usable…again, I mentioned this earlier, that one big brush we're all being painted with. Usable, helpful projects get painted with the big brush of a terrible reputation. New contributors are absolutely petrified that they're going to show up and be raked across the coals and treated like trash. This kind of ties into a question that came up in Bradley's excellent talk. I wish he were here. I loved his keynote yesterday about why people are choosing Slack instead of IRC. And afterward, in the Q&A section, people were proposing reasons. Here's why people are using this. And maybe they're using it because of that. And maybe, you know, emoji (I love emoji). I'm sorry, but this is a solved problem. James and the amazing people at IRCCloud have made a really great client that's just as good as Slack. So…it's not a technical thing.
	None of the people after Bradley's talk mentioned the real reason why people aren't going to IRC. Again, this isn't anecdata, this is actual data that I'm hearing from real live people. I speak with those new contributors. I speak with people who have been around for a long time and who have left IRC. They all tell me, each and every one, that the reason they left IRC is not because it's old and crufty. That's not it. It's not because it's hard to use, because these are really intelligent people. They can figure this out. That it's difficult to use isn't a problem, because if they can see that it's serving a purpose then they're OK with the fact that it might be a little arcane. No, the reason they left IRC and that they don't want to show up at all is that IRC is overflowing with trolls and assholes. Every single one of them says the exact same thing. I'm saying the same thing thing from random people whom I hadn't met before. There are some channels that even I won't participate in because the community of those channel has allowed trolls, and assholes, and assholery to flourish. And I just won't go because life is short and once I spend my time it's never coming back. I'm not spending it on those people. And that's what I'm hearing from people. They want to participate in IRC but they won't. That is why IRC is losing to Slack. It's not technical, it's social. For good or ill, Slack is a gated community, whereas from the perspective of new contributors, IRC is Mordor, and they don't want to be anywhere near it. So it's not about the technologies or the licensing or the freedom. Again, it all comes back to the experience, and the bad experience people are having, and the worse experience they want to avoid.
	So, CoCs—codes of conduct—can help with that, but only if we learn how to enforce them. Having a piece of piece of paper doesn't mean anything. OK, I know, you probably don't print them out but work with me here. Enacting codes of conduct is fine; enforcing them is better. In order to enforce them, though, we do have to do some of what Kyle was mentioning earlier, which is learning how to communicate with people. I love the example he used, where you will argue about top posting and inline, or you'll quote to him chapter and verse of the Klingon rights of passage. Those are things you learned. Communication is another thing that we are perfectly capable of learning. As he said, the human protocol, you can learn that as well. It's hard. Not as hard as actually having those difficult conversations. I have them all the time and they're not fun, but they're always necessary and they're always important to have. You can learn this. As you're learning these things and as you're starting to enforce your codes of conduct, recognise that ignorance is far more common than malice. It's more likely that somebody didn't know there was a line there before they stepped across it. It was just ignorance. They didn't know they were doing something wrong. So as we enforce our codes of conduct, doing it with empathy and coaching people rather than chastising them will make everything a much more pleasant experience. But…also…it is vital that we know where to draw the line. That means instituting a No Asshole policy. People who refuse to learn how to play nicely with others, after being coached multiple times, they must leave. Full stop. If they can't behave, they make it a toxic environment for everyone and one bad apple really does spoil the lot. They are free to leave, and no, your project isn't going to suffer even if it's a core maintainer. Yes, your project might slow down a little bit, but that's OK. Because overall, it becomes a healthier place and you're more likely to start attracting more contributors. By doing this, each time you improve your community in this way, you also take just a little piece out of that bad reputation of all of free and open source software. You're helping all of us, and that's great.
	Now the fourth little word here is Humilty. We must remember that even to this point it's been by FOSS devs for FOSS devs, we can't do that anymore if we want to expand, if we want more people to love, use, and understand open source software and experience those freedoms. FOSS isn't just about you, it isn't just about me. FOSS is about us. Consider the needs of other people, and the impact that you and your actions and your software has on other people. The experiences that other people have when they use your free and open source software project, when they interact with you and your community.
	Most importantly, please stop expecting people who aren't Capital T Capital B True Believers, stop expecting them to understand and use free and open source software. People who don't know, people who don't understand, and whose needs are not currently being met, they will not join the movement. They're just not going to do it. Why would they? Because it's the right thing to do? That…doesn't solve their problems. By not meeting people where they are, recognising where they are and meeting them there, we are closing the door to most of the software using population of the world. We want to grow the use and adoption of FOSS. I think everyone in this room probably wants to do that, right? If we want to grow that, we must go to these people, discover what their problems are and their needs and their reactions and their problems…just figure that out. Rather than waiting for them to come to you to find your solution, go to them and offer them a solution. "Hi, I see you're having a hard time getting wifi in your area. We've created this thing that's free software. Let's set it up." That's a problem real people have. How can we solve it? Is there a solution already? Great! Find those people and offer them a solution rather than expecting them to find you.
	By focusing on these four little words, and through understanding and having empathy with others and a user-focused approach, FOSS can reach and influence those billions of people. All of us together, we can reach billions of people. It all starts here in this room. We can do this. Baby steps. We can do this.
	These slides are already available here at Internet Archive. I want to thank you all so much for being here, for building and maintaining and supporting free and open source software and everything it means to the world. Thank you freenode live for having me, and especially huge thanks to every freenode volunteer who has been working not only this weekend for this event, but every day of every month of every year to keep the freenode service running. Thank you, you're all amazing people. Officially I have seven minutes left. If anyone has any questions…but not comments concealed as questions. I will repeat the questions so we don't have to make poor Nathan run up and down the steps some more, so applause for Nathan for running his ass off. Are there any questions? Q: I see lots of rejections of codes of conduct in place of, for example, the controversial no-code of conduct with "don't be an asshole end all." How important do you think it is what behaviour is not assholery? A: The question is about codes of conduct. There is a lot of push back about having a written and defined code of conduct, about what is and what is not good behaviour rather than the standard (and I'll be totally honest about my opinions here) and totally fucking bullshit "be excellent to each other" code of conduct. The thing is, "excellent" means different things to different people. If you are very explicit about "no unwanted physical attention, no unwanted even mimicked physical attention, no this, no that" whatever your community says is not what we do here…if you're not explicit about that, then someone's going to Rules Lawyer you, and you're going to have all sorts of bad actors. If you don't want bad actors, be very clear, "This is the line, don't cross it." You can't do that if you don't draw the line, because otherwise no one knows where it is, it's really wibbly-wobbly. No more questions, so you get to go to the pub early. Thank you, everyone.

---

📣 Like what you see? Hire me! 📣

I can bring my decades of experience and knowledge of business strategy, software development, servant leadership, and open source to your organisation.

Check out my resume then contact me today!

---