 Yeah, there we go. Yes, good. Thank you very much for coming. Cool. Wow. This is this is awesome audience. So, um Yeah, I'm Richard. I'm the chairman of the open Suzer project So I've been actually contributing to open Suzer for about well 12 years as long as the project's been around and Some genius thought I should be in charge And actually I'm gonna talk about how Distribution projects specifically, but I think most open source projects out there Seem to have forgotten why we have governance why we have a project in the first place and Talk a little bit about some of the consequences that we're actually facing in the real world with our projects and Yeah, how we might want to change and rethink actually what we're doing when it comes to keeping yeah Keeping our project running how we're governing them. So, you know, ultimately answering the question Does governance matter? And when talking about governance, it's it's quite easy to talk about, you know, the leadership the guy in charge the guy at the top You know and obviously You know a certain person at the top of any food chain can have a significant influence Or maybe not such an influence, but But but yeah does does have an impact on on how the organization below Works thinks about things talks about things and also talking with other people and other organizations But really at the heart of it It shouldn't be about the person at the top The question of a project's governance and organization and how it actually works Should all be about the influence that any one individual can have any new person joining the project any one person in there can they You know be be this sort of pebble disturbing the entire ocean of a whole distribution or the entire open source ecosystem at large and this this kind of thought of You know can is there the power of one in open suzer is what really got me thinking on this topic of Do we meet that test that any person can can join and really influence where the project is going and Of course when I was thinking of that I was looking at all these other projects and got me thinking of You know just how does everybody else do it and I kind of realized that the situations way Way messier and way nastier than I was expecting And and not nearly as as as free as as and open as I was hoping it to be in you know open source ecosystem And and so sort of when thinking about this I realized I wanted to sort of talk about Which You know who does the project serve really? What is the point of an open source project? What is the point of an open the distribution project? You know why does what who does the project itself serve who did it bet? Who is it meant to benefit and the first time I ask is to most people they answer You know we're here for the users. You know it's here You know we're doing something to give software to the users and the more I thought about it the more I agreed I thought that's totally effing wrong it is Our projects do not Exists to benefit the users and in fact what me you know I say we should I say they and if you disagree with me I'd say then we they should not benefit the users The project should exist to benefit the people working in the project The software that we produce Yes, that's totally for the users, but that's the product. That's the end result The governance the structure the methods the policies the processes every decision We make as a project about how we're going to organize ourselves as a project Should be orientated to serve the needs of the people in that project as soon as you forget that and start focusing on the end users and Start feeding that into the the organization of the project projects time and time again lose their way They lose focus they lose their they lose their purpose and you end up with Yeah, yeah distributions that try and solve everything for everybody and then no one uses it because it doesn't do the thing They wanted to have done So it really yeah, it really has to exist to provide a collective benefit to your maintainers to your contributors to your volunteers Because if it doesn't provide a collective benefit, you're not going to have any maintainers You're not going to have any contributors. No one's going to bother joining your project and Yeah, and this does require a bit of a mindset change for some projects some people do you know really stick to this mentality of sort of users first, but The project has to be there for its contributors And I'm now going to stop using the word contributors Because language matters and that this this framing matters, you know when when you talk about contributors There's this kind of tendency to Especially as a leader of a distribution project, you know It kind of comes with an implication of it's my project and you're just contributing to it You know, I don't like that kind of hidden meaning behind that often gets kind of labeled with the thing of a contributor You know that there's you know sort of suggestion of a contributor doesn't really have ownership of the end result They're just contributing to the end result And so and the on the other opposite side, you know with language, you know maintainers quite often comes with You know an opposite connotation. We're just maintaining it just keeping it where it is or yeah, it's ours. It's mine Ultimately, no matter what anybody in your project is doing doesn't matter if they're you know helping with the artwork or helping with ideas or dealing with You know support forums or whatever. They're all volunteers I would contest every single person in an open source project is a volunteer Either literally they're doing it in their spare time and totally voluntarily But even when dealing with Open-source projects where corporations are involved Ultimately the corporation is there voluntarily they can always go elsewhere and the people working in those corporations are there Voluntarily, unless you can give me an example of an open-source company that has slave labor, but there shouldn't be I really hope there isn't So as soon as you start Freak realizing that and thinking in those terms and realizing every single person in your project is a volunteer a lot of these weird questions about How should we? Yeah, how should we deal with this dark and how should we deal with this idea? You know, how should we? Organize our yeah, you know our leadership committees and technical groups and that kind of thing suddenly becomes a lot easier to actually answer and Totally changes the context in in how you approach these problems Because ultimately you the kind of underlying bit of this they're they're volunteers if you're not again not dealing With the needs of your volunteers They can walk away and when they do walk away your projects suffers for it And I just press the wrong button. There we go And then this is kind of yeah sums up with this quote, too, you know, we're we're here doing Linux during distributions You know, it's free But the project, you know the work you are doing for the project isn't free. It's valuable It's beneficial and so it you know We have to have the project structured in a way that it somewhat is its own reward and it caters there So that that project is providing a value add to that contributor to that volunteer And yet if you look at so many of our projects What's the first thing we do when it comes to structuring them and organizing them and having some kind of governance? we have a committee and Starting without the distribution, but just Apache and this is Apache HTTP D But this is actually true so every single Apache project and this you know Every Apache project has their their working group in the top which you know all major changes must be voted on Any Apache developer can vote on on any Apache working groups Changes which is nice. However, only the active maintainers for that active working group are the ones that their vote is actually binding So, you know, basically if you want to get any change into Apache HTTP D You have to be friends with at least three of the maintainers there But on the flip side because you know, they're trying to be very equal opportunities in the open there Anybody can veto anything So basically if you're a new guy trying to contribute to Apache you really are going to have a hard time You know, unless you're surprisingly lucky and This isn't necessarily a bad thing. It works very well for them I think I would actually say it works very well for the majority of Apache's projects Because most of Apache's projects are somewhat narrow in focus and narrow in scope and therefore, you know Having a narrow decision-making model has certain benefits. You can you know, theoretically get changes to rather quickly But then having a look at the border ecosystem, how many different web servers do we now have in You know in the Linux ecosystem, you know engine X and the like all competing with Apache Because Apache doesn't do it the way they think should be done Well, why couldn't engine X get their lightweight? this Into the Apache HTTP project or because this decision-making model will net it will never get past this kind of committee process You know, they're thinking in their way doing things their way and they've structured their entire decision-making and acceptance model In a way that reinforces the status quo You know Debian does this a kind of a lot as well But you know and lots of other projects do it's not necessarily a bad thing But when we're deciding our governance models for our projects We really should be thinking about the impact that has on where can this project go? You know long-term how can we change? How can it be sustainable? How revolutionary can it be? You know with this model, there isn't going to be some massive fundamental World-changing rewrite of Apache unless you know, they're really those guys over there really smoking something nice and That might be a good thing but It does mean that over time things are likely to stagnate things are likely to slow down things are Likely to get harder and then that's how projects decline That's how projects go away and then we need new projects to come up and stand up there But does it have to be that way? Could we you know to do us to have a sustainable project? Shouldn't the model potentially be one where the project itself is more open to challenge within itself? Therefore, you know accepting changes more broadly not voting against you know not having easy vetoing and not having very select approvals When dealing with larger projects like distributions that model has massive scalability problems You know you can't deal with that many incoming requests You know your poor core maintainers have to approve every single thing and you have to have at least three of them So that thing all backs up there. You can't just add more people to the committee That's what some projects try with with this kind of approach But that just ends up with more people in the committee arguing with each other So it doesn't really solve the problem at all In fact it quite often makes it worse And like I've been talking about for the last few minutes really it Provides a barrier of entry to the project a new contributor is going to feel that it's that it's harder to get in there In some cases some of these projects some of these committees that follow this model You know the people involved are really nice friendly opening people which somewhat mitigates the reality of that You know if you've got the right people in that place, they you know a lot You know they'll accept crazy changes. They'll accept that challenge So the model doesn't necessarily always mean that barrier of entry is real But it's perceived you know as a new person you're not going to know who that that nice guy is So are you going to send that crazy change that you have that you've baked in the in a dark corner somewhere? Or are you just going to declare a new project on GitHub and do it in there? And you know is this why we end up with so many forks of so many projects for the place because they never realized They could actually contribute to the upstream Because the upstream was structured in the wrong way in the first place And this is why I talk more about Debian Because Debian has their technical committee, you know, which is there to decide any matter of technical policy Especially where you've got situations where developers have overlapping jurisdictions They can also just make a decision because someone asked for a decision and they have the right to overrule a developer Which I find really weird because it's like we're all volunteers and we're all doing especially in Debian You know that there's no company behind it, but what do they expect if they ever overrule a developer like this guy's doing it this way This committee says he's doing it wrong. It's like it's a volunteer really going to change what he's doing No, that's how you lose a contributor or you at least don't get that person's contribution on that topic And Debian and SystemD is kind of a perfect case study on how the Debian model can be followed Perfectly, every part of every person involved in the decisions with SystemD did their job in Debian perfectly The technical committee, I do not fault for their decisions at all. I think they were perfectly right and valid I also think the Debian community who objected to everything going on with SystemD were doing their part perfectly right and valid But and yeah more about that in a minute But yeah, the technical committee in Debian decided the SystemD would be in Debian as a default But they purposefully and I think quite smartly Decided that they wouldn't decide on whether packages could depend on a specific system But you know some people don't like SystemD So there was a flame war The lasted nine months And that that discussion pissed off a lot of people that discussion had a lot of upset people on both sides It led to the fork of Debian and ultimately They decided let's have a democratic vote on this and decide, you know, what is our way forward and after nine months Collectively the Debian project decided that they didn't need to make a decision Which is ultimately the right decision it's the one the technical committee made in the first place There's nothing wrong with that, but how much pain and upset did their process and their structure cause? It's not you know, no one's at fault, but the entire project organization Created this problem not SystemD But the model they decided to follow and therefore what benefit did that model really bring Debbie? They didn't make a quicker decision didn't get more people involved Anyway, how did that work and in fact the technical committees generally? How often does a technical committee bring nothing to a project but an opportunity for someone to say no to a developer? Because a developer doesn't need someone to say yes, they're gonna do it anyway And this topic I lent off that corporate overlords companies, you know working in working in this space because you know They do too. So yeah, obviously I work for SUSE so I'll get to that in a minute But I'm gonna start with our friends that read out No Actually I'll get you I'll get I'll get back with that later Fedora have their Fedora council which Speaking as chairman of the open Caesar board I can shamelessly admit when we started the open Caesar project We basically copy and pasted our structure from their structure But things have changed over the last 12 years So the Fedora council as it stands today has a very similar role to my purpose in the open to the project But oh no, sorry doesn't anymore used to now it has this role of identifying organizing and enabling the project's goals It's currently 10 people Eight of them are employed by Red Hat Two of them are elected by to the community So three of them are directly appointed by Red Hat The remaining five are appointed by the board. So, you know, it's a nice internal loop And even one of those two elected by the community is employed by Red Hat How much yeah, how much non Red Hat community influence can possibly be in that board, you know Do you think Fedora's goals might ever be challenged to do anything other than what Red Hat are deciding they want to do Yes Possibly but that may you know, but ultimately I mean when speaking of somebody who works in an organization very similar to red hat You know Organizational bias really is a thing inside Susan We have lots of well-meaning people who have their own ideas and thinking their own thing But when you're surrounded with a whole bunch of people doing something, you know for your corporate overlords You're going to end up thinking along the same lines even by accident So you can't have if you're trying to do a general let's say for example, it's like Fedora and open Susan You know pretty much general purpose distribution In the open source space If you go this model you're not going to have Anything challenging your kind of perceived organizational bias, you know You're going to go in that direction, which you know your corporate management or whatever Decide either fully wholeheartedly because you know you're forced to do so But like I said, we don't really have slave labor in the open source world But even by accident you're going to be thinking along those terms Focusing on those goals that you know corporate red hat or corporate Susan have decided and you're going to be pushing in the direction Even if it's somewhat unconscious And I think it's better when dealing with with with a mixed sort of corporate and open governance model to have A system that's designed where you know challenge must be baked in You know there must be and I'll get to that more later because otherwise I won't have anything to talk about later And yeah, just to really be horrible to Fedora again, but you know in addition to their leadership board They also have a technical steering committee, which basically doesn't set the long-term goals But decides on every single Every single package that's going into the distribution and what the software should be available to the end user That is also currently nine people That's a copy paste from the charter for the That's a copy paste But it's it's what they wrote down Okay, so that's what they say they're responsible for you know, they may not practice it But whatever whatever they're doing, you know, there's nine of them seven employed by red hat my other my other points Yeah, ultimately And and yeah, and like we've been talking about you know in open source. I really I do agree with Linus here You know, I think you you know our contributors should have the right to control their own destiny Um, if it's not real open source if one person can't make a difference in a project Um, and then in sort of the worst example of that is somewhat, you know But I do give credit to canonical here at least they're honest and very very clear about it You know their their organizational structure is one where basically mark is in charge And mark nominates who he wants to have in their community council, which is sort of doing the The the conflict resolution and community management side of things And mark decides who's in the technical board um, you know, obviously so Again, that's a structure where a new individual coming to the project or any individual within the project It's going to be somewhat limited in how much they can change, you know in the project as a whole and and you know And how much that can grow and maintain and move faster in the future Um, and I'm talking myself again there. What about suzer and open suzer? More about that later Because we like I say we started well go back we started Pretty much copying what fedora were doing, you know when fedora started 12 years ago. We started sort of six months later um, and and you know the the goals from suzer was to kind of bootstrap something on the same lines But inside suzer There's some mentality differences than inside red hat And it's really interesting to me to see the difference now 12 years later of just how far those two original starting points have diverged and also How humorously bad some of the experiments were that we tried um And one of those that we tried straight out of the gate because we thought this was really really good Was direct democracy you know, let's have Everybody deciding everything about the direction of everything in our distribution um And yeah, winstons, right? It's the worst of everything. Yeah apart from everything else that's been tried um In our case we even you know in typical suzer fashion made a tool for it So there is a tool called open fate you can still see it today sadly because I haven't quite taken the heart to the killer yet, but It started as an equivalent an open suzer equivalent of suzer's initial internal feature tracking tool So the tool that they use still today for deciding what features go into the enterprise products You know fate you know decide deciding the fate of the world um as feature I can't remember what the it's a pretty abbreviation for something as well like feature and tracking enhancements or something um Yeah, but an open freight was decided to be a totally and utterly open Where anybody can suggest any feature they want and the community can vote on any feature that they want um, in fact Yeah, and and there are hundreds of feature requests thousands of votes and I can honestly say as the guy who quite often goes through this trying to see how we're doing with that kind of thing The impact on the project's priorities are negligible Every time I close a feature it's done on there. We fixed it by accident I I am yet to find a developer who's actually looked at open fate and done anything because it was in open fate Um, you know, there's been a few times at suzer where we've like copy pasted it and put it as a feature for sleeve But that's you know, just it was convenient Um, but it does not work. Um But this quote about democracy can't be thinking because in fact when we When we think about open source projects, especially when we think about how did it all begin? Where did we all start? How does linux work? You know It is it you know, it the inmates should be running the asylum Why why not that's where we started in fact You know looking way back to the beginning, you know the first rule over the cathedral and the bizarre every good software starts by developers scratching their own itch So why have we forgotten that? You know, you don't need to tell your volunteers what to do They know what needs to be done. They're working on the code base. They're using it themselves They need to have the tools in the environment to do that So that is something that a project really should be thinking about to bring as a value add to its contributors that's what that's what That's one place they should definitely be starting and your volunteers should be feeling empowered that they can do Whatever they want to be doing with that software for that for that project as a whole And it doesn't matter if you had someone telling them what to do. Anyway, because they're not going to listen to you That's what we learned from open freight So a sort of core principles that I really think that more projects need to remember they should have at their heart Whatever they're doing distributions or otherwise Respect your volunteers. They do not need to work for you. They can move elsewhere Even if you're paying them they can move elsewhere You should be focusing on enabling them making sure they have the tools and the processes to do their work And you should be trusting them, you know, you they don't need to have management or project managers or You know technical committees deciding on what needs to be done The best person to decide is the volunteer during that work Anarchy's are crazy. So And anarchy's don't sustain either. They have a habit of exploding So Respecting your maintainers is great But don't give them too much respect. Another example from Debian is a Debian Maintainership model, you know A Debian maintainer is pretty much God for his package Which is that's which is nice to hear because the the model of sort of, you know, a single overlord of a package Will not last in the long term So Structure your project in a way where any person in a position of influence Can be challenged new volunteers should be able to come off the street start working with the existing volunteers You know, or ultimately replace them, um, which Can be a daunting concept in some example in some projects in some structures But you know, if you if you can't pass that test, I think you're doing something wrong Enable them But you know too much freedom can be a bad thing, you know everything going off spinning in different directions So if you look at what for example, we do with open suzer in our tools and things like obs and open qa All of the tools and processes are designed in a way that they're there to not just let the developer do what they want to do But encourage and guide it towards good practice good guidelines and ultimately long term sustainable maintenance ship Because you have that first concept where you want to have the capability of any developer possibly disappearing and being replaced by another You've got to have a little bit of sort of common standards and common structures So, you know you guy off the street can understand what the hell the last guy did But doing that in in as part of a structure sort of tooling or processes Generally works a hell of a lot better than relying it to being people in technical committees and decision-making groups because ultimately as It's kind of fun to admit with developers We argue with people all the time if you do it in a tool, we're really unlikely to argue with a bot Um, so, you know having that there is is a very clean way of making sure that you can You know last with this model in the long term And you do want to trust your you know your developers and your your volunteers But conflicts of opinion will arise and you need to have a tie-breaking solution In open suzer, we basically sum this entire philosophy up in what phrase those that do decide Which I say way too often and you know citation needed. I can't find an excuse besides where we use it. So open suzer So we're we're living this philosophy, you know, we're we're we're focusing on making sure our volunteers Are the ones deciding where open suzer is going down? Obviously, we're not expecting everybody to do everything on their own So we encourage to have self-organized teams. We just had that last talk until I talked before last Where a collaborator talking about their How they were using obs and that whole kind of model of multiple obs projects layering over each other That feature in obs is born from this concept of self-organized teams Because we needed to have this model where Anybody can go to our build service anybody can start working on it and we kind of Start grouping people together based on common packages that they're working on But they do that in a separate project so they can have their own rules They can have their own structure. They can do all things their own way So it's devolved but not an arctic And again in those tools in those structures We define that by consensus generally, you know Our mailing lists are where that the general concepts are defined and agreed and then they implemented generally in tooling Which are then overseen by other volunteers So they're open source too. So if you want to change the tooling and you know, what you need to do is a commit request Um, so that that's sort of how we keep those general standards rather than having an overbearing technical committee making decisions in a dark room It's all done in tooling in open in the public and therefore all changeable at any moment's notice because it's all easily just committable So in action, you know, this this sort of bureaucratic approach Yeah, uh, yeah, I wanted to avoid using that word Anybody you can log into the open source of build service today and submit any change to any package in the open source of code base No permissions required existing volunteers will automatically be notified. There will be automatic say hey, this needs a review um, and But they give it they're not That review isn't a blocking it's there to give an opportunity if they don't review it in a timely manner We're going to assume that new person off the street is probably You know good enough to at least reach the next stage to the viewer move on from that So, you know, they have a chance to start working with the person. They don't have a chance to block everything And therefore the contributions do all of the talking we we generally are when we're dealing with a new contribution in In the open to the code base our first criteria our first thoughts are much more about How easy is it for us to carry that change? We generally don't ask at least on the the human side of things we're reviewing Does this actually work or is this the direction we want to go in? Because we have those automatic checks in our tooling with obs and with open qa So the does it work question is a simple case of Is it going to work? You know, we leave we leave that out of the equation entirely Um, and of course that does sometimes mean that some changes take a little bit longer to get in because the person Doing the change also has to write the test to get it into the test suite So they can prove that it works But it really does mean that those contributions can go in any direction. There's no overarching control There's no overarching features or functions So we don't have any steering committees. We don't have any technical boards of benevolent dictators project managers And we don't even have community managers. I mean it's The whole thing is meant to be self managing self governing and ultimately self sustaining And Therefore system d ends up being another good example Because we were the first distribution to actually have system d in our code base It was like july 2010 like I think the first commits were in like April and we had a package in our distro in july um Because one guy Kai, I mean immediately he was the upstream developer for system d wanted to put it in the distribution um And it became a default in 2012 The changes were made by the people who wanted to have it in the distribution And actually one of them sitting there smiling at me Um If people didn't want it and there was of course some objections on our mailing list and some discussion The answer in this model is simple fine. We're not forcing this on anybody There's no overarching decision that we must use system d If you can do something better if you can do something else if you want to still carry sysv in it as well Then do the work in this case the coven sysv in it maintainers weren't really that interested in carrying on doing that So You know it didn't it didn't happen and we now only a system d distribution But there was no conscious decision for that. There was no management decision. There's no management Um, and ultimately there was no major strife You know, there wasn't a huge blow up. We didn't lose contributors. We didn't have a you know, horrifically nasty time We are where we are And we got there without Yeah, without the the strife that other models by accident just cause Peace And this model has some really significant benefits open suzer The more we've embraced this model the more we find tune to the more we realize this is the way we should be doing things Has become more and more agile. Well, we can now as a distribution Deal with changes with whatever upstream projects are doing at a rate of pace that not even arch Linux can do You know, we're able to keep up with everybody at every speed Um at full pace without any problem And we can also deal with all the wonderful eccentricities of all our various upstreams So, you know, every upstream does something different. They have different release schedules. They have different structures Because we've got this devolved model where the contributors are deciding how it works and they're you know They're working close with their upstreams. They know what crazy stuff they're doing Um, so they're dealing with that and there's no kind of overarching policy of of again picking on debion Sorry, but no overarching policy of like, you know, we cannot change version numbers ever Um, you know in our case even in our stable distribution even in our enterprise distribution You know, if an upstream has made some change for some patch that's security critical or otherwise needed for suzer's enterprise customers Suzer will look at that and think Okay, we can backport that change Or we can change the version number And they'll decide there which one makes more sense for that case Sometimes they'll just backport it quite often they do sometimes end up with a version bump even an enterprise distribution Yeah, and therefore, you know, you end up with a nice yeah free approach of Yeah, if it works and you'll support it it gets him It isn't perfect Freedom has its problems One of which being the power of choice, you know, if Develop, you know a new person coming into your project has an option to do whatever they want So they decide to do nothing because they can't decide what they want to do Um, it can be overwhelming and I don't have a great answer for that. Um, you know, obviously things like You know, obviously documenting your current pain points documenting where you know where you ideally might need to have A little bit of help can can help but then of course you want to avoid crossing that line just telling people what to do Um, so that yeah that part does get a little bit tricky So my current approach to deal with that one is do presentations like this to make people realize, you know This is how we're working. This is how we're thinking and don't panic just pick what you want to do and go ahead with it It also has a common tendency to have misconceptions, you know, obviously You know, you're going to have senior developers who've been in your project for a long time It's you know, they might be Seen to be you know, thou that can't be questioned But in this model everyone needs to realize that everybody can be questioned In addition to my work that I do with open suzer or as the chairman of open suzer I've currently been working on restructuring How we do all of our btfs sub volumes in in sly and open suzer. I spent months on this. It's been like keeping me up at night Everything is now finally in the distribution. I know tomorrow Some other guy can come in and change everything and I can't stop them Um But that's fine. That's how it should be because if they think they can do it better than me Isn't that why I was doing it in the open in the first place? You know, so Yeah, just but that mentality needs to be communicated people need to realize They can challenge everybody in a project But that challenge sometimes means you've got more than one person wanting to pull in a different direction And conflicts happen and you what you need to have some solution To resolve deadlock or void deadlock Or you need to have life started calling now organizational check sums Yeah, because you don't want developers slapping each other Conflicts happen, you know, let's say volunteers. We're human mostly Um, we have different ideas those ideas might not be compatible with each other And compromises can be hard to find But most distributions go and call this a technical problem You know, they put this this conflict resolution under their role of their technical committee And, you know, and how many mailing list threads do we have in all our projects? Or arguing about the technical benefit of this or that or whatever Bullshit, it's not a technical problem. You have two developers or multiple groups of developers Who have an interpersonal issue with each other And you need to think about these problems in that context forget about the technical solution because ultimately Even if one of the answers is 100% technically better It doesn't matter because ultimately the only one that matters is the one that's going to be maintained two years from now Three years from now in the future So ultimately the only bit that matters is the one that has The you know the motivation behind it the people who want to make it move, you know The the better solutions don't necessarily win The motivated ones win And so when you've got these interpersonal issues You need to find a way of basically satisfying the motivations of as many of the people involved as you can It needs to have a human touch. You need to be dealing with the humans and seeing it in human terms And you need to make sure that all sides of the argument are not just heard But feel that they have been heard feel that their concepts have been understood and thought about and dealt with And that's how you get to these compromises of actually how We end up With everybody moving the whole linux and distribution ecosystem forward It's also how you sometimes end up with like five or six different versions of a package in your distribution But that's not necessarily a bad thing Because you can find compromises to the weirdest problems Another perfect example is in open suzer the desktop options. We have you know, we have kde is our kind of default No equally fully supported and lurking away in some dark corner of the tumbleweed code base We still have kde3 because we've got maintainers who still today manage to get it in the distribution and make it work No kde4 luckily But they still have kde3. I think they're crazy, but I can't stop them and that's fine because you know They're able to they're able to keep it working and they're able to work that way and you know That's fine and every now and again the kde5 guys and the kde3 guys end up Doing something stupid like sharing a library name and everything goes horribly wrong But you know when you get them around the table and talk about that issue there And deal it on a personal level every time they found a compromise for their problem We don't have to decide. Oh, we're going to drop kde3 because the library got the same name So decision-making should always be an app in this kind of conflict Should be an absolute last resort. You shouldn't be trying to decide this side versus that side or this solution But that solution You really should be aiming for a compromise. You really need to be aiming for Really ultimately going back to the original concept of Enabling your volunteer to do what your volunteer wants to do in the first place So if you can find a way for everyone involved to do what they want to do And if you do make a decision you've got to realize that the thing you're deciding at the end of it The people conflicting and yelling at each other for the last six months on your mailing list Still got to be the ones implementing that solution So, you know, you don't want to be still in a situation where you've made some overarching decision Thou developer must go do this and they're not going to do it because they disagree with it So what's the point of the decision-making process? So basically what you need, you know, if you have a problem and no one else can help you need to have an a team of sorts In open suzer, we have that as the open suzer board Which is our evolution of what was once sort of our copy of the fedora council Unlike the fedora council This board has no responsibility whatsoever when it comes to Dealing with goals and long-term planning and whatever. I mean sometimes we do it and give suggestions and sometimes people listen But the responsibilities are just that that you see on the board there. We're there to resolve conflicts We're there to be a central point of contact for the project And we are the absolute decision makers of absolute last resort And because of course we have a corporate sponsor in the case of suzer We also have the responsibility of keeping touches suzer and vice versa because you know, it's easy for the company If they've got a group of people to immediately talk to and ask questions of and that kind of thing Internally, we've taken a model Which yeah has sort of yeah somewhat changed from From what everyone else is doing Apart from gnome actually because this is very similar to the gnome projects model Where we have five elected board members Elected by our community Which are currently open suzer members Which are basically currently established Well existing established volunteers The the selection criteria for open suzer members is actually something That I think we need to fix right now in open suzer There is a selection committee or a membership committee which decides have you done enough stuff to contribute Which of course goes against everything i've just been talking about for the last half an hour Um That is something which well hopefully the rest of the community will be able to see this presentation And now understand why i'm about to suggest that we simplify that and make it a case of If you've contributed and you want to be a member and you're a member You know, it you know, it isn't going to work any different It's just going to be a lot easier to get people involved and integrated into the community An elected board member has a two-year term We don't want to keep on replacing the entire board every two years So at one year we replace two of them one every yeah every other year replace three of them But we have this really hard rule No more than two board members. So no more than 40 percent, which is the same as the Nome Foundation Can have the same employer So if you do the math, you know best case for suzer They can only have two people on elected into the board. That's it Um Therefore, you know, you've got a company that's actually adopted the same mentality here of Creating a structure in their own friendly project, which they you know, which they started and sponsored That is designed to challenge themselves They you know, there is no way that that you know, suzer can have overarching control of the board There is a six person Me Which is appointed by suzer So they guaranteed to have at least one person in there which for several years in open suzer I've been the only one Um, you know, there's you know, the community elected, you know all non suzer employees and I was there kind of on my own Which is great. Yeah, and nothing nothing wrong with that whatsoever And I have the additional responsibility of you know being the one guy who's meant to talk to suzer all the time But ultimately I I whereas oh one thing I forgot to put on this board This board is is answerable to the membership We have a 25 percent rule. I think which is the 25 percent of the members say they don't like the current board to get anyone Um, it's a pretty low threshold and you know pretty easy to replace the whole lot Um, the however the members they didn't elect me. They can't get rid of me, but the board can Um, so again having a system with built-in checks and balances Everyone's can't you know, I can't go rogue and take over the entire project even if I wanted to Um, and that's how it should be, you know, there should be a challenge in there There should be something to keep me on my toes and keep me honest and keep everything yeah smoother Because yeah, yeah, otherwise how can how can we be sure I'm doing things fear with my responsibilities really in mind And so you end up with back to this quote of yeah corporations are people In a democratic model the corporation has to start acting like one Because the only way that suzer can get something done in open suzer Is if they're acting like peers That suzer employees have to be part of open suzer the same way that some random contributor is a part of open suzer They don't have any additional control because they've got a suzer email address Um, the only control they have is literally through the commits which they put into the project But their commits are no more important or no more overarching than any commit from any other person who's also working in the project Um, that means they have to keep up with their their upstreams either various different parts of the open suzer project Um, or you know, obviously the different upstreams they're dealing with across the world um which is a An interesting proposition that went to companies to realize okay They you know effectively other people are creating work for you because you know you have to keep up with these other people Um, and when there is a change that they want to have like yeah, for example Thank you restructuring the you know like like me recently restructuring our btfs layout You know, I had to go and persuade the community at large that that was you know a good thing and you know I couldn't just go in there and throw it in because i'm chairman of open suzer And like I say they can take it out any moment they want anyway But corporations already know how to do this You know the kernel works under very similar principles of this No single company has overarching control of the kernel. No single company has overarching control of open snack So why the heck do the red hats and the canonical of the world who know how to work in this kind of environment? Not create one when they're building a system, you know building their own project at home Yeah, they go and make some nice little system which they can control with their guys in charge And I think that's wrong. I think it's really missing a trick and I think it's actually really holding these companies back Because they can't be as agile and as fast and as flexible dealing with what's really going on in the open source world at large Because they're just going to be focused on what they've decided internally in their little ivory castle So in conclusion Distributions all of them. I think you should get rid of your technical committees entirely and your dictators You know, you should not have them. You do not need them You're just creating ways of saying no to the very people you need to keep your project going But when it comes to decision-making models, you know, I favor duocracy over democracy, you know Especially direct democracy. You just will never get a decision made if you ask everybody everything That means you need to trust and empower your volunteers to drive your project You therefore need to have some way of dealing with deadlocks and breaking that cycle like like an mediation body But limit their scope don't fall into the trap of starting with them as a mediation body And then they end up evolving to some kind of technical committee and then they end up, you know Being responsible for deciding your long-term goals. It doesn't work And corporations need to realize especially with their local their local distribution projects that they are close to them Give up the control. You don't need it. It holds you back when you have that control Yeah, if you treat your distribution communities like your other upstreams Your distribution community can start moving faster like your other upstreams That's how you can make money quicker. You can go to market with that new stuff faster You know, so Why hold your teams back? Why why hold why hold your friendly volunteers back? It doesn't make any sense. And yet we see it all over the place And have a lot of fun. This is what open source is about and with that I am done and have a bit of time for questions. Yes So I'm coming from a background where it's more of a building code and Yep Which which is why like your your review process and you're tooling there, you know, that that should be your primary question of You know, can we understand this this contribution in a way that we can maintain it? You know, if this guy disappears so that that and does it work are basically the only two acceptance criteria for anything And like open suzer for example, and I think Those are the only two acceptance criteria you really should have I don't think you should be getting too much into the nitty-gritty of deciding is this, you know Always the right best technical solution if you can understand it and it works. Why not accept it? Can you still maintain it? I mean For example in support for a new platform that you know that nobody else has Yeah, you can't understand it. You can accept it works. Yep How do you make sure that you don't break it if you change something else? That's a fair boy. Um In the case of open suzer, we throw in a new open qa test at it, but um, yeah I mean generally I mean that that should be a fair question for that guy on that initial contribution Like basically, you know in for something like a new platform there, you know, yeah They're creating as an environment where they probably ask a little bit of a question Of you know, okay. Are you going to be able to look after this for a little bit longer? But thinking in those terms totally changes the way you're going to ask that question Then just saying no, we don't support that platform. So, you know, that's kind of it I know it seems all like psychic mumbo jumbo, but Yeah, you do need to think you do need to kind of realize that you should be thinking in these terms to frame that question that way spider So Maintain package that things build on So you had a developer who was maintaining it Don't know if you've lost it. It's still an integral part of the core, but nobody really wants to touch that Then you throw it away and with everything else that's attached to it It's amazing how quickly that motivates someone to take care of that nasty thing at the bottom You I mean you you threaten to do so first and then you do I mean, you know, you don't want to break everything out there But in fact, we just had that which we had just had that Recode, yeah, we just we literally just had that with recode in open sousa. Um, so, you know, that's sorry Yeah Yeah, and that but that kind of it's a perfect example that that sort of craziness actually in this model Drives innovation. We've never thought of recodal as fortune It's a good model Yes, just wanted to comment a couple things about debon and ubuntu. I'm coming from that perspective So you You mentioned that canonical they have this like quite a corporate structure. Yep Which is like I I'm I'm I'm a debon developer and I find it quite difficult to Be in debon developer to push things into ubuntu even for packages I maintain in debon which ubuntu takes from debon But it sort of makes sense for them because like there's quite some difference between red heart and fedora, for example And debon and ubuntu because like in red heart of fedora, like most of the tribe happens Comes from red house even though even if it happens in fedora first, maybe I'm not quite sure How it works in in there, but I guess like most of the people are like red hunt lawyers and they do things and They're so it's but in in debon and ubuntu relationship is different So like the driver force the community behind debon and ubuntu builds on that. That's why probably for canonical makes sense But I wouldn't I wouldn't argue that it doesn't make sense. I I agree that it's open enough Yeah, I you know this makes sense for canonical canonical happy fine. I think it's wrong You know, I don't I don't think it doesn't make sense I just think it's wrong and I think I mean there's the the kind of practical examples that I've mostly focused on in this talk of You know the agility and the ability to deal with you know crazy changes quickly But also I just think it's morally wrong. We're meant to be an open. You know, we're meant to be doing open source Why are we limiting our white? We are why a canonical limiting their options in their code base Long term, isn't that just shooting themselves in the foot with how fast they can go to market with their own stuff? Um, so, you know, I mean I don't really want to make ubuntu a nice You know better competitive than open suzer, but you know if they did pay attention they would be quicker Yeah, I would for debon I'm not sure how how familiar are you with decision Decision taken in debon, but the thing is like what the example you have with system d for example You know technical committee and debon is the very last resort Which is like like if nothing else helps, please step in normally it It it doesn't have any role in any decision taken at all only if the Huge fractions of developers who cannot agree on something or if there's just one developer Which gives saying no to everyone in this case this when the technical committee steps in because like in system d it was one of the situations like that so, uh There was a discussion without involving them Should we switch to system d? Oh, probably we should and there's a bunch of people coming saying oh, no, we hate learners But um, like when he kept you know going on for a long time someone said okay, let's Take it up to the cct cct because we can't stand it anymore. Yeah, like it is I mean, I get that but I kind of want to post. Yeah I get that but but I still kind of want to post the question Of if debon didn't have a technical committee You know, how different could things be if they followed this model more continue for this half a year more Honestly, because it it took quite. I think it took quite some You know Videl when he ended it by just saying okay. I'm I'm the chair. I'm ending this now And I'm using my chair boat, which is normally not being used But he did use it like to gain the majority It mostly like okay people who continued hate 11 they went out and they created debon or whatever like And it stopped without that decision. It probably would continue for quite a long time I see where you're going, but I think I think there is another way. I think I think this probably But Thank you. Thank you. Thank you Oh, yeah