 Welcome to my presentation on from remote first to what they think first. Happy to be here at Open Source Summit. My name is Isabelle Trestfromm. I'm open source strategist at Europizagé. I'm also a member of the Apache Software Foundation and the co-founding member of the InnoSource Commons. I also created Berlin Buzzwords, which is a conference on all things search scalable and data analysis. Now, for decades this conference ran as an on-site conference, like many other events this year. It moved to an all remote format, organized by a little agency in Berlin called Plainschwards, who did an awesome job moving a conference that lived from a lot of hallway conversations and socializing into a digital format. I also created FOSPEC Stage, which is a conference on all things open source. But behind the scenes, think of licensing, think of governance, think of community management. Also, this conference is going to be remote first in 2021. Call for presentations is still open. So if you have ideas, if you want to share what you're doing in your communities, looking forward to your submission. Now, a lot of the ideas in this presentation are based on what I learned at the Apache Software Foundation, in particular at a presentation at ApacheCon in 2008 back in Amsterdam, which happened to be my very first ApacheCon ever. It was a talk by Bertrand de la Cretace on asynchronous decision making. So if you're interested in diving deeper into this topic, I would like to invite you to head over to YouTube after my presentation and watch Bertrand's video on asynchronous decision making, why and how. Now, throughout my presentation, there will be different interactive parts. We will use an other pad where you as the audience can collaborate on answering some of the questions around moving towards asynchronous communication and decision making. You don't need to write down this URL right now. You can head over to it and have a peek into what the questions will be like. But I will show the URL again on all of the slides which have questions on them. Let's get started right away. When thinking about remote working, what is the first sentence that you think of when hearing remote first? I will give you a couple of minutes to think about that. Head over to the other pad and together with all of the other people in the audience, try to brainstorm on what the first sentence looks like when you hear remote first. I thought during the pandemic or during your open source development or even in a corporate setting. Ready, steady, go! One more minute to go. Okay. Now, before going through this talk, I also talked to some of my friends and colleagues what their remote working experience looked like. So here's the answers that I got. There was one human telling me, I lost all flexibility. We moved all pairing to video conference sessions and we pair all the time. It's exhausting. I'm on back to back conference calls all the time. It's worse than on-site meetings. What could have been in email still is a video conference. It's chaotic. I'm making time for the conference call but it doesn't have an agenda or even moderation. But there's also different feedbacks that I got. I managed to get more done. There are less distractions. Colleagues moved to another country. Remote works. So what is the difference between these teams? In order to figure out what happened, we will first have a look at which types of communication you have in your typical office. There's a coffee machine check, which happens to be incidental, unplanned, which also is very informal and which still helps in formation to flow from team member to team member but also across team boundaries. Plus it helps with bonding team members together because they don't necessarily only talk work topics. There is pairing where a lot of mentoring happens but also knowledge sharing on how a certain piece of code works. There's team communication happening at the desk, which is mostly informal but very fast and very speedy in order to get feedback. If you have a question, ask your team members and you will very quickly be able to move on. But there's also formal team communication. Think about scrum stand-ups, think about planning sessions, review sessions, etc. There's also cross-team meetings. Think about architectural synchronization sessions, thinking time deadlines between dependent teams, etc. But there's also company online meetings where there's one human standing in front of everyone else, sharing updates, sharing plans. Everyone else mostly listening, like in a presentation setting. But there's also lunch breaks, very informal. Sometimes people talk about the work, sometimes they don't. Much like the coffee machine lunch breaks mean that information can flow across team boundaries but also team members are being bonded together. And that adds much longer sessions than what happens next to the coffee machine. So with that in mind, with all of those different types of office communication in mind, think about which purposes for communication you can think of. Could be mentoring, could be teaching, what else is there. And after that, think about which properties of communication can you think of. Think about confidential versus transparent, which other properties are there. And we'll give you again three minutes to think about that. The S&P URL still is in the lower right corner. And people go through that and think about how to move that to an online first or remote first setting. Some of the purposes of communication that you could have thought of are, for instance, giving feedback to someone. That's something that within an open source project we are fairly used to. Think of pull requests coming in where you give feedback on how to improve the pull request. There's also a purpose of socializing. Think about the coffee machine chat. But there's also things like resolve and conflict, which is harder to do in a written-only context. There's also things like making decisions. Think about moving towards one architectural path. But there's also things like teaching, motivating people, or simply sharing information. Now, if you think about different communication channels that we are used to in open source projects, it could be something that is either archived or it's something that could be deniable. For project decisions, architectural decisions, all of these should be archived. But some of the conversations likely should be deniable. Think about someone sharing with you where that project is being used, where the users themselves don't want to disclose to the wider public that they are using that project, but they still want to be involved, they still want to contribute to it. Think about communication being transparent versus private. Technological decisions, process decisions, all of those likely should be transparent. Once it goes to people decisions, personal feedbacks, that's something that should be private. Communication channels also can be either higher bandwidth or low bandwidth. Think about meeting face-to-face over lunch that's very high bandwidth. You see faces of people, you see what they are doing with their hands, you see what they are doing with body language. A lot of that is missing in typical open source communication which tends to be written first. So the goals of remote first should be to gain flexibility both in terms of location and in terms of time. So we shouldn't simply take office communication and move it as is to remote communication, simply replacing face-to-face communication with video calls. This won't give us the full potential. Still we want to transform office communication to digital alternatives, but likely we will have to take different paths. What we also want to achieve as a by-product is to increase innovation speeds through transparency. Think about how communication changed in science during the pandemic. Instead of going through a lengthy publication cycle, scientists shared research results as quickly as they could on pre-print servers. That meant that a lot more conversations were made public, it also meant that a lot more mistakes were made public. But it also meant that innovation could move way faster than any time before. For the general public it also meant getting used to scientists making mistakes. It also meant that publications that before had the reputation of being correct and well-checked suddenly meant that there could be errors in there and the entire quality process was transparent and visible as well. So we have to learn that making mistakes is okay for as long as we work to correct these mistakes as we move along. So step one, we want to convert in-project communication. This is what I observe in a lot of typical software engineering projects. If you have a question around architecture of component X, typically the answer is go to Bob, he has the answer. Or it's about go to Alice, she knows why this was implemented. Essentially this boils down to mass media where everyone has to talk with everyone. This scales very well up to a team which is roughly two pizzas sized. But it doesn't scale much larger than that because connections grow exponentially and we've learned during the pandemic what exponential growth looks like. Open source does that slightly differently. Especially in Apache ProTechs what you have is a central hub of communication where everyone goes to in order to ask questions, in order to coordinate and in order to make decisions. At Apache those typically are mailing lists. Some of the properties that this communication hub has to have is that it's public and transparent for everyone. That it's archived and archived is searchable. Plus that every message sent to that communication hub can be referenced with a unique URL that is stable over time. So we want to replicate this. We want one hub that everyone communicates in. Of course in a typical setting you do not have just one project. You have multiple projects, a project unicorn and project kitten. Both of these projects have their own hubs with team members communicating through that hub. Now what happens if project kitten depends on project unicorn and has a question? They no longer go to a certain team member, instead they go to the central hub just like everyone else and ask a question there. What is the benefit of this way of working? It means that everyone standing around is seeing the question. Including people who have the same question but didn't dare to ask. And including people who didn't even know that they have that question but are still interested in the answer. On the other hand, it also means that everyone who could potentially contribute an answer has a chance to do so. So you will automatically tap into the knowledge of more than one human being answering that question. Just recently at my workplace we had a question concerning string comparisons. It went to a dev list and the person asking the question in the first place was very surprised by the extensive answers that he received. Not only on the specification but also on the specific implementations within the JD case themselves. So asking a group of people in that way means that everyone can contribute their perspective. And you do not receive repeatedly the same answer because people know which knowledge already was shared. Of course the same can happen the other way around where project unicorn watches project kitten, watches their releases and gets involved. That's a very nice way of communicating for sharing information. You don't need synchronous meetings in order to share information. You can do this very easily in an asynchronous way. We've seen in open source projects that this also works well for motivating people. Where by constantly sending and reinforcing positively good behavior. People can be mentored towards working in a way that matches well with the project goals. It can also work very well for giving feedback. Also doing so asynchronously means you need higher communication skills than when doing so in a face-to-face manner. Because you cannot see a reaction of the other participants directly. You see it if at all was a certain lack of time in between. It can work well for teaching. It can work well for making decisions. But it's harder to resolve conflicts that way and socializing is even harder. It's archived. It's transparent. But if it's written only it also means it's low bandwidth. But there's a nice side effect to this way of communicating. It means that passive communication is created as a side effect of your day-to-day communication. You don't have to sit down and write everything down. But you can rely on having a baseline of documentation already there. Think about those questions that you receive over and over. Those are already answered in the archive. Will everyone search the archive for the answer? Clearly not. But still you can link to previous good answers and provide them again without having to retell them or retype them. Now is that enough in terms of communication channels? We're here at Open Source Summit. That's not asynchronous and it's not written only. So even in Open Source projects we do have additional communication channels. Which I'll say. The one with the highest bandwidth is meeting in person. It's great because humans are great at reading faces. However it's expensive to set up. Not only during the time of the pandemic. But also because they are synchronized in both time and space. Everyone has to have time at the same day during the same time. Think back towards the brainstorming exercise that I built in into this slide deck. In order for it to be kind of inspiring. It helps to have people fill in the survey at the same time watching each other. And influencing what everyone else is writing. It does work asynchronously. But it's faster and it's more inspiring and more creative if you do it together at the same time. Which can mean thinking back towards the purchase of the foundation where you have people in Asia, in Australia, in Africa, in Europe and in America. Someone always has to wake up in the middle of the night in order to participate. Meetings in person are also of course expensive to set up. Because you have to have everyone at the same physical location. So you have to ship people around the globe. Plus it's not particularly durable. It has to be repeated for every human new to the project. Now you can tell me that you record everything that you talk about. But still if someone's joining your community as a new member after 10 years, having to rewatch everything that was set within those 10 years, that's not feasible. It's very good for motivating people. It's very good for socializing. And because you see people face to face, that's also great for solving conflict. You have immediate feedback. You have an immediate back and forth. There's various stories about contributors to open source projects that had a conflict with each other. So it was then resolved either over beverages or over shared meal. It's fairly informal and it's high bandwidth. We can add video chat to that. It's pretty high bandwidth. You still see faces. Also a likely less body language. But it's still pretty expensive to set up because it needs to be synchronous in time. Plus it needs good technology in order to really work. Plus it's fairly durable. So even if you record all those video chats, having to rewatch them is fairly expensive. If you lower the bandwidth a little more, you can include more people. You can have online group chat. It's also cheap to set up. It's still kind of synchronous in time because what you send are tiny sentences, tiny bits of information. It needs a decent client in order to work well. It's pretty durable. You can search and skim locks. But have you ever tried to deduce architectural decisions from IRC locks or even Slack locks? It's still very hard because it's fairly unstructured. You can add a bit of structure to that, create a web forum or mailing lists. Slow bandwidth because it's usually text only, maybe with graphical emojis. It's also cheap to set up. It's asynchronous. It doesn't need any special technology. Plus it's pretty durable. You can search. You can follow archive discussions. And typically texts are longer, providing more context. Same with mailing lists and a decent client plus an archive. You can add more structure to that by using an issue tracker. It's asynchronous. It's well-structured. But still it's fairly fine-grained because it moves in very small increments. So it can be very hard to piece together the entire picture of an architectural decision. For that, you can use wiki pages in order to give higher level views. Or you can move to something that is very durable but also takes time to set up, which is to provide a web page which gives higher level overviews, not only for first-time users, but also on how to get involved with your project and also on what the architecture of your project looks like, what changes look like. So to summarize, what you want to create is one canonical place in order to keep current status, which should be provided as self-service. If someone is working on an issue, it should be made transparent in your issue tracker. You want one canonical place in order to keep documentation and the goal here is to avoid repeating yourself. Plus you want one place where you track previous decisions. What you achieve by that is that you provide your project with a long-term memory. So what about the coffee machine chat? What we've replaced so far are all of the formal conversations. What about the deniable, informal, incidental communications? Head over to the other pad and think about which types of ways you found in order to replace coffee machine communications, lunch communications in a remote first setting. Ready, steady, go. Giving you two minutes, half a minute to go. Okay, now let's head over to step three, scaling decision-making through transparency. So far we've looked at teaching and resolving conflicts and socializing setting goals, sharing information, motivating feedback. We haven't looked at making decisions so far in detail. I will pick one example which is how to make a meeting with dozens of agenda items take an hour or less. A lot of this is based on experience I've made at the Apache Software Foundation on how they run their board meetings. Okay, what's the secret? The secret is to make agenda items available for reading well ahead of time and the agenda items there doesn't mean only bullet points of what we want to talk about. It's really the bullet point plus all of the content below so that all of that can be read ahead of time. So you don't have to use precious meeting time just for sharing the information on the content that you want to discuss. This is shared ahead of time. Plus you enable pre-approvals. That means if you go through that agenda you come up, come to some agenda item, you read all of the text and your brain says, yeah, sure, approved. Fine, fine by me. Go ahead. You can mark this as pre-approved and if enough people do that it won't appear in the meeting because enough people pre-approved it except when someone says I want to discuss this. So a lot of the items are moved out already by this process. Now you ask yourself certainly there are some items where you have tiny questions where you need a little bit of clarification. In order to enable that, you enable asynchronous communication in order to clear questions. If there's a tiny glitch, if there's a misunderstanding that can be cleared asynchronously before the meeting next agenda item that moves out of the agenda. Now this looks like rocket science, doesn't it? Actually it's not. It's a text file put into version control. This text file essentially is the meeting notes. So you can read through everything that would have happened in that meeting that you know before the meeting happens. Participants can go through and mark writing into this text file which items they pre-with, which items they pre-approved. Now because of course the text file for meeting minutes at the Patria Software Foundation is a bit longer than the average letter page there is a web app on top which reads the text file and which generates comments but at the end of the day it's just a text file. So for communication what they use simply is a teleconference. You can dial into it, there's a video conference part in it where you communicate about that plus they go through that text file piece by piece. Of course again because it's rather lengthy so the web application that helps the secretary goes through the meeting where every participant can follow the course of the meeting in the agenda and where additional comments are being made just in time. Now in order to keep conversation on the verbal channel on topic and in focus what they also added is a back channel, written back channel essentially IOC is like whatever, just a chat where back chatter can happen. All of the socializing, all of the little jokes but also all of the little additions all of the tiny corrections can go to chat where they are being picked up. Now take that to the next level, how to make transparent and open decisions that's mostly based on things I learned at Apache but also from the book The Open Organization. In Open Organization there is a sentence that was really interesting to me in order to drive engagement and collaboration to the roots of an organization you need to get people involved in the decision making process. Okay, makes sense except that at Apache we have more than just three people. Let's read on. While making an executive decision by Fiat is fast but that's when the real hard work starts. This is a funny thing, you make a decision and then the lengthy change process starts at the end of which you have finally reached a state where everyone is working according to your decision. If you manage to engage people in the decision making process this change management becomes unimportant so you start your decision making process and then you hit the road running. So the funny thing is that the leader's role then becomes making sisters and parents decisions integrating everyone but making change management itself superfluous. How does that work? Well in open source we do not only open the software a lot of people would agree with me that simply taking a piece of software that is ready flapping an open source license to it and publishing it doesn't help very much maybe to some extent because it adds to transparency but where you reap the real benefit is by also opening up the creation process opening up architectural decisions as they are being made and opening up towards influence from other players including your competitors. Now you do the same in your organization when you make decisions. You engage with people even though it takes a ton of time you do not only explain what you are doing but you also explain why you are doing stuff. Now if it feels overwhelming at some point in time likely someone is moving too fast making these kinds of transparent decisions and engaging people in this decision making process takes time however those slower decisions typically lead to better results because as soon as a decision is made likely a lot of these stakeholders already have been engaged. In order to do that you enable asynchronous communication in order to prepare consensus. You communicate about an outstanding decision ahead of time and you prepare consensus asynchronously. That means that only those pieces of that decision that are really controversial have to be discussed face to face. So you save precious meeting time for the pieces in the decision where you actually need this precious meeting time and you can focus on stuff that is controversial. You leverage your soapbox in order to poke and prod on issues that you believe are important but you also share plans early and now comes the hard part you share them even if they are half-baked because only that way and that release early release often manner it's possible to receive feedback to refine your plan and to make small and reversible steps. You avoid big mistakes but you make mistakes small and cheap. It also means that you have to create an organization and making mistakes is okay. That way you inspire other volunteers to become active, to help you out and to provide their vision and their knowledge and their expertise in your organization. Now how to do a lot of that is being explained in INOSOS. There is an organization called the INOSOS Commons which is collecting patterns for collaboration and for transparent communication in organizations. It tries to move patterns how we communicate in open source projects into organizations themselves. Essentially what I've once heard people say it's where you go for the patterns but you stay for the community. Careful it's just one step on a journey. The goal is to train more humans in open source practices but not only to make those organizations internally more efficient and more innovative it also means lowering the barrier to get involved upstream. One of the feedbacks that I heard from many people that is most challenging and frightening is the way we communicate in open source. Very transparent. Transparent to the point where our communication is public. Now all our mistakes are public. We have our way of thinking our way of decision making is public. It takes a certain level of training a certain level of getting used to in order to become comfortable in this way of communicating and in order to understand all of the benefits that this communication brings with it including early feedback including learning including getting better including collaborating and communicating across boundaries building bridges between organizations that otherwise would not collaborate. So essentially using those practices means teaching people all of the advantages that come with them in order to lower the barrier for them to get involved upstream. And here's the funny piece it actually works. I do know people who started out working in an InnoSource project and his end became much more comfortable communicating and helping projects in the open source world that they rely on on a day to day basis in order to get their work done. And with that I would like to thank you for your time today and I'm happy to take any questions either synchronously in chat or asynchronously afterwards through whatever channel you would like. Thank you and bye bye.