 We have Treshek and Reshek and they are open source advocates and their talk today will be on their work with investigative journalists and supporting them to use open source software. Thank you very much. So hi, everybody, I think it would be much better if we all moved a little bit closer. It's a huge room and apparently not many people here are interested in free software, which I understand. But if we're here, it will be easier for us if you're all closer. Presumably you have some thoughts that we can talk over a little bit in the Q&A. Also, if you have any questions, we can take care of them as we go. There will be a fair amount of Q&A if you guys have some suggestions about the talk. The more audience involvement, the better. This will be an open source talk. Just try not throwing things yet. So, I am Reshek and he is Treshek, but this will get lost anyway, so don't worry about it. We are two hackers originally from Poland, but now living in Sarajevo and doing weird shit. We would like to talk a little bit about how the free and open edge cuts users, cuts people that try to use it from time to time. There we go, that's a paper cut. This paper cut will explain the difference in a minute. So these slides will be available or are available on CC by SA 4.0, so just go crazy with it. And now, as I said, we're hackers activists, we're in the business of organized crime and high-level corruption. If we have your attention now, we work at the organized crime and corruption reporting project. It's an international NGO that does what it has in the name. We work with journalists, we work with editors, reporters and fact checkers, which are surprisingly, they are non-techies. I mean, it's not obvious that journalists are non-techies. Okay, it is obvious that they are non-techies, but they are non-techies. And what the organization does is we're writing about stuff that happens and how, I don't know, $20 billion got money laundered through Moldova or how a humble cellist from Russia has $2 billion in Panama. Of course, he's a friend of a certain Vladimir, but let's ignore that. But back to the topic. Our use case is very specific, but I believe there are many environments in which the same problems and the same paradigm supply. So we're working with IGE with journalists, but I think there are groups of people that are just non-technical, that are trying to use free software and have the same problems all over again. So we're trying to talk more generally about those problems, but we're going to use our examples because that's what we know. So here's a disclaimer that was suggested to us by Bjarni, who's the developer of MailPile. If you don't know MailPile, you should totally check out MailPile. It's absolutely fucking amazing. But he suggested to us that we should make it clear that what we're going to do here, we are not just trying to rant. There's going to be a couple of examples. There's going to be a couple of rants about how software makes it harder for users to use it. For no good reason. There are some good reasons that sometimes there is complexity that has to be shown to the user, i.e. key fingerprints or key IDs in anything related to GPG or anything like that. But sometimes there are small, stupid, annoying, like the sound paper cuts that just make it really hard, especially for non-techies to use software, and they're so easy to fix, but they never get fixed. So we are... How many software developers we have here? Come on, don't be shy. I can't believe it's just half of the room. So many of us are software developers. Many of us are sysadmins. Many of us have their own pet projects that also have those paper cut bugs, right? Many of us write software... I mean, if we write software, this software will have bugs. That's a given. But we very often don't have the time or energy or resources to fix all of the bugs, right? This is like we're working nights, or we're working on our project as a hobby project, and then we just don't have the time to fix the stupid small bugs. We want to fix the bigger problems. We want to, I don't know, do the architectural stuff, et cetera. And that is entirely fine, and we understand that because we have the same problem. So the disclaimer is, please don't take this personally, right? So we're not trying to shame the developers. This is not the point of the stock. The point of the stock is that we as a community seem to have... seem to value certain things at different levels. And this clashes with what the users need very often, right? We value technical amazingness, right? We love amazing stuff. We love to create amazing, sometimes complicated, sometimes over complicated systems that do something amazing, right? But then when we do the hard part, the thing that we had to figure out, then we leave out many of the details. We leave out the usability. We leave out fixing the small problems because this is not sexy. And we'd like to try to tell you why this is important. So the positive takeaway from all of this is that your software wants to be used, and probably there are people who really hard want to use the software to solve their problem. And they can't because the small problems that are obvious to us, how to solve them are really unsurmountable, without an option for most of the people. Okay, so dear Sir or Madam, do you have a minute to talk about our Lord and Saviour free Libra open-source software? Or why don't NGOs lose floss? It seems like a no-brainer, right? You have an NGO or you have an association. You have a group of people doing something amazing, right? I don't know, fighting for LGBTQ rights or fighting for privacy or fighting for anything. You name it, right? And it seems so obvious that they should be using free software, right? Why should they pay for software? Why should they get locked in into software? Why should they then secondarily lock in their users or their supporters or their friends or people who communicate them into close-source stuff? So one of the reasons this happens, obviously, and I'm sure that this is not only my experience, are requirements that are sent from somewhere above, like the government or the organization that gives them a grant or anything like that, right? Sometimes there is something like that and there's nothing you can do. Sometimes it's a question of familiarity, right? You're a small NGO. You're hiring a person or you're actually a volunteer comes in and tries to help you out. But this person only knows the close-source world, right? And it just doesn't make sense to... It seems like it just doesn't make sense to retrain them to use free software solutions because this will take more time than they have to spend to help you out with the actual thing that you're doing, right? There are many, many different reasons, but one of the reasons, as our experience kind of showed to us, are small, annoying things that are called paper cuts. So who of you have ever heard about the 100 Paper Cuts project of Ubuntu? Okay, we have some... Do we have any 100 Paper Cut developers here? No, no, no. Damn it, I would love to meet those wonderful people. So there's this project within the Ubuntu community called 100 Paper Cuts. It was a little bit more well-known or a little bit louder about itself a few years back. Now it's somewhere in the background, but it's still there. The idea is to fix those small, annoying bugs that bug users. So what's a Paper Cut? First of all, it's a bug, right? It's not a feature. Secondly, it's simple or trivial to fix. It might be as simple as moving a button, just switching, swapping the order buttons on a form, right? One famous Paper Cut, one of the first 100 Paper Cuts that got fixed in Ubuntu was that some GTK applications were using cancel apply order and some were using apply cancel, which meant that if you're just using your muscle memory or using many of the first kind and less of the second kind, you might apply or cancel something randomly, right? You did not want to click here, but you went for the bottom right corner and you're like, oh, shit. Damn it, okay, now I have to do it again and now I have to remember that the buttons are swapped. Damn it, okay. So for us, and they are annoying to the user, right? They're breaking their workflow or attention or anything like that, right? So for us, these things are simple to fix. It seems, right? We are techies. We are people who are like, okay, I understand why this happened. I understand that somebody put the button on the wrong side of things or I understand that something got missed or something wasn't finished or I understand that I have to click here. I have to go through these two additional clicks. But for a regular user, for a regular person that just tries to do their job, they're literally just trying to write a ODT document or they're trying to send an email or they're trying to do something and they're focused on this and they're not techies, right? And then something weird happens that they don't expect and they're taken out of this flow, they're taken out of their focus, they lose their focus and they have to focus on the software instead of the thing that they were doing. And if this keeps happening, if they have to do it every single time they send an email, for example, this takes a lot of their time and this takes a lot of their energy and creates a lot of frustration for those users. Also, sometimes it just scares them off. Sometimes it's not just annoying. Annoying stuff sounds like we're complaining about like this interface not being perfect but this really has an effect of putting people off and scaring them off sometimes. We'll have one example that fortunately was fixed in the stash of examples but they tend to have sometimes an effect of just stopping people from using the software at all. Like they may be annoying or they may be just a catastrophe for the software. So what a paper cut is not, right? As I said, it's not a complex bug, right? It's not an actual, we would call it an actual bug that you have to dive in, spend, I don't know, five days debugging trying to figure out what the hell is actually happening in the software and then fix it, right? It's a simple thing. This is usually not UI or UX design. I use this example of swapped buttons. This is not a UI or UX... I mean, this is not a UI design issue. It's just somebody put the buttons on the wrong side, right? When I'm talking about UI and UX design, I'm talking about people actually sitting down and figuring what would be the best way to do a certain task in software in general, right? Sitting down like, I don't know, GNOME or GTK guidelines for writing software or anything like that, right? Fixing those guidelines, fixing the design side of things is super important and this discussion is already happening but this is not what we're talking about. We're talking about some things that are obvious that should be fixed and then they are trivial to fix. Also, we're not talking, as I said, we're not talking about necessary complexity, right? We're not talking about situations where you actually, unfortunately, have to show something to the user and take the user out of the flow because the user, I don't know, has to verify a fingerprint or the user has to scan a QR code or anything like that, right? There are better and worse ways of dealing with those but these are very often necessary and there's no way around them and we're not talking about them. We're talking about things that, as I said, are trivial, obvious and quick to fix. So the question is why won't you use Floss, right? Why won't you use free software? And from our experience of working with... So the environment that we work in is really peculiar because on one hand we have... We work with about maybe 200 people all over the world so sometimes we do help desk calls at 2 a.m. because somebody is in Latin America and then they need help. But... So on one hand we kind of have to help those people stay safe, we have to keep those people, you know, from leaking something accidentally or using software that will leak that for them but on the other hand we have no way of actually writing a policy that everyone will adhere to, right? The only thing we can do is say, you know what? From our experience this software is better than this, right? From our experience or based on our, I don't know, knowledge you should use this rather than that. For example, you should use, I don't know, signal instead of Skype. Why do people use Skype? Okay, that's a rant. So the question is why don't people use free and open source software and we have no way of forcing them, we can just suggest it or ask them to. And so here's a scenario for you, right? So somebody needs to solve a problem, somebody needs a software for, I don't know, cutting PDFs into separate PDFs or merging PDFs. That's a use case that we've seen. And then we find some free software, free as in freedom and we install it on their Ubuntu or whatever and they start using it, right? And we say, hey, so this is, from our perspective, this is better, this is free software, right? We don't have to manage licenses and other bullshit. We can be actually sure what this does, right? If we have any doubts that if something bad is happening we can just check that. And all the other reasons that us techies, like hackers, free software activists have been using as arguments for decades, right? And then there's this small little thing and the user sits down and tries to print, for example, right? And it doesn't really work. You have to, I don't know, manually, for example, you have to always manually set the size of the paper. The software does not remember what size of paper you have, right? And then it's like every single time and the user works with PDFs, like, with 200, 300 PDFs a day. And this becomes a problem. From our perspective it's like, why is this a problem? Just click on the A4 or whatever and then just, it's done, right? But for the user it's like, there's this weird long-haired guy in a weird t-shirt that comes into the office or writes an email and says, hey, use this software and then this software is just annoying and there's no good reason to use this software. Why should I use this software, right? So there's a disconnect between our motivations and our understanding of software, obviously, and the motivations and understanding of software and the needs of the users, right? And those small little paper cuts very often are things that actually stop users, stop people from using free software, even though it might be better in the long run, even though it might have more features or it might be more stable or anything like that, right? But there's this one single little annoying thing that this user has to click 300 times a day and it just doesn't work. Just because there's too much clicking. There's probably a command line flag to set that, so I wonder why they're not using that. Exactly. Okay, so there's also something that I couldn't find a name for, so we kind of named it internally. We call it the Miranda copout. Let's assume that the name is random. So what is a Miranda copout? Tell me if you recognize this, right? Somebody is using some kind of software for, let's say, audio and video calls, right? And you say, no, please don't use this software. This is not secure. This is not safe. Why? Just use this software. This is better. This is open source. It was audited. It is secure. It is all of the things that this thing is not. And then this user starts using the software and then there's one, the first little thing, the first little thing that is weird or not even a bug. It's just different, right? Immediately is the reason to drop this software. One of my favorite examples is like, oh, but the calls break from time to time. I'm like, okay, that's cool. But do calls break on your old proprietary close source shit? Yes. Do they break as often? Yes. So where's the problem? The problem is that the user already has decided that they want to go back. They don't want to learn something new. We all have the same thing, right? We don't want to have the additional baggage of having to learn new tools or having to learn new things if we have this one thing that we need to solve, right? And we know that there's software that does that. And for some reason, somebody tells us that we have to use something else and it works differently, right? Our brain will say, you know what, let's just find this little thing that, one little thing that we can use as an argument to go back and we'll go back. Moving from Windows to Linux, right? It's the same thing with moving from, I don't know, a proprietary office suit to LibreOffice, right? The buttons are in a different place. These are small things. Many of them are not papercuts. But if you have a person who does the Miranda cop out on a regular basis, then papercuts are at the enabler, right? They will find this papercut and they will use it to say, I will not use the software, it is shit. That's an actual quote. And then you're like, how do I deal with this, right? How do I even try to convince the user if the user has already decided and they have this little thing, this one little thing? We know it's a little thing, but they have it, right? They found it, this little argument, this little papercut of theirs that they will now use against you. So, by the way, do you have any questions? Because we tend to kind of start ranting and as I said, I'd like to have some engagement from the audience. So if you have any questions or examples of yours, just raise a hand. Okay. The rant is very beautiful, but I wonder if we should move to examples a little bit because of the time constraints? Yes. We have some annoying examples and then we have some success stories, I guess. Yes. There's not a lot, but just to illustrate the ranting. Huh? I think I have a papercut. No, it's not. It's just a steep learning curve of Linux. Oh, yes, there we go. Slide shows are hard. Why do you use KDE still? Huh? Okay, I know what I'm going to do. Yay. There we go. Yay. Yes. I think that was a good no point. Jesus fuck. Yes, this is a very good example of papercut, actually. So what is happening here, we had no way of testing this slide show on a two-screen setup when we were making this presentation and turns out that GwenView, which is the KDE image thing that I'm trying to use to show you the examples that we have actually made screenshots of, assumes that, hey, you know what? If you're going to do it full-screen, I'm just going to use this screen. No, I want you to use... No, I'm going to use this screen. I cannot find a way to change that, but we will work around that, because we are hackers and we have ways which users usually do not have. Okay. So first I'm going to talk about this. There is the software, AnyMail, which you probably know that works with Thunderbird. It's a thing that enables email encryption in Thunderbirds, which is a Mozilla email system. So when you're trying to send an encrypted email to someone, you have to have their public key. The only way to get their public key, if they didn't send it to you, is to search for it on a key server. So you go into something in the menu that looks fairly familiar. It's just a key management, and you click, and you're trying to search. But if you search, it really searches through your keys and not the keys on the key server. So it really doesn't do the thing that you wanted to do as your most usual thing. To get their key from the key server, you have to click somewhere and click search for keys, and then it... Can you go back two slides? Can you show the one? Yes, the next one. This thing I love. I totally love it. You have any mail key management, you have search for, and then you have search for keys. What the hell was I searching for earlier? I mean, I understand this. Everyone here understands what's happening on the screen. But if you ask a person that is not a techie to figure out how to get a key from a key server, it's just like, I don't know. If you went through the GPG tutorial like five times in your life and you remember what subkeys are and what are identities and how they differ from keys and all this stuff, you're probably going to get around it, like this interface. But if you're really new to email encryption, you're clueless and this will not help. The good thing is that when you imported the key actually from a file or from a key server, it showed you this. It doesn't show you this anymore, fortunately, because if a user is trying to import a key, he or she really wants to see like a green arrow, like green, you're successful at importing the key. And this happens. And you're... We actually got help desk calls about this. Somebody imported a key. Congratulations, well done. You're being sarcastic right now. If somebody was able, if some non-techie person was able to use any mail to import a key from a key server, I'm like, wow, would you like to work with us in our tech team? And then we got a call about this weird alert box that showed up. Apparently something went wrong. I'm like, no, it didn't. What went wrong is that it's really bad. It's a really bad thing to show a thing like this to a regular user, because this is scary. But it's an alert. What HKP is and what this... Yeah, so fortunately this was fixed. Now it looks like this. And thank you, developers. Well done. Let's have a round of applause for any mail. No, honestly, we need these kinds of fixes in our daily lives, you know, working with journalists. Yeah, this is just one of the examples. The other software we use for the same purpose, because it's really hard, apparently, to get people to use encrypted email is any mail which works with... MailValue. MailValue, which works with online mail systems, with web mail. Anybody here used MailValue or uses MailValue? Where is the... Nobody. Okay. So it has some great things, like if you have keys for people, it's all complete and it's amazing, and there are some usable parts. What happens when you're trying to add an attachment to an email is that you're looking for it and you find it's not really visible at all. There is this small link that says encrypt attachments. It's kind of problematic. It gets you completely out of the flow. You click on it, you're presented with something like this, which is a completely another view and you're wondering at this point what happens. It asks you to add the files. So you add the files when you're done adding the files. By now, you've forgotten why were you even doing this. And where's the email? What I was writing about, what I wanted to... You vaguely remember that you were writing an email, but now you're in some different thing and you don't know what's going on. You added the files, so you succeeded in picking the files, which would have been easier. So now it's asking you about the recipient of your message because you typed that in before, but now you have to choose them again. So you have to remember to add the recipients two or three times if you're sending an encrypted email. You have to add the recipients to the to field or BCC or CC whatever, and then you have to add them to encrypt to in MailVlob, the text edit window, and then you have to add them again if you're encrypting an attachment. Yes. Also, I didn't check it. I don't know for sure, but I'm pretty sure that if you want to be able to decrypt the attachment later on, you have to add yourself to this list because that's how it works. And then it asks you to download the encrypted file, and then you have to attach it to the original message in the original window. Yeah. Yeah, this is like an example of something that... Maybe there are technological reasons, but we can prevail, we can like work around them, and this doesn't make any sense. Also, you will not delete the attachments that you saved on your disk to add them to your message, which creates another level of complexity and another, actually, threats. If you're sending sensitive files, you don't want to have them in five copies on the disk somewhere, even if they're encrypted. So, why... There's a few more, but I think we're running short on time. Yeah, we're running short on time. So I'm going to give you three more just by saying them, right? And these are kind of my favorites. One of them also fixed, EA for signal developers, is that you couldn't send attachments other than media, like videos or images, etc. So you couldn't send a text document or a PDF or anything like that through signal for some reason, right? Now this is fixed, but for a year, this was a huge problem for us, because we have journalists and their sources, they're communicating through signal, thank God, right? But then they cannot send attachments through it. They have to find a different way, I don't know somehow to send a PDF, right? That was a huge problem, right? It got fixed, thank God. Second one is something that I'm hit every single day with. It's who uses K-mail, K-D-E-P-M? Nobody uses K-mail. Good, stay that way. I'm kind of sucked into this software, and what happens is that there's a special key combination to send email, right? You're writing an email and then it's like control enter and it literally says send email now. So I'm hitting this and then I'm showing a dialog box. Do you want to send email now? Yes, this is exactly what I just did. I literally told you to send email now. Why are you asking me this again, right? And I sent a fair amount of emails every day and I know that for a regular user, this would be killing because it's like 200 additional clicks every single day. And the third one is Ubuntu. If you have full disk encryption on Ubuntu, you of course have the unencrypted boot partition, right? For some reason, Ubuntu makes it 512 megabytes, but the kernel package is about 100 something megabytes. So after four to five kernel upgrades, we get calls from users saying, there's something about, you know, not enough space on the hard drive. And then we are like, oh fuck, right, the boot thing. So it doesn't remove old kernels and it makes it very small to begin with and that's something we also have to remember. So the question is why does this happen? We decided to call this the uncanny valley of paper cuts. There are bugs that are sexy, right? There are like, ooh, this is an interesting bug. I'm gonna spend two days or five days debugging this and then because I'm gonna learn something new or because it's a challenge, right? Paper cuts are not this, right? On the other hand, there are bugs that are boring, but they're high stakes, right? They're like, yeah, if this bug doesn't get fixed, it's incredibly boring, but if this bug doesn't get fixed, nobody can use our software, right? And paper cuts are somewhere in between. They're not as high stakes as a serious huge bug that blocks you from encrypting the email at all, right? But they're not as sexy as actually figuring out how to do X, Y, and Z. It's literally a small, annoying thing that you can actually click around usually, right? And somehow we as a community, and again, as I said, we're not trying to blame the developers. We have the same problem. We have the problem of limited resources and limited time and et cetera, et cetera. But I think the broader question is, can we as a community find a way to make paper cuts valuable to fix, right? To make paper cuts maybe not sexy, there will never be sexy, right? But maybe we can find a way of telling the developers we really appreciate the fact that you are fixing those small bugs apart from the large bugs that are there, right? From adding features, right? Somehow we need to kind of channel this good energy towards the people that are actually fixing those small paper cuts because these are really as annoying, as weird as it may sound. These are things that actually keep users from using free software. And here's a short message again from our good friend Bjarni who, as I said, is creating MailPile. He made a very good point yesterday which we decided to include here. We are magicians, right? Hackers, developers, et cetera, we are magicians. If we write software that is used by 10,000 or 100,000 or 1 million people, we might not even know that it's being used by so many people, right? But every hour we spend on this software, if you divide it by a million people, that's infinitesimally small, right? It's incredibly small. How much effort it takes to fix a bug for an individual user, right? But the time that we can save and the empowerment that we can give to the users is incredible. It's tremendous, right? It's magnificent. One hour of developer time for software that is being used widely is incredibly valuable because of the time of the users that is being saved, because of the empowerment, because of the features that the users get, et cetera, et cetera. So, kind of, let's think of us as magicians. We have those magic ones, we have those magic keyboards. We can literally make somebody's life better and it's not just one individual person. It might be millions of people or thousands of people or hundreds of organizations that are actually working every day to make this world a better place. Especially if we focus on the paper cuts, because this is the biggest leverage that we have. We can spend 15 minutes fixing an annoying bug that takes an hour or two hours out of someone's life every day and this scales for 500,000 people. It's the 80-20 rule, right? We spend 80% of our time helping users fix the 20% of the smallest, most trivial problems that they have with software. Okay, so, there we go. So, keep calm and fix paper cuts, I guess. Do you have any questions? Because we would like to have questions. Are there any questions? Or now is the time that you can start throwing things at us. I mean, silence. We put everyone to sleep, nobody's interested. Okay, so, is there a question now? We're going to keep ranting about it anyways. Okay, so I'll ask a different question. Has anyone of you, I'm sure you have, but the question is can we remember, give me an example of a paper cut that you have encountered in software you use daily? Because many of those examples were from our daily use, right? The K-mail thing is literally my daily use. And it took me a moment to actually understand this is a paper cut, right? It's not normal to have to do the same thing twice to send an email, right? Yes, please. I have an issue that has nothing to do with open source, actually. But it's something that you see a lot in computer games. Commercial expensive computer games. First you start a launcher, then the launcher starts the game, then you play the game, then you quit, you get in the center menu and from the center menu you have to quit again. I always have to click two to four times to quit the game. And I know two should be the maximum. Why not just one? Also there are some games where you, during the game you can't load a different game. You have to quit, get to main menu, and then you can load again. Everything takes more steps than necessary. It's super annoying, especially if you're playing the game at work, right? And the boss comes by and you want to quit quickly. Well, I play games only at home. It's a small thing and I keep running into it in almost every game. I think why is this such a standard in game development? Anybody else? Any other paper cuts? No paper cuts? Come on. You all have been cut by a paper cut. A different question. So speaking about games, one of the biggest at-vive of mine is you can't really alt-tab out of most Linux games, which for a platform that wants to encourage people to game, it's very difficult to move from Windows to Linux and then try to play something, alt-tab to your browser while you're doing something, and then not being able to do anything because you lost your mouse or you literally can't alt-tab. And it seems like a very easy solution, a very small paper cut that someone can deal with, but keeps showing up over and over again in all the games. Yep. Okay, so a different question. Does anyone have any suggestions how we could fix the paper cuts? How we could fix the community or change the community in a way that we could kind of channel this good energy towards developers to fix the paper cuts? Yes. Not exactly about the paper cuts, but in the Miranda Coppout example, you said something about people refusing to use the software, not just by paper cuts, but just by different differences. Can you tell us something more about the psychology behind enticing users to use false software? Sure. So we were surprised, and we are still surprised by the fact that... For example, journalists, as I said, journalists are not very technical usually unless we're talking about technical journalists, these are not the ones that we're working with. But they're amazingly intelligent people, and they go through this long process of education and then internships and then more internships and then getting actually good at journalism, right? And part of that process is... At every step of this process, one thing is made super clear, super important to them, and that is they have to protect the sources. Protecting the sources is the most important thing they have to do. The first thing is they have to protect the sources. The next thing is that they might maybe publish something one day, right? Which is an amazingly good thing. But since they have surprisingly good tools to deal with that in real life, right? So they know, for example, that they have to take out the battery from a phone, or they know that when they're going to meet a source, they should make sure that they're not being followed, et cetera, et cetera. But because they're not techies, because they're not technically inclined people and because we do not have media competences in schools, which perhaps we should fix, they cannot kind of move this experience, this knowledge from quote-unquote real world into the digital world, right? So one thing that works amazingly well with journalists is making the analogy, right? Creating the metaphor for them, right? Saying, okay, so you're talking to your source. If you're not using encryption, then basically you're shouting through a room to the source that is standing there. Everybody knows who the source is and everybody knows what you're saying and what the source is saying. And then immediately it clicks. It's like, oh, okay. And then their opsec is immediately better and they're immediately starting to use the software. So I guess the answer is you have to find something that moves a particular user, right? For the journalists, it's protecting the sources. It's super important and this is non-negotiable for them, right? So, okay, that's something we can use, right? Explaining. Not just saying use this, but saying, so this is what happens, blah, blah, blah, something or other. And this is the broader picture. I don't know. NSA is spying on everyone on the Internet. That's why we need to encrypt stuff. That's why we need to use this software. That's why this software is better than that software, right? And even if they are not able to remember everything, just as I would not be able to remember everything if they told me why certain things in journalism are more important than others, they will remember that there is an explanation and if they need the explanation, they will come to you again. It is suddenly not just a random rule that somebody imposes on them. It's suddenly understandable and potentially helpful. Yep, thanks for the question. So, any ideas how we can fix the paper cuts? One thing that I came up with is starting to tag the bugs. Hi. So, I just wanted to add that it's not only paper cuts that make people avoid free and open software. It's also a networking effect. So, you say your video conference application, why do people use it? Well, because everybody else is already using it. And when you say, well, use this, but my friends are not there. Yes. The network effect is incredibly potent and incredibly important and this is why people still use Skype, unfortunately, even though they know that it's what it is. But, right here, we just wanted to focus on paper cuts, right? Just one slice of the cake. Yes. There's another. I'm certainly reminded of a talk I heard years ago at Petsicon. Stephen Pemberton, a member of the W3C, had a keynote where he said that the problem with open source software. Sorry? Yes, I'll turn it off. Oh, this sounds very different. Okay, he said that the big problem with open source versus commercial software is that commercial software is it's written to sell. It has to appeal to the user, to the customer who pay money. So, you have to conquer the user. Most hackers, most open source developers, they write software mostly for themselves. They have a problem. They need the problem fixed. So, they fix it in a way that works for them. And if that means that the interface is complex, arcane, that's not a big deal because they're used to that. And the big problem is that open source developers will have to think in a more commercial way, analyze the little things, the paper cuts, that are not a problem to them, but are still a problem to other people and just make it easier, slicker, polish it, make it look more like commercial software, which might feel a bit dirty for hackers who like it rough. SPL doesn't say anything about selling software. Open source software, free software can be commercial. It can be, but because it's also often available for free, it's not commercialized in the same way. And in a way, we don't want that. That's such a great topic, but these guys have just got to wrap up. So, I guess one more question. So, one thing you can do is try to build up the network of usability designers because recently there's been this upsurge of people who specialize in UX development and stuff like that. And they're becoming more and more in tune with open source and I know this is a bit dirty, but there's a lot of people who do JavaScript stuff, usability in JavaScript and web, and if we can bring them to have a look at our software. Yeah, that would be great because I'm sure there's a lot of people who can easily mock up their designs, but it's just getting them into the projects that's the biggest issue. Yeah, so I think this is, I mean, what I said earlier is that this is already happening. I remember on CCC last year and CCC two years ago there was a whole room for open source designers. Open source designers were just sitting there and saying, hey, just come to us and we will help you to mock up the application or tell you why this particular decision, UI UX decision is a problem. But as I said, we're not talking about UI UX here, even though most of our examples were, I'm sorry. But the problem with the paper cuts is that, so with the design, you can have this wonderful design, et cetera, et cetera, and still have the paper cut somewhere. And they will still not get fixed because they are not sexy. Creating the design is sexy. Fixing paper cuts is not sexy. One last sentence, promise. So I'll just finish the thought from earlier. One of the ways I kind of came up with, but everyone would have to kind of get involved, is to tag bugs that you report on, you know, whichever software you're using as a paper cut. So that's clear. It's easy to find how many paper cuts are where. And it's easy to show, oh, these developers are actually fixing the paper cuts. Thank you, right? Then we can have ways of showing, yes, these guys are amazing. They're not only creating amazing software, but they're also fixing the paper cuts even though they're not sexy. And then we can thank them. But there have to be better ways. Absolutely. And thanks for ending on such a practical example. Thank you very much.