 Hello everyone and welcome to my talk today for opens and the open info way. I am Kendall Nelson. I am a senior upstream developer advocate. And I work at the open infrastructure foundation. I'll blow my name you can see a few different ways of contacting me. I'll have them up at the end at the end at the end of the presentation. If you happen to have questions for me that we don't get around to answering today. So, like I said, my name is Kendall Nelson I work for the open infrastructure foundation. I have been there since about 2016 I think. But I actually started working on open stack before that in 2015. And I have also added Kubernetes to my list of open source projects that I contribute to, and I started in that community in about 2019. And I have had the pleasure of doing talks at a number of conferences. At the open source summit in North America in, I think it was 2020. I did a talk with one of your singer, and I have spoken at the open infrastructure summits. I love my con Z a variety of coup cons. I, I love to travel which is one of the things on this last bullet point. I love Dr who Harry Potter, I've been getting into running during the pandemic. So, I've a lot of things that I do, not just open source but open source definitely has a special place in my heart. So, it's a pleasure to be here and talk to you all today. What are we here for today. Well, the four freedoms kind of give way to the four opens, and the four opens along with the three forces make one opening for way. And I'm totally aware that I'm giving away my whole presentation today. And also that this sounds a little bit like some Jedi teachings with freedoms and opens and forces and the way but there's a lot of information packed in here and I'll try to spend time digging into each section. And without further ado, let's get started. Let's jump in. But first, some history. When we think of open source, we don't normally think about where it comes from just what we want to get out of it. So we think about the marketing aspects like what do our customers want. We think about, you know, getting some software for free maybe which is exciting. Or perhaps you actually think about the community of people that surround the software that are there to answer your questions and help review your code and that sort of thing. But whatever it is, you're not thinking about the history. Where did it come from. So this concept of the, the four freedoms, I guess originally it was three and then became four came out, I don't know, early 90s, 80s, a long time ago by technology standards. And they tried to be really clear about defining open source and and the methodology behind it so you have the freedom to run a program as you wish for any purpose. The freedom to study how that program works and change it. So it does your computing as you wish. So you have the freedom to redistribute copies so you can help your neighbor, which is kind of what we all think about with open source like giving software away for free, or at least that's what I think about. And lastly, the freedom to distribute copies copies of your modified versions to others. So that's another facet of it. It's a really good starting point when thinking about open source, but there are some holes in this when you are trying to use it as guiding principles for a community based around a software. So you don't see anything here about how the software is going to be built, or what that community is going to be structured like, and there's nothing about how collaboration is actually going to work. So moving from here, you have the four opens so I'll introduce each one of them, one at a time. And first, we have open source the most you think straightforward of the four, but we'll, we'll dive right in here. Open source, when open source was defined in 1998. Hey, we have an actual date here. It focused on like a particular angle of approaching the the concept, and it was based on those four freedoms. They like played off one another. So that one specific angle that it approached was the one that mattered most to businesses, which makes sense because open source, like, was a really compelling interesting thing that had maybe started, like, on individuals computers and sharing the software and then businesses were like, hey, we can profit off of this and let's define it and so open source. So the availability and reusability of the code are at the top of the most important concepts for the definition, but as things evolved by like 2010 ish most open source projects were actually closed some way or another. It wasn't the most obvious and straightforward so part of the four opens methodology is using this Apache 2.0 license, because it is OSI approved OSI standing for the open source. Oh my gosh, the open source initiative. And they're a great group of people and do a lot of awesome things if you're interested in them. But it's also GPL v3 compatible and DFSG compatible. And if you want to know what all that means, you're probably going to need to go look up licensing complexities because I don't think we have time here today to get into all of that, but specifically, all of this says that if you're doing open source you're following this open source methodology of the four opens. It means that it's not open core and open core means that a company or business or whoever made the software will let you see the repository and you can, you know, clone it and whatever. And they won't accept any of your changes. So, and they might not actually open source all of the code either. So, they maintain the bit that makes it work. The most important parts, they don't let anybody get involved. So it's, it's open core. It's not open source. And this also means that there's no enterprise addition. That's just kind of another way of explaining it. So open source, pretty straightforward, kind of, because, you know, got to avoid the different ways of things being closed, but that Apache to license is definitely a good place to start. Our second of the four opens, as we move down this path that totally sounds like a Jedi order or Jedi teachings or something. So you have open design. It is complicated because it's inherently opinionated. It's not easy to do everything in the open and to keep it done in the open and be receptive to all of the people involved. It just requires a lot of thought and being very diligent about how you're doing design. So that the product in the end when you put all of this effort in ends up being a better product that better fulfills the needs of its users. So why would you not want to do this. So as part of the design process you set requirements and that should be done in the open and you propose specifications for new features or new functions in the code and those should be reviewed and iterated on openly just the same as you should be doing for the code. Priorities for where you want software to go building that roadmap, all of that should be done communally in the open. The community really controls the design process, not a single person or entity. It's a collaboration at every step of the way the code down at the very basic level the code should be licensed open source and then open design and that kind of brings us to our next of the four opens open development. So open development, maybe a little bit more straightforward. You know, there's ins and outs and complexities of everything so open development what does that look like. It means that the source code repositories are publicly available. It means that the code reviews that are being done are done in the open and anyone can leave a code review, or ask a question or make a comment. Testing should also be done publicly so that anyone can view the logs and we can trust that system. We shouldn't be differentiating contributions depending on the affiliation of the person or any aspect of them. It doesn't matter who authored or committed to change. We're all a member of this open community. Leading leading a little bit there. Open development has a lot of benefits. It builds trust across the community because everybody can see what everyone is saying and everyone is doing and you're building up this karma and in this like cosmic balance of a particular open source project, but also open development makes it easier for new contributors to get involved and grow into those longtime contributors which are going to keep your project healthy and moving forward for years and years to come. And that's because they can start learning the code. There's a chunk of like a particular API at a time, because that's all in a single patch that's being reviewed, and they can ask questions about how it works. And they can see all the conversation about how it's being implemented one way versus another way because they can see the open design discussions but also the whole history of code review as well. The goals that are really great for open development are obviously everyone knows about GitHub, but my personal favorite is actually Garrett. The, the get review system is fantastic for showing how iterations on a single patch happen, and what comments were made to inspire that change. It's all in one place. It's tracked beautifully. It's, it's just so simple, and a lot of people get down on Garrett get review over GitHub because they're not used to the push versus poll models, which I think I've talked about and other other talks about, but effectively, they're just, it's, it's the exact same visualization just things are going one, you're, you're pushing code down to your local repository on your computer versus pulling it out into a remote repository elsewhere and stuff so they're very, very similar tools and they have benefits one versus the other but personally Garrett is the way to go for open development. And as I kind of alluded to earlier, you have open community as the last of the four opens. So, what is open community was that look like it should be pretty easy. Well, I have two slides so all processes are documented, open, transparent, the same as we've done development the same as we've done design, everything has to be open. Governance should be elected by the community as representative government, and anyone should be able to rise into one of these roles. And just let that sit for a moment because that's like, really important, you need to be able to encourage any new contributor to grow and become a leader of the community in the future, you, you need that pool to be able to pull from and you need that diversity of thought and involvement and knowledge. It's really, really important to the health of a project and the growth and stability overall. So, along with governance, you have communications. And those are obviously going to have to happen how else are you going to build the software if you're not communicating with one another, and communicating solely through design documents or like reviews on patches can be done, but is definitely painful, and there are a lot of things that would be much easier to make progress on and move forward with if you can talk about it synchronously. Any project meetings that are being held in your particular community should be in public, they shouldn't be invite only. And they should also be recorded so that the people that can't attend at any given time can still go back and watch them later when they wake up in the morning. And the meeting happened to be held in the middle of the night because time zones are deaf. But also, regular day to day project channels should also be logged where the, you know, people wake up and say hello I'm around for code reviews or whatever. All of that should be recorded and logged in archives that you can access that later too, because often conversations will happen, or context will be shared or something like that. And you need to keep all of that, so that if somebody asked the question later on and you're like, I don't know but I think we talked about it back last week. Somebody can go and look that up. And so these things are obviously hard with the, how you're going to do the recordings and back them up and where you're going to back them up to but it does increase the amount of trust across the community, which is really important when you work together. And asynchronous communication is obviously necessary as well you can do that in your design documents and you can do that in your code reviews, but any other asynchronous communication should be going through public mailing lists. And you should also be archived for later reference. So, you shouldn't be starting threads with just a small group of people who you think are going to be involved, like that's, that's important, like getting the ball rolling but more often than not, those people should be paying attention to the public mailing list and you should all be chiming in there because there are probably voices that you want input from that you forget to add on a particular email thread so doing everything public is the best way to go. And this is all difficult, obviously, because time zones, time zones are horrible. They really are when you're working with a global community spread across the world. We can't all be awake at the same time. And sometimes coming to a decision on something is basically impossible or seems like it's impossible. And that's why this lazy consensus model is really important. I've said this before. Basically, what it means is that when a decision needs to be made, whoever is like proposing the question or proposal, they are like, okay, well I need an answer by the end of the week. On Monday morning when I wake up, I'm going to go and push the patch to do this thing this way. And if you don't think it should be done this way, let me know in this last week because if I don't hear from you. I'm assuming everybody's good with it. Thumbs up all around. I think that a lot of people do this by default without knowing about it, but it, it is a really helpful model when you're dealing with a community at scale, and just trying to continue to make progress because it's very easy to spin your wheels and iterate and iterate and iterate and iterate and not make progress. So other important ideas around open community. So I kind of mentioned this before, but contribution is a currency. The work that you put into the project, whether it's actually doing code reviews, or maybe you're filing bugs or proposing talks to conferences to get the word out about your community and your project. That's all really important in different ways. And that adds to your like karmic balance within the community. So long as other people know what you're doing. And that gives you more influence, I guess, contribution is currency. And to that end, you also have this kind of concept of one contributor is one vote. If you started a project, and you'd been involved for 10 years, and you knew a lot about it. That's awesome. That's really important, but also your perspective and your knowledge is in is as important as the new perspective that's coming in asking questions and getting to know about things a different way. So their vote is just as valuable as yours. In terms of things like electing new representative governance or I don't know what else you would vote on there all kinds of things. Obviously, the long time contributor is going to know the code base better and know what's going to break the code or not break the code. One contributor, one vote is a good way of avoiding benevolent dictator or elected government that doesn't ever turn over and change and give way to the new perspective and new life that a lot of projects need from time to time. So another concept is how you organize priorities and importance as an individual contributor. So we have this project first project team second company third. And a lot of companies aren't going to like this, because you're paying a contributor to work on a project so you want your priorities first. And that's totally understandable, and also makes a lot of sense. I don't know how that contributor is making their business case to be in that community. But if the project doesn't come first, or any other little sub teams that they're involved in if those things aren't being prioritized higher, there's going to be a lot of people arguing and the health of the project is going to suffer. So the project and the community around it need to come first to maintain a level of health and functionality. And your company's priorities are also really important. And that's why contribution is currency. And people that are really involved are going to be able to push those things, those priorities that are being trickle from the company into a project. And that's just a really nice clean way of doing it to balance everybody. One contributor, one vote, so that if a particular company wants a lot more influence in a project, they can employ more contributors to work on that project, and then they will have more influence. And you don't want that to get too out of scale because or out of proportion, because then you run the risk of the project becoming basically a single vendor project and then you lose all of the benefits of it being open source. And you can't push too hard on that. You kind of just have to trust the community. And all of these four opens are about building trust. You have trust in the code that all of it is being published and shareable and you're going to be able to implement trust is the open source, and that you're going to be able to influence the design process and make your opinions heard and make sure that the software is going in a good direction. That's open design. And then actually putting those designs into implementation and making progress there. You're open development and open community, which is both the top layer and the bottom layer of like this whole thing. But open community is, is so important to making sure that you have that level playing field. And that's insured by the community being cohesive and inclusive. Inclusivity obviously is difficult because we are such a diverse people across the world, but diversity makes for a healthy community, you need that really diverse ecosystem of people and thoughts and backgrounds and knowledge. And so you need diversity. And it's not as simple as race or gender. You also have diversity of company affiliation and education and geographic location time zones. Horrible. It's important because I've had, you know, interns or people that I'm mentoring be based in one time zone, far away from me. And that's difficult for me, but I know because there are other contributors on the other side of the world. They'll be able to answer my mentees questions while I'm not around. So I have trust in the other community members in this open community that they'll help support the new contributor that I'm also supporting. So open community is really, really important to the health and longevity and progress of your project. So that's all fine and good. They sound great, like an excellent iteration on the four freedoms. But do they actually work? Like, do we have any concrete evidence? Do we know of any projects that are using these four opens as a guiding principle and methodology for their communities? We do. So open stack, Cota containers and Zool are all very, very different projects. So open stack, if you haven't heard of it previously, it's cloud infrastructure for virtual machines. It's been around for about 12 years now. I think it was established about 2010, which was when the four opens were. They're actually the first project that is like pioneered this methodology of the four opens. So they continue to release software on time. They just finished or are finishing their 26th release. And that the users that use open stack are continuing to grow and new users are cropping up every day. Many of the users are actually reaching one million cores of open stack in their clouds. That's insanely huge clouds. And some of them are public and some of them are private, but a million cores in a single cloud and like multiple others are at this level now. It's crazy. So if that's not a concrete example, okay, fine. Let's let's try a different community. We have Cota containers. So Cota containers is a container runtime that's compatible or compatible with Kubernetes. You just swap out Run V for Cota. It's reaching its fifth birthday. It has a global community as well. A lot of companies in Asia, a lot in the US are contributing and are continuing to invest in it. And it's one piece that fits into a lot of other open source software and other communities and integrates really well. So these four opens are also a good example for how to set up a community to be collaborative with others. And open stack is also an excellent example of that. But lastly, I have Zool listed here. Zool is a CI CD gating system. And it did start out of open stack. But now it's being used by a variety of open source communities and also internally by companies as gating and testing on their research and development projects. All kinds of different things. But Zool just had its 12th birthday or is about to have its 12th. No, 10th. 10th. Sorry. Zool just had its 10th birthday. Open set had its 12th. Cota is reaching its fifth. So all of these projects, they're all very, very different projects because you have like obviously virtual machines are very different from containers. And then you have all of the gating and CI CD, which is a very different tool and tool set and therefore community than either the other two. So if you happen to know of another community that's using these four opens, please let me know. I just think that these are three really good examples that are all really different and kind of illustrate how successful the four opens can be and are continuing to be. So it's not just something that was established 12 years ago or 10 years ago and is doing fine but if you tried to do it today. Well, well, maybe not. But Cota proves that it is still good today in this day and age. So we, we talked about the four freedoms, and we talked about the four opens, and now I will introduce the three forces, one more step on our Jedi adventure, and how these things come together to make one open info way. So, the three forces, what are the three forces. You have ecosystem developers and users, and these are three very different pools of influence. And they're really important because you need to balance them via the four opens, which I've talked about already to ensure community and project success. And it's much more complicated than just upstream and downstream. If you try balancing two ends on a single point, like a teeter totter or seesaw or whatever you happen to call them. You just need to even things on either side. But when you add a third point in the balancing or triangle becomes much more difficult. So ecosystem what is ecosystem. So that is the larger group of companies and alternative tools and technology. We're all together influencing the direction of technology in the space around a project. It's a, it's an ecosystem of users and operators but also companies and rules and regulations and like everything, everything is part of the ecosystem. We have developers, pretty straightforward people working on the code, but slightly more complicated because those developers are probably working downstream for their companies, but also hopefully primarily upstream in the open source code that the entire community is working on. So developers are involved in the design and the implementation process and reviewing the code and all of those things. So doing those all in the open helps build the trust to balance with the rest of the triangle of forces that you have here. And then users and operators is the last one. So they're the people that are using the code and they're just as involved because they're giving feedback to the developers and they're filing bugs and finding new issues and using things at scale or in a different way that puts the software under stress that then maybe a new design needs to happen. So you have to take things in a new direction because a particular library that you used to rely on doesn't work anymore. So, the four opens really do help to balance these three forces. They like first and foremost you establish those common goals like what is this project trying to accomplish you unite and unify under that one mission. And then you build connection between these forces, making sure that the users and the developers are integrating together and talking to one another. And you make sure that the users are present in vocal in the ecosystem and influencing the direction of where the software is going and then the ecosystem is going to determine your set of developers and users. So companies are involved and interested in a particular software or space in technology. So, building connections between these forces is really important. And that helps avoid the siloing, which has been a problem and more than one project I know opens up the issue and is still working to balance these three forces. And it's an ongoing thing throughout the entire lifespan of your project. So, three forces, plus the four opens, because that's how you're going to balance them with the four opens. This is the open info way. This is what the open infrastructure foundation believes is the way to success for any open source community. There are things that a community can do on their own. There are things that the foundation can help with that. But there are a lot of different ways of doing open source and there are lots of different foundations that can help a particular project, or not all projects need to go to a foundation either. But if you're interested in this particular methodology and you really like the sound of the open info way like take it go for it. It's, it's all open source. And I'd be more than happy to give you more examples and explain things answer your questions. Please feel free to reach out to me but as we started with we will end with these four freedoms. How open source was established these were the basic ideas and they were a really good starting point, but they did leave some room for difficulty. And so we evolved them into the four opens and the four opens plus the three forces gives you the that one open info way. I really hope that you've enjoyed my talk today. And if you have any questions, please, please reach out to me. I think maybe we'll be having a Q&A here shortly. Otherwise, feel free to email me contact me on Twitter. I am also pretty present on IRC and matrix because open communication. God love it. So I am available on GitHub as well. So please feel free to reach out to me. Thank you so much for coming today. I hope you learned something, and I look forward to hopefully running into any or all of you at a conference someday. Thank you.