 There we go. Welcome everyone, this is the bits from the DPL with our Debian project leader, Stefano Zacchiroli, so I really give a round of applause. I don't think he needs much of an introduction. Thanks. So I'm sure you're here because this would be the last time I bother you with the bits from the DPL speech at least at the Debcom. So thanks for being here. In this talk I gonna go through two main parts. So the first one is some sort of a set of mantras that have become the way I define Debian today. So I've presented them to various people before. I see there is enough people in the room that won't be bothered because it's the first time they heard them so I hope you will allow me to go through them. And then after this kind of defining mantras of Debian I will present some of the challenges that I think we have in Debian and that we need to take care of to guarantee that we have a longer healthy life ahead. But before that I'm trying to make a point that we did make history. So this is how Debian started in 1993, the first quote. Okay, so 1993 is almost 20 years ago. Back then there were very few Linux distribution around and there were they had troubles, there were the quality was not stellar and people started to think about okay how can we make GNU Linux competitive with commercial operating system. And Ian Mardoch came up with this great idea of Debian and this where all this started. But then we made the story at least in two ways. So one way is a sort of community and social way. So in a more recent interview of a couple of years ago, Ian made the point that Debian has been the first intentional community project. So there were distributions back then, there were first after projects back then, but Debian was kind of designed with community in mind. And with the idea that if you want something to scale to the side of Debian today, we need to have a community behind it. So I think we really made the history showing up our project as big as Debian can be made only in a community driven way. But then we also made the history in very technical ways. So 20 years has passed since 1993 and if we look at today at Debian we have something like almost 40,000 binary packages in Debian proper. We have made 12 release and who knows, maybe we'll make the 13 before the end of this year. We have a project of almost 1,000 members and almost 200 Debian maintainers that have interest in maintaining some part of Debian and various thousands of contributors doing a lot of other stuff useful for the project. So we have the largest number of ports among let's say major binary distributions out there. We have no Linux ports. So we have released a version of Debian that works with a kernel other than Linux. We haven't yet released a version of Debian that works on a kernel like Herd, but for people who like Herd and want to try it, Debian still remains the best choice to do that. So, well done. This is us making this. So, bravo, all of you, we made this. But then one thing is making history in some way, technically or socially. And a completely different thing is remaining relevant. So in this past three years as DPL has been faced by the problem that people were starting to question. That was like a couple of years ago. Do we still need Debian? I mean, why? Okay, you made history. You made a lot of stuff. You made derivatives. You made a lot of stuff. But do we really still need Debian today? So I've asked myself how to answer the question. And a way to answer the question is asking us ourselves what's different from what we do and what the other distributions do. So there are something like 300, 400 active first of the distributions around. So what is that makes Debian special? Okay. And I've started thinking at some answer to that question. And I've come to five specific traits that makes, I think, the Debian project unique. I think it's useful to keep it in mind and to remind why we are contributing to Debian and not to some other similar project. So the first reason, and it's sort of my first mantra that makes Debian special, it's freedom. Okay, this seems obvious, but it's freedom in many ways. So the first reason why Debian is special in terms of freedom is that we essentially have agreed with our public and with Free Software Public in general to keep Debian always free. Okay, we have been promoting the culture of Free Software, not only giving Free Software to people. We have been promoting the culture of Free Software since 1993. And we have a product which is free at the bottom up. There is an incredibly high amount of dog food in what we do. So it is free in the software we give to people. It is free in the way we make it. Every single bit of the Debian infrastructure is free. And nobody would accept if we start making Debian using like non-free stuff in our infrastructure. Okay, this is kind of peculiar per se. And we have also a notion of free-ness in the processes we use. So people who have been around in Debian for quite a while have heard the motto, there is no cabal as some sort of joke several times. Okay, and we use it in saying that, in thinking that there is some cabal around. But the point is that if we make this joke, it means that we really cannot stand the idea that there is someone driving Debian behind the curtain, driving Debian not in the open. Okay, so we're free not only in our infrastructure, not only in the software we make, but also in the way we do things. We try to be as transparent as we could be. And what's more interesting for me is that there is some sort of community awareness of this kind of attachment we have for freedom. So our community trusts us to not betray software freedom principle. And they think that this has been a very high contribution to free software in general. So we have set some sort of very high bar to decide when something is free or not. Okay, when people that need to decide if some software is free or if some license should be considered free software or not, they go basically to three entities. They go to the Free Software Foundation, they go to the OSI, they go to Debian and they see if that license is considered free by those people. And we are one of them. Okay, so first point, which I think is determining what we do in Debian is freedom, software freedom. Second point is some kind of perfectionism, which sometimes strikes back on us. Okay, sometimes make that the trade gets in the way of some of our choices, but we do have a sort of culture of technical excellence. Okay, we have the policy, which is where we have codified our quality needs for packages. We have a huge amount of testing, we have LinkedIn, we have PU parts, we have testing, automatic testing to see that packages matches our policy. We have maintainers who are software experts. So we do not, we try to discourage people to maintain software in Debian if they only know about packaging. We try to encourage people to maintain software they use and software of which they are expert. And this is huge in terms of user support. So when a user come to us, come to the respective maintainer of some software in Debian, usually it finds someone that knows about that specific piece of software. Okay, this for us is quality. We have packages which are all at the same, they are up all to the same quality requirements. Okay, there are no packages, there is no distinction in Debian archive that says we try to have these quality requirements for one part of the archive and a different one for another part of the archive. Okay, and also when we say we release when it's ready, it's our way to say that we know we cannot commit yet to a specific date because we fear finding issues, quality issues just before that release date. And we fear compromising our release quality for that specific day. So when we say release when it's ready is also a matter of quality. Third point, and it's something important from what I'm going to tell you next, is independence. So if you look around at the ecosystem of distribution out there, you won't find many distribution where you cannot pinpoint a company that is back in the distribution. Okay, among the big distribution, we are one of the very few that is completely run on a volunteer basis. Okay, that we have no corporate or some sort of hierarchical structure that where the decision come from top down. Okay, we have no single company babysitting us. Okay, and we essentially live up to donations in term of time. So volunteers contributing time to Debian and donations in term of money. Okay, this is very remarkable in the ecosystem of today, especially in free software distributions. And once more, we have a phenomenon of community awareness. Our community seems to trust that due to this independence of us, decisions in Debian won't be taken due to some profit reason or other kind of reason than our own core values. Okay, so independence is another very important value for me that motivates me to contribute to Debian. And then, we have decision making. Okay, so decision making, it's something that is very well codified in our constitution. So the basic role which I started to call a while ago, duocracy, actually I picked it up for someone, but I don't remember from whom I did pick it up, but it seems to be sticking around. So essentially it says that if someone is responsible to do some kind of work in Debian, as long as he is doing that work, well, they decide how to do it. Nobody can go there and say, you need to do that work in that way unless they're ready to commit and do the work themselves. And this is the default role. All decisions in Debian, by default, are taken this way. Okay, and then we have also democracy. So we have some kind of potential correction on how we take decision. So we are allowed to take decision altogether in a democratic way, voting on stuff. We are wise enough to do that only, and in general, only for political reason, for philosophical reason. We try not to do that for technical reason, but we can do that, even for technical reason. So we try to use this as some sort of way to make the default way of taking decision work. Okay? And what this means? This means that it's very easy to have an impact on Debian. Okay? If you know how to do something in Debian and nobody is doing that, you can't pick it up. Okay? And if you start doing it, you will decide how to do that. Okay? So this is where it's very easy to have an impact in Debian thanks to the way we take decision. But it also means that the reputation in the project follow works. Okay? If you have a good reputation in the project, it's usually because we have done a lot of work and a lot of very high quality work. Okay? And finally, once more, it means that there are no imposed decisions. It's not like the people who own the infrastructure or who employ people can decide how decisions are made. Okay? Decisions are made this way. And last point, we have ended up being at some sort of throat of a huge ecosystem of derivatives. Okay? So I believe you all know what derivative is about. You take an existing distribution, you start a compiling packages, you add your own package, you change stuff. Okay? And you obtain a completely new distribution. And this is something that's starting to happen in the last, starting to happen massively in the last, let's say, 10 years. Okay? And they've really changed the way in which distribution products are made. Derivatives can focus on customization and benefit from all of the work that is done by their mother derivatives. Okay? And Debian ended up being a throat, something like 140 active distributions according to this watch. So that means that the work we do in Debian is not only relevant for our own, let's say, direct user. It's useful for the users of all these sort of distributions, which include the most popular distributions out there. Okay? So people out there, even if they do not know, rely a lot on the work which is done in Debian. And I think this is great. Okay? So, all in all, my point here is that Debian has a very important role to play in the free software ecosystem in general. Okay? And if we fail at doing what we are supposed to do, not only the direct users of Debian will fail. Okay? I think free software in general will suffer from a failure in Debian of delivering what we are about. So the question is, are we up to what we are supposed to do in free software in general? And I've seen some challenges that I would like to discuss with you. So the first challenge is staying healthy. And staying healthy for a free software project, for a volunteer free software project, essentially mean being able to recruit people to find new volunteers that here after a year join the project. And if you have heard me talking at webcam for the past two years or in general to the Debian developer public, we have always discussed the lack of manpower as a major problem in the project. We cannot do stuff because we have a lack of manpower. Okay? So in fact, I've looked up the data and our recruitment, if we can call it this way, is going very well. Okay? So over the past two years, we have had 30 new DDS more every single year. This is net in the sense, this is an actually increase in the number of DDS. So I have already discounted the number of DDS that drop off the project because some sort of natural turnover. Okay? So 30 DDS per year is quite a lot. Okay? And if you look at containers, Debian containers, we have something like 50 new Debian containers per year. So this is gross because I didn't find the actual net data, but it's a given idea that we do, we are able to recruit people, both to work on Debian in general, whatever the task, and to work on specific packages in the archive. Okay? So I think we should really stop using the lack of manpower as an excuse. We are a volunteer project, we will always lack manpower to do something, but our ability to recruit new people is doing well, is doing very well. So what we really need to do is to actually better use the manpower that we do have. And in particular, I'm worried about the barrier for contribution that exists within the Debian project. Okay? So one thing we discuss often is we don't need people to maintain yet another package in the Debian archive. What we need is people working on some of the core team, the very infrastructure team or in maintaining the very important package in the archive. Okay? But the key to make that work is to make it easier for people to contribute to those teams. We have a lot of services in Debian which are very difficult to contribute to. We have services which are online, which we have no mentions of where is the code behind those services, of where to report bugs for those services. These are all small attention that we could use to make it easier to contribute within the Debian project. And if someone starts working on some leaf package in the archive and if it finds easier to contribute to some more important stuff they will do that. In fact, that's how I think most of us that got involved in the Debian project ended up doing more and more important stuff starting from the easy part and climbing up a bit doing the more complex stuff. So if you're working on something within the Debian project, in addition to think at the work you're doing, please think at how can I make it easier for others to contribute to this. Have I documented how to contribute to this? Have I put a link of where is the source code of this thing I'm maintaining in Debian? Have I mentioned who should they contact for a project? All these kind of questions. This is what it will help in better using the main power we have in Debian. And another one, and someone will probably kill me for this, is diversity in various sense. Okay? So I think we have realized that to do an operating system like Debian, we need a lot of skills. Packaging is not enough. Packaging is one piece in the puzzle, but we need a lot of other stuff. We need translations, we need people doing artwork, we need the system administrator, we need porters, and all these kind of skill are quite different. We need software developers, and good packages are not necessarily good software developers and vice versa. We need a whole lot of different skills. And we should not think that packages are good at doing all of it. It is not the case. The skill needed are very different. So this is one reason why I think diversity is good for a project at Debian. But I think it's good also for the culture, the discussion culture in Debian. So if you know that in a discussion place you will find people that have very different background from yours, a very different point of view than yours. Well then you need to be more cautious about how you write things. You need to make less assumptions when you write things. So having a more diverse project actually helps also in having a better discussion culture. So this is the second reason why I think diversity is good for Debian. So we have done a lot in the past few years. So we have sort of fixed the membership project, process, sorry, making it clear that we do welcome people with a wide range of skills joining Debian. And we have also more recently fixed the NMDB.org website to make it clear to avoid implicit assumption that there are only packages that we welcome. Okay so this is great. We have done that. But as Christian mentioned in the previous talk, stealing my argument, we are not doing very well at attracting people who do stuff other than packaging. So in two years we have attracted only five people in the so called non-uploading DD category. So these are only five people that decided to join Debian as project members and said you know I don't really care about packaging. I want to do something else in Debian project and I commit to do that on a longer basis. And I but I do understand the value of the Debian project and I'm ready to uphold that. Only five is a bit, it's quite a few. Sorry it's not too much. So we really need to understand how to invite people with different backgrounds and packaging to join the Debian project. So I think the diversity statement we send out is a step in the right direction but we need to do more. I don't know what exactly but we really need to do more to attract those kind of people. Some other challenges are related to the release process. So I'm still amazed that people on the net still complain that Debian has unpredictable release cycles. The other day I replied on Linux you can use as someone that was complaining that Sarge has been very much delayed as release. Yes that's true. Sarge has been a delayed release like three years or something but it is something which happened seven years ago. Even in the time frame of Debian that's a lot. That's one-third of our time in existence. So since then we have learned. So the release cycle of fetch took 22 months. Same for the release cycle of Lenny. The release cycle of squeeze took 24 months. So all of this looks pretty much predictable to me. Okay so I think we're doing well on that front. And starting with Weezy for the first time in our history we've done time-based freezes. You probably know that I'm a huge fan of that. Not all of us agree with that but I think it's a huge step forward because it helps developers in planning ahead changes. Okay yes there are people that will upload last minute no matter what. I understand that. But for all the people who want to plan ahead that's a huge help. And it also helps our upstreams. There are upstreams out there which very much care about the version of their packages that will end up in a stable Debian release. There are people out there that if they know we freeze on a specific date they will commit to give long term support for that software. Okay so knowing a freeze date in advance is huge help for them. So I think we should keep this in mind. Keep this in mind what was not working with the previous model. Like people getting upset of about freeze without knowing in advance when they were going to happen. And I think we should try to not forget this. So aim in the future at reliably freezing every x months. 24 maybe. Little more than that, fewer than that. I don't know. But I think we should try to keep this in mind and maintain that in the future. In the case you didn't notice with this frozen okay. And we did this with a time-based phrase. I think it worked well. But there is still a lot of work to do. And in particular we have frozen with something like 135 more RC bugs with respect to the previous table release. So there is a lot of work to do for all of us. Okay. In this work which is ahead of us, I think we should really aim to have a short freeze period. Okay. That's something I think we should aim to. It will happen, it will not happen, it will depend on us. But I think it should be a goal. Okay. It should be a goal because it will show us that time-based freeze is a sustainable model even if it means freezing with a bit more bugs than before. Okay. It will reduce the period of time in which we are a bit frustrated in which you cannot do far-reaching changes. Okay. So the shorter we can keep this period, it will be better for people who really wants to make some more profound changes. Ashish, do you have a question? Sorry. So the question is how short is good? Well I don't know. I think it should be a goal. I don't think we can say, well I mean staying within the limits of the past trend, like six months, I think that's would be good. Better would be shorter than that. But this is not really a question for me. I mean this is more for the release team. I think we should have in mind that we should do all we can to keep that as short as possible. And also there are distributions out there that rely on testing. So we do have in mind a single product which is Debian stable, which is a great product. But like it or not, people out there are using Debian testing as a product. They are using it on their desktop machines, on their development machines, because it's kind of the thing that invented rolling distributions out there. And it's a great suite. Okay. So keeping it short, keeping the release, sorry, the freeze period short will also help other people that rely on something like Debian test. So how do we do that? I don't think it's really normal to have that many release critical bugs at a freeze point. It means that there are maintenance, it means two things, that there are very hard back to fix, which is normal. But it also means that there are some maintainers that kind of neglected their work, that didn't manage to complete to clean up their packages of release critical bugs before the freeze. Okay. But it happens. We are here, it has happened in the past, it will happen again in the future. So the only way I think we have to release at this point is to once again keep in mind that releasing is not something that the release team does alone. They cannot release with the alone. Okay. So I've been bothering you with this idea since ever, since way before I became a DPL. But I think the only solution we have for this is doing an emu's, accepting an emu's, welcoming an emu's, loving an emu's. So every single day please have a look at the list of release critical bug reports. I look at this graph essentially every morning and also at the afternoon coffee to see how we are going. Okay. Really. Please do the same. Then please every day look up if there is a release critical bug you can fix. Even and especially if it is not in your package. Okay. There are people like Gregor which is somewhere here in the room that every single day, thanks Gregor, every single day tries to do that and publish the initiative to make other do the same. It is not the only one. A lot of other people are doing that. But also publishing it is very good. Okay. And really any muse that fixes bugs are free for all. Do them properly. Try to make it clear that we're trying to help the maintainer of the involved package. But please that's the only way we are going to release we easy. Really. And if you want another way of looking at this it's for the software engineering fan is collective code ownership. Okay. So collective code ownership is a notion that well with this term comes from extreme programming. Okay. And essentially says that all programmers have access to all of the code of a project. Okay. So that no single person can be a bottleneck on a specific part of the project. Okay. This is considered good in agile development. This is considered a best practice to follow in open source project management. But in some way it's not always considered good in Debian. Which is kind of weird. So in the past we didn't have this notion of maintainer. Then BDL will correct me if I'm wrong. In 95 it has been introduced. Is it right? Something like that. Okay. Thanks. And with that we sort of added some barriers. There are useful stuff behind the notion of maintainer. Like pride in what you do. Being recognized for the work you do. Which is great. But we should also keep in mind that there are barriers with the notion of maintainer that make it harder for other to contribute to your package. So the best approximation we have to collective code ownership in Debian is essentially being more liberal with an immune. And team maintenance. But we don't have teams which are as large as the Debian project. So liberal and immune is really our best approximation for collective code ownership in Debian. And then moving to the past two which probably will be a bit more controversial. So low company involvement I think it's becoming a problem in Debian. So if you look at other similar projects to Debian with the same kind of history and with the same side you see that Debian has less paid work opportunity around. And you see that we have few companies which are contributing directly. Okay. So think at the, I don't know, the Linux kernel. Everyone who can show that can get code in the Linux kernel will find a job in five minutes. Okay. We do have companies that will be happy to hire Debian developers but not as much as you have around the projects at the Linux kernel. So for me, volunteering is great. I wouldn't work on Debian on paid time. I would not do that. I work on free software for volunteer reason. It matches my view of society where each of us has a work and some extra time after work in which he does something to contribute to society. So this is not really for me but I think it could be a problem for Debian in general. Why? We do compete with companies and full, and they're full stuff, sorry, and they're full-time employees. Okay. So our concurrence are commercial distribution with huge means in terms of employees who are working on the distros. That's fine. We don't do this to, we don't do free software to, not only to make money, but we need to watch out for our morale. So when we start thinking stuff like Debian is not innovating anymore, it is other distros which are innovating, well, we need to keep in mind that the ratio of force on the field might not be very well balanced. Okay. So this is the first problem that they're thinking of having low distribution contributing to Debian. Second reason is that there are useful tasks out there that volunteers won't bother doing. I've been asked many, many times, why don't you go to outdoor vendors and convince them to pre-install Debian on their machines? Well, try to find a volunteer that is happy to spend his time in, you know, lobbying a hardware product producer to install Debian on it. That's an example. Other examples are all sort of certification lobbying. Something that very often public administration asks me is why Debian is not certified for random very high-quality corporate database system. Okay. Why Debian is not certified for that unnamed system? Well, because you need lobbying to do that. You need people going to the software vendor and convince them to say, yes, you can run this on Debian. Otherwise, there are people out there who won't run Debian. Okay. And all sorts of other stuff, like creating a support network that makes specific adopters convince them that it will be fine, they will be fine adopting Debian. Okay. And the last reason why I think we need a bit more of company involvement in Debian is a sort of disturbing thought. What if only one company or a few company for what is worth end up hiring how a lot of DDs? The independence I've been bubbling around before will be gone. This is not paranoia. This is a kind of problem that has been discussed for instance in the Linux kernel community for a long time. They know that they have some sort of independence because they have many different companies with interest in the Linux kernel which sort of balance each other. So if we don't have more companies interested in Debian, we risk ending up in that situation. So some sort of very early work in progress which is trying to kick start is a sort of user group Debian companies of companies with some strategic interest in Debian. Okay. And we want to try to work on fixing this problem. There might be other solutions. I don't know. I wanted to present this a problem. I think in the long run we need to think about this. And the last thing is the DPL which happens to be me at the moment. So what does the DPL do for you? So according to my family possibly too much but that's a separate problem. So it does fancy stuff, right? It goes to conferences around the world is invited to talk about Debian and he has a Wikipedia page and all this kind of fancy stuff. But he also has to do all sort of needed but pretty boring for the average geek stuff. Okay. He has to take care of money, approving reimbursement, buying hardware, debconf donations, try to avoid bankruptcy which is a nice thing to do. And it takes care of lawyers. I've never been working with lawyers as much as in the last three years. Okay. So it takes care of what we do with patents, can we have it in the archive or not, what we do with train logs, what we do with copyright for instance. Can we re-license the Debian logo with right on their mining some other asset we have and legal responsibility. And what if a Debian developer gets a lawsuit? Okay. All this sort of stuff which is useful. Because if we now have a bit more, how to say, announced multimedia experience in Debian is also because we take the time to discuss this stuff down with lawyers that are experts in free software. Okay. And then it does mediation and it does reports. Okay. How many reports from me have you got in the past three years? Yeah. Too many. Okay. This is all sort of boring stuff which I think is useful for the project. But then, as it is today, the DPL is a problem. I am a problem but not me. It's the role of DPL who has a problem in Debian. It just does not scale. Okay. We basically rely on some sort of luck. Okay. That we will find candidates that will have enough time to do all of this. Okay. And it's quite a bit of time. I don't know if it is wise to only rely on luck to finding those people over the years forever. Second problem. Transparency is very hard. I've tried to work quite a bit on that. Okay. I think I spend like half of my time as DPL in trying to tell you what is going on and only the other half in working on stuff. I've been happy to do that but it's very hard. And as long as I'm talking to myself or applying to inquiries that comes to the leader mailbox, there are some sort of intrinsic limits. If you are in a team of with more people, you need to discuss things and if you force yourself to discuss things publicly, you don't have these intrinsic limits. And the third problem is there is very little institutional memory. Okay. So we keep on essentially rediscovering the job at each DPL change. Okay. Yes, I can write a DPL out to with the help of all past DPLs. We can do that. Okay. But things change. And essentially the key of the problem is that being the DPL is unlike any other task in the project. So it's difficult to know who will be a good DPL before because he or she has never done that before. Okay. And there is essentially only trial and error. There is very little institutional memory of how to do things. So how can we fix this? I've been thinking a lot about this is one of the reason why I decided to run again for a third time. So essentially I think the problem is that the role of the DPL is a relic of the benevolent dictator era in free software. Okay. It made a sense in the past. Okay. Today, projects of the size of Debian are not run in this way, not even for only the management part. Okay. So we do not do the technical part with the benevolent dictator, which is very good. But we do that for all the kind of management parts. Okay. So I think the solution, the only solution possible here is have some sort of both of directors that other projects have, which essentially help the DPL. The role of the DPL should not disappear. I think we should try to keep this as informal as possible. But if we have a group of people that we can call the Debian Board of Directors that can have some sort of turnover, okay, to guarantee that there is some institutional memory. So there should not be tied to the normal DPL period. Otherwise you have the problem of institutional memory again with periodic meetings for transparency. Okay. And if we do have this, you can have the people on this kind of board that help out and show if themselves they will be able to do good DPLs or not. Okay. So I think this is the only way to make the role of the DPL scalable without changing the nature of what the institution is. And as an interim solution, I'm trying to collect a group of DPL helpers. You have to think they call for help thanks to all the people who are applied. So what I'm trying to do is to try to see if these kinds of things could work. And yet the DPL will remain. So given I'm here basically because someone a few years ago started joking about me becoming DPL, well, that's a good occasion for all of you to start thinking of the next one and maybe start joking with them whether he or she will be happy to candidate the next year. So thanks a lot. It's a pleasure to be here. And if you have question or thoughts I'm available. Thanks. The last part where you talk about solving the DPL problem really caught my fancy because I've given a lot of thought to non- corporate organizations. I'm very, very ignorant about your job. So please take that in mind if I say something you think is really stupid. Now, board of directors, I personally, even before you said that I was thinking council of elders. Now there's a big difference there. There's a big difference there and it goes beyond the choice of words and your particular leanings sociologically. Because one idea that I had is you could try to integrate a board of past DPLs. That means they inherently know about the job. Like I said. Well, you know what's the problem? I came from a counter where one of the main problems is that very elderly people are ruling and taking decision for very young people. So I'm kind of a fan of the idea that you should really change people doing stuff over time. So getting elderly people start to get more fixed on their past position. I know something where you need some kind of a new meant. But yeah, I see your point. And another couple of ideas that I had was one is it seems to me that the DPLs should not, that one DPL should not start when the other one ends. Transition period. Yeah, sure. I agree. That would be useful. Which includes mentoring, but also not just like you're the new DPL and I'm here as an advisor, but an actual overlap of responsibilities. And that forces discussion, forces some level of transmission of knowledge. Yeah. And the other... I think we should need some space for others to... Just as a reminder for video team folks, there will be a video team meeting 10 minutes after this talk ends here. So keeping the same subject, could you elaborate why you don't think a DPL board would work? So would not work or would work? So what I think would not work is having a DPL board as proposed in the past, which is tied, which is basically elected together with the DPL and will last the same time as DPL. Because at that point you have again the problem of that all those people, we need to learn the job when they change. So I think it should be around more than a single DPL period, mainly to have some sort of institutional memory of how you do things. I actually mean, turnover is fine with me, but why don't you think that a board of directors without a single DPL entity, but being DPL as a whole, a whole team of DPLs with turnover? So you mean elected all together? All with turnover, like replacing three members at a time for example? Yeah, no, that I think is what could work. But my point is that I think we should first convince ourselves that it works before trying to start voting and have institutional decisions and all this kind of stuff. So this is the direction which I mean, all other big free software project out there has been using for the past 10 years. And I think it works. The question is how you get there. How do you see what you think is the difference between delegates and the board of directors? Okay, so that's a very, very good question. Thanks Kurt. So the problem with delegates is that we tend to make the delegations which are not time limited. Okay? So essentially, every time you delegate someone in a non-time limited way, you are creating some sort of power that will need some specific action, either to be changed or only to say, okay, I want to reassess whether I'm still interested in doing this or not. So it could work, but it requires, so either you start doing time-based delegations and keep track of them or you have the problem that you are creating entities that will stay unless someone says no, you need to go now or they step down voluntarily. Just a quick question. So what exactly is stopping us from engaging in this now? I mean, it doesn't look like there's any particular permissions necessary for the DPL board. They can self-select and start having meetings. I think nothing is stopping now and that's why I've been calling for helpers. The idea is that will be the seed from which try if this works and if it's worth making it more stable in the long run. So essentially what's missing is, guess what, people doing the work. But seriously, here I think an important part is that it's more easier to find DPL candidates than to find volunteers to work on DPL tasks before the elections. Which is kind of scary because it might seem that you have a motivation to candidate for DPL, but a bit less so to do that before. So, one very brief suggestion about how a transition period might work and then a sort of topic, a question that's about delegates and how to solve the same scaling problem there because you're the DPL so thinking about the whole project. So as far as a transition period, what would be really useful, which I don't think our current rules allow is after the new DPL is chosen, instead of having two DPLs at once, that's kind of confusing but maybe a month or two where the old DPL is still DPL but the new DPL is already known so that they can explicitly be learning and then a month or two of advising afterwards. But about delegates, for scaling delegates in a way that doesn't make people have too much long-term institutional single-point failure memory in their head and doesn't allow people to get too fossilized in a role but still allowing them to serve in for several years in a useful way, what do you think about that? Well, I think it could be an improvement but I think it's just a small patch, an incremental improvement on how we're doing things while I think we really have a more substantial problem here. So it could be an improvement but I think we need some changes. I think personally, that's my opinion of course, if you start going to systems where you have overlapping DPLs you have a very large risk of having a lame duck DPL who is afraid to still make decisions and for that reason me personally I'm not in favor of that sort of solution. Although I think you need going to an elected board or something could be a good solution but I'm not in favor of that. So it seems I made a mistake of raising a point that is very, you know, it's tickling the idea of, okay, how we can change the formalities in Debian. So thanks a lot. But if you also have a question on something else I've said, please feel free. But if you really only have a question on this, of course, go ahead. So one of the things you said that makes Debian significant is the fact that can you? Maybe. Yeah, one of the things you said makes Debian significant is the fact that we have a standard of free-ness that other people look to to help them decide. We have a standard of free-ness that other people look to to help them decide whether they're doing okay. And I'm wondering if our process for giving folks that the feedback they need needs reinforcing and needs a health check in terms of the Debian dash legal mailing list is where that activity happens. And Debian dash legal certainly has a reputation within the larger developer community of being a bit of the inmates are running the asylum. And if this is something that is important and that we agree that this is important, let me encourage other developers to participate and be voices of sanity there. Because it's the place that outsiders go to get checks on their licenses and if there aren't actually people who are Debian developers and who are actually going to provide the advice and provide an opinion that has some semblance, some resemblance to the actual project's opinion, then that's a problem. I completely agree. It's a problem. And I've seen this many times people coming to me and say, hey, Debian thinks this of that license. Because on this thread, on Debian legal, this is the outcome. So I agree that it's a problem. First of all, the problem is the mismatch among those particular, a threat on Debian legal and the actual position we have. I think the first solution that is already on the website but not really well known is making, is publishing our decisions about licenses and our rationale for that. So right now, the authority that decides what's the FSG free and what is not is FTP master. This is the current status coin Debian. So when they say something is not free, they usually provide very good argument for that. The problem is that it's essentially posted on some nailing list. Last time, I think, it's been on Debian project and not really easy to find, not really well documented. So we do have, on www.debian.org, a page with the license with consider free and the license we do not consider free, but it's very little known and it's not really up to date. So I think the first part of the fix there is fixing that kind of editorial part. And then for Debian legal, so I've never participated on the mailing list, so I cannot really say how the climate or whatever else on that list can be fixed because I mean, I would speak of something I'm not competent on the way. So time's up. So last thing, I will surely will do that on mailing list when the time come. But given last time, I talked to you in person, I want to do it here. So thanks a lot for this past, well, two year in a house that will become three years. You're a very demanding community but you're worth every single bit of it. It's thanks a lot.