 Okay. Hello. Can you hear me? Great. So in a minute, we will have WM project leader talking about the WM and the challenges that await us. I would like to remind the audience not to interrupt him. Once he's finished, there will be a question and answer session. So I present you, Stefan Zakiroli. Thanks. So if I now say that I welcome questions during my talk, would you be offended? Thanks for the introduction. Thanks to all of you for being here. I want to point out that I didn't want to enter on a Herm Chair as much as I didn't want to pitch during a baseball game last year. And it always feel ends fault. So welcome to DebConf. It is always a pleasure and a honor to be here and address the DebConf people at the start of the conference. In this talk, I just want to share with you some thoughts on the role of Debian and what we are doing and why we are doing it, and some of the challenges which await us in order to be able to keep on fulfilling our role. So I usually start with a bit of history, which I guess if I've seen other thoughts of mine, it's familiar with you, but still it's an important starting point. So the first quote is the announcement of Fian Maadok that he was creating what we now call the Debian project. So it was 1993, 18 years ago, and back then it was seen as something quite idealistic. Back then there were a couple of distributions and no one believed that a group of volunteers can put together a competitive distribution able to compete with a commercial operating system and especially nobody believed that it can be done in the open and only on a basis of volunteer people. And in a recent interview that you can find on Linux.com, which is pretty interesting on the history of Debian, Ian essentially stated what I believe is true, that Debian has been the first intentional community development project of this size. So there was some software development project with them, but Debian is the first large scale distribution which has been made in a completely community-based manner and we are still doing that. So this was 18 years ago, 16th of August of 1993, and 16th of August this year we will be celebrating 18 years, so Debian coming of age. Now, 18 years later, we have a distribution which is a very interesting software project and a very interesting community project. So we have today in AMD64 seed main something like 33,000 packages and that makes Debian possibly one of the largest software project in existence, even if we do not develop the project, we try to keep all the pieces together. We have released 12 times, the last release is a squeeze as you all know, and we have a project which is made by a few thousand people, 900 Debian developers, 150 Debian maintainers and thousands of contributors which it's not very easy to quantify actually, translator, people doing ports, people submitting bug reports, it's not really easy to count, but a ballpark figure of several towns is probably appropriate. Our distribution, Debian, is among the so-called, let's say the most popular distribution, among the mainstream distribution, as the largest number of ports, so we have about a dozen of ports that were released, and we have also released for the first time we squeeze a non-Linux port, which is, if you ask me, quite an achievement, and we are also considering to have a hard port coming with the, with Weezy, so if you ask me, well done everybody, this is something we have done together, so thank you, thank all the people submitting patches reporting bug, this is what we have done together, and it's pretty incredible if you look back at 18 years from now. So this is what we do, what we do, and I think is great, but is not really enough, so back then in 1993 there were really not that many distributions, there was what is now called Slackware, there was I think what is now called SUSE, and that's pretty much it, so it was reasonable to have a new distribution made in a different way than what was made before, it was something that was needed, and nobody was saying, okay, you know what, we don't need that, and we don't need something like that, but now the situation has changed completely, so there are a couple of distribution review sites, which I believe you are familiar with, one is DistorWatch, the other one is LWN, which maintains an index of distributions, and if you go there you will find something like 350, something like that, active free software distributions, so we are not the only one, by far we are not the only one, there are hundreds and hundreds of distributions doing something similar to what we do, and among them you find many differences, you find distributions which have a different release schedule, which do things in different ways than what we do, maybe they are based on some corporation, they might have a different degree of support for software which is in distribution, different packaging system, different look and feel, different target for users, and so there are a lot of differences, and if you ask me, it's important to be able to answer what is so special about Debian, so we should not do Debian just because we have always done that, people in this room are, there are developers which have been developing Debian since the very first days, I have been doing Debian myself for the last 10 years of my life, but that's not enough, I should not continue doing Debian just because I have always done that, we need to know why we do Debian, so at last DebConf in New York when I was doing my DPL speech, I made a small exercise with the public asking why we are doing Debian, I'm not going to redo that again, because maybe bore some people that have been already there last year, but I'm going to share some thoughts on why I personally think that what we do in Debian is special, and why what we do in Debian is something that no one else is currently doing in the ecosystem of first of the distribution, so the first thing which qualifies Debian is quality, sorry for the word trick, so I like to say to people, because I believe it's what we do, that we do have in Debian what I call a culture of technical excellence, we are perfectionist, we want things to be done right, not just to meet some sort of deadline, but we really want to do things done right, and we have written this down in several places, the policy, so we are pretty interesting project in our use of the policy, so we have a formal document stating how a package should look like, and that's very helpful both for developers and for people depending on us, and then we have a whole lot of testing tools, we have PIP parts, we do periodic archival builds, we guarantee that every single source package which is in a release Debian distribution can be rebuilt from source, and this is important because if you cannot rebuild the package from source, then several of the advantages of the software are just many hypothesis, are just something that you is not really granted to users, so all this is technical quality in Debian, then we have other cultural traits which make up the quality in Debian, we have maintainers which in general know not only about packaging technique, but in general they also know about the software they are packaging, it's not really well accepted in Debian to have someone who does not know a specific software to package it, because we want maintainer to be able to answer a very in depth question, and we want maintainer to be able to collaborate with upstream to improve the software. Finally, we also have that all packages in the archive are equal, okay this is an ideal, there are some cases which that's not true, for instance orphaned packages, but in general we try to have all quality guarantees equal for all packages, we do not say Debian only support this tiny subset of the archive, but we do support all the archive, and finally if you think of it, our release mantra, we release when it's ready, is actually another way to say that we are here for quality, we are not ready to just say we will release that day, because we might have blockers that day, so we just say we will release when all RC bugs are fixed, so all this for me is something that makes up Debian quality, and it's something that I believe is pretty unique. The second point is freedom, so Debian is based on a group of people which are united together to make the best possible operating system, and what keeps up together is what is written in the social contact, it's essentially the only thing we have that we know we all agree upon, maybe we can have different interpretation, okay, but that's what keeps us together, we have been in some way promoting the culture of free software for the past 18 years, and we are completely free in many ways, so the first obvious thing is in the software we distribute, everything, including firmware now, is completely free in Debian, and we will always be, but not only that, Debian is free in the infrastructure, all the tools we use to make Debian are free software, most some are developed by ourselves, but still are free software, no one in Debian will accept using some non-free software to develop Debian, or some non-free software to actually offer a bug tracking system or something to the user which is not free, this wouldn't be acceptable in Debian, and a different kind of freedom we enjoy is actually also in our processes, so we are here to have open processes, we of course have no cabal at all, so this is another way of being completely free and being open to people, well, sometimes we fail, but still that is the direction in which we want to go, and our community knows about that, they respect us for this, and essentially what we have done with all this is setting a very high bar for software freedom advocates, so if someone claimed to be someone advocating for free software, often it makes a comparison with Debian, so how are we doing when compared to Debian? And this is an important role, it's not only software, but it's a way we have been promoting free software in the past 18 years. A third point is independence. This is something I didn't realize in the beginning, so it's something which just came on us, but it's becoming more and more important every passing day. So we are a project of volunteers, well, there are people who can be paid by their bosses and work on Debian, but the project itself is based on volunteers. We have no corporate or hierarchical structure, we have no power structure, we have very little device in which doing something can be imposed on others, so there are essentially exceptions, and we don't have any single company which can claim that they are taking care of Debian, that they are babysitting us, okay? We have these companies which donate to us, but no one can say, I am the company behind Debian, and if you ask the public, no one will be able to say, okay Debian is essentially the same thing as this company. How do we work? Well, we do need money, we do need resources, we get them by donations of either money or hardware, and everything else is a sort of gift economy. So we work for each other, we exchange patches, and that's how Debian work. So if you do a small exercise and go through your mind at the most popular pre-softer distribution in existence, in most cases, you will be able to associate a distribution to a company, either because it's what we call a commercial distribution, so created by some company, or because even if it's a community distribution, all the infrastructure, all the machine used to run the distribution came from a single company. This is not the case for Debian. And this is, I believe, very important because in our case, we have people who trust our choices not to be driven by profit, not to be driven by commercial interest. And if you think at recent acquisition of big companies which used to be free software friendly, and then after the acquisition, they are not so free software friendly anymore, well, you start to understand why this is very important. So to do what we do, to push for free software, independence is really a key device we need. Then we have a kind of peculiar way of taking decision, which is a sort of a consequence of being independent. So the default way in which we take decision is what we call a duocracy. So our constitution is very clear on the fact that anyone who is working on a specific task is free to take all the decision you want on that specific task. No one else can go to that person and say, no, you should do this differently unless that other person is ready to do the work in place of the maintainer or whoever was in charge before. We do have also democracy, but we tend to use it not for technical stuff, but let's say for political decisions, but it's a good way. So it's a good way to say, if someone abuses our rule, we do have a way to overall the rules which we believe are being abused. And if you take these two things together, it essentially means that the reputation in the Debian project is very strongly tied to work. Someone who is well-known in Debian is someone who does a lot of work and is respected for the quality of the work he's being doing. There are no other ways to be well-known in Debian. We also mean that there is no benevolent dictator, which is something which exists in many other software development projects, and ultimately it means that there are no decisions which are imposed on us by some external entity, by someone who has the money, someone who has hired a lot of people, or someone who is owning all the infrastructure we use. And the last point, which I think makes Debian special, it's this fairly new, well, respect to the history of Debian, fairly new, a notion of derivatives. So derivatives is a phenomenon which started having a really high importance in the past five years, I would say, and have changed the way in which distributions are made. So you start from an existing distribution, you pick some packages, you add some new packages, you add patches if you need, you rebuild, and what you obtain is a new distribution. And the advantage for the derivative distribution is that they can focus just on the customization. I say only between quotes because it can be a huge amount of work, even only synchronizing with the upstream distribution can be a huge amount of work, but still is way less work than having to maintain by yourself 30,000 packages that exist in the Debian archive. So this has changed the way in which distribution are made, and Debian is sort of the champion of derivatives. If you look at the indexing site for distributions, you will see that something like 130 active derivatives are either directly or transitively based on Debian. This is about one-third of all active distribution in existence which do benefit from the work we do in Debian. So that means that any user, either of Debian or of some transitive derivative distribution of Debian, benefit from our work, and even more so probably depend on the work we do in Debian. And if Debian fail, if the well-being of Debian is not granted, all those users will suffer something. So to summarize, there are quite some reasons why I believe that Debian is unique, the quality, the freedom we offer, the fact that we are an independent project, the way we take decisions, and all the derivatives which are based on our work. All these together make Debian a quite unique player in Free Software in general, and I think it's our responsibility to be up to the task. So if we fail, not only Debian will suffer, I think that in general Free Software will suffer a very important loss. So the question is, are we up to the task? Are we doing enough not to fail and to guarantee that we're playing our role in Free Software? I think we are, but there are various things which we should watch out for. In particular, I made an experiment in looking if these points, the way we do things, can strike back on us. So what are the drawbacks or these characteristics of Debian? And are they affecting us in any negative way? So to conclude, I will go through some of the way we do things and ask you and ask myself whether the way we do things can have a problem and something we can try to fix. So last year, one of the main blocker, one of the main hindrance I've been discussing in my Debian talk was the lack of manpower. I've discussed that because it was one of the most commonly reported problem in Debian. I've been going through a Steve team review, which are a couple of years old, but still it's pretty interesting grade. And one of the most reported problem was we lack manpower, we lack workforce. We don't have enough people to do what we are supposed to do in this team. And so we went through that last debcov and well, you know what? We still lack workforce. We are a volunteer project, we will always lack workforce. We cannot simply go and hire people to work on the stuff, we are not, which is not being attended. So yes, we do lack workforce, but it's not true that we are unable to attract people. I've been through some numbers and this is the number of people we have been attracting recently. So the number of people voting with the right to vote in DPL election 2010 was 25 DD less than in 2011. So this is a minimum number about 25 new developers in one year. Actually it can be more, because that's just the total number. The number of new DDs this year up to June is 13 person. The number of new DDs in the last, the DM sorry, in the last year is 30 person. That might not seem much, but if you look at the stats of active developers by looking through the uploads and the people who actually vote, this is about 10% of DDs new in one year, which is I think is pretty good. And the number of DM was like 120 and become 150. So we do have new people. We are attracting new people. It's not true that we are unable to attract new people as we often repeat ourselves. So this is, I don't think it's an argument. I think we are good in attracting people. And beside that, don't cry for the lack of workforce because it will always be the case. We should not use that as an excuse. So rather, we should try to put into better use all the people we have, all the workforce we have, all the volunteer we have. So let's go through our characteristics and see how they can strike back. So we are up to quality. Can quality be a problem? Can quality be something which holds us back? Well, yes, it can be. All other factors being equal, doing something of better quality requires more time. So if we have higher requirements for our release, well, it will take more time to put it together. That's for sure. But we are actually doing pretty good. So if you look at the past four releases, we have been releasing every two years, on average every 25 months, even if you include the surge, which has been a pretty slow release. So what we are doing by increasing year after year the quality requirement for our release is that we still are able to release on average every two years. I think it's pretty good. It's not a six-month date cycle which others are doing, but in what we do, providing a rock-solid stable release, it's pretty good. So what can we do to improve this? So I think we should have a more dependable release process for us, not for people outside. We should be able to tell developers you have this time to make up all your changes that will break stuff, and then after this time we will consolidate and release. And this is something we are doing for this release cycle. So the release team has decided to go for the first, for this time on a time-based phase, and we know a freeze date, a freeze month, which will be June next year, with one year of advance. This is something we have not trumpeted much, but which is really important. Something we can use to negotiate with upstream to say, okay, I need a stable release of your software for June next year, actually a bit before that, if I want to be able to check the packaging and do all that. And it's something we can use to be sure that our development cycle will have a specific length. So this is very good. This is something new and very good for us. But also we need a more collaborative release process. Too often we just care about our own package and leave the release team do all the rest, right? They're the release team, they should prepare the release, right? Well, no, doing a release is a collaborative effort, and to do that we really need to learn that it's a shared responsibility of all of us to put out our release. So once your own packages are free of RC bugs, you need to realize that the other RC bugs are your responsibility as well. Do NMUs, accept NMUs, love NMUs, okay? And finally, another possibility to go forward here is to add a new quality time trade-off in what we offer. So right now we offer a stable, which is a very clear quality time trade-off. So it takes time to prepare, two years on average, it seems, and it's very solid, it's very stable. And we have been discussing on mailing list for quite a while, but I find very useful and interesting discussions, the possibility of adding new quality time trade-off, of adding something like testing, but which is meant to be used by final users. There are various versions of the proposal, cut, rolling, but this is something we should consider. We should take care that it does not get in the way of stable, of course, that it would be a very useful way to add a new product which offers the unique feature of Debian to a new user base. What about freedom? Can freedom be something which holds us back? Well, no, maybe yes, but that's something which cannot negotiate, okay? Of course, well, of course I got to ask a lot of talks very often, why my Intel-based wireless card does not work with Debian? Well, that's too bad, but it's something we do not negotiate. We offer a clear barrier where you explain people, if you pass this barrier, you will be on your own. You will be using non-free software that we don't know what it does to your hardware, you cannot support it, so you're on your own. And this is part of what we do, is what unites us together, so I don't think we should negotiate on that. How about independence and bureaucracy and the way you take decision? Can that be something which holds us back? Yes, it can, and I think it currently is, because we have some drawbacks when you do only bureaucracy. There are some tasks, some non-geek tasks, some non-cool tasks, which can be left unattended. So there are tasks which might be sort of boring for geeks, like writing documentation, doing mentoring, doing management tasks, doing marketing publicity, doing accounting, doing legal-ish stuff. All these stuff are not fun for geeks, okay? They're not fun at all. But if we leave them unattended, at some point, they might get in the way of doing hacking, of doing geek stuff, for instance. Having sprints is something that is very funny for geeks. You get together, you hack for a weekend, and you put out a lot of very cool stuff, very cool new stuff, but you need someone that organizes the sprints. If you don't do that, you have less occasion to meet, and you have less hacking, which gets done. Another example, trademarks, which have been debating quite a lot this year, okay? If you don't know what to do about trademark, if you need to have some kind of legal advice on what to do about trademarks, you are stuck in not knowing what to do with a specific license, with a specific trademark license. Or, I don't know, you don't know what are the risks of setting a specific package in the archive, and if you don't get an informed advice on that, you are stuck, okay? So there are plenty of examples in which you can be blocked in doing hacking by non-geek stuff, okay? For instance, not doing documentation. Who cares about documentation? True, but documentation helps other future geeks to join your project. It makes easier to actually join the Debian project. And there are plenty of examples like that. So what can we do to, oh, and by the way, like it or not, we are competing with other distribution, with other commercial distribution, which are very good at this stuff. They can just hire people doing that stuff, so they turns out they're pretty good at that. And like it or not, we are competing with these people, so unless we learn how to do this task as well, well, we will have a problem in this competition. So what can we do to improve on this? Well, first of all, we should stop saying that those stuff is useless. It's worth nothing. Just ignore all this. It is not. In some ways, it gets in our ways, so please acknowledge that it's actually useful. Second point is to welcome in our project people working on that. And this is something we have done. Last year with the GR on Maintainership for Non-Packager, we have done that. We have welcomed people in our project and about, I think, four or five people have applied for that, which is still too little, but it's something we now say. We now acknowledge the fact that those tasks are useful for Debian and we welcome you if you want to do them in Debian. And finally, we need to try and understand it socially. If we agree that this task is something we need, well, we need to find a way among us to do these tasks, to do them together, maybe taking turns, taking turns, but this is something that will help us prosper more than now. Democracy, can that be a blocker? Can that be something which gets in our way? Well, yes, if you look at folklore, I think there is also something on this to watch about Debian at this point, people believe that large changes are impossible on Debian because as soon as you propose a large change on Debian Devel, well, at least someone will disagree. So you cannot change anything in Debian because we are just too many people and it's kind of impossible to agree on everything. Well, consensus is not the same thing as unanimity. You can have consensus even if someone disagrees. Let's keep this in mind. And also we need to keep in mind that there is an order in democracy and democracy. Democracy comes first. So you can debate something on Debian Devel as long as you please, but if you're not doing the work, if you're not the person in charge of doing that work, it will just not happen. So too often I have the impression that people believe that just by discussing something on Debian Devel, they can impose their choices on other and they just cannot, okay? They just cannot. So if you want to change something in Debian, well, show me the code. That's the only way, okay? And this is a quote which I'm quite loved by Sam in Debian 7, be bold, okay? Take some big job on your shoulder if you really care about and start doing stuff. Start doing even the NMU that implement your change. Honestly, what can you undo? We have computers. A lot of mistakes we can do can be undone quite easily, okay? So what can you do to improve on this front? I think we need to work on forking enabling technology. We should make Debian easier to fork, not in the sense to create even more derivatives. That's good, but that's a different matter. But we should make it easier to test big changes in Debian. We should make it easier for developers to propose some dangerous change and let people play with it, okay? An example of such technology is what they're called PPA, Personal Package Archive. I have an infrastructure to enable developers to propose their own version of packages they do not necessarily maintain, okay? This is something which have been discussed, which is good, but guess what? Need some work to be done. The second example is what we've been discussing test-driven development. So enable people to have more testing packages. We need supporting policy for that. We need some bit of infrastructure. But if we have more testing Debian, people will be less scared of making changes. People will be more confident that their changes they've been making are not breaking stuff. So this is what I think we should work on to get better in this front. And the last one is derivatives. Can derivatives be a blocker? Can derivatives be something that gets in our way? Yes, they can be. If they lower our morale, if we think that nobody uses Debian anymore, they are all using derivative, if that gets on our morale, then yes, derivatives are a problem. But I think they are an opportunity, actually. So like five to 10 years ago, software was distributed with a very limited number of stakeholders. We used to have upstream software developer here, someone in the middle, like Debian, and users from the other side, okay? The software flow was from left to right, and the bug flow and batch flow was simply from the right to the left, your right to the left, okay? Now it's more complex. Now we have a whole pipeline of distribution which are upstream one for the other. We might have upstream developers here, and route distribution here like Debian, another derivative here, and so on and so forth. And in each single block of that diagram, you have users and you have potential contributors. This is very good for us, because every time we are at the block, okay, we reach out to new people that use Debian, even if it's indirect, they use Debian, new people that might be interested in working on Debian, okay? So what can we do to exploit this to our gain? Well, encourage collaboration with derivatives. This is something we have been doing a lot this year, with initiative like the derivatives fund desk, with decks, there are a few initiatives which has been going on, which is very good. Keep our communication channel open and explain to the people in the derivatives what Debian is about. Explain that we care more about the benefit of free software in general than the benefit of Debian itself, or than the benefit of a single upstream development project, okay? In my experience, a lot of contributors of other derivatives are really fascinated by these values, and it's quite easy to explain to them that if they contribute to Debian, they benefit also their own distribution, and they benefit free software in general. So this is a very appealing argument, and I think it's our role to try to spread this culture, try to spread the culture of giving back to your upstream, okay? So, to summarize, I think we have a greater role to play than just being yet another distribution among the unders distribution which exists. I think that if we fail, it's not only Debian that will suffer, not only our current user that will suffer, but free software in general will fail because it will lose a player which cares about free software deeply and which enjoys important independence from companies and from money. So our own ways of doing things might get in the way, and we need to watch out for that, we need to watch out that it doesn't happen, and a couple of rules which can help to avoid that is being bold, taking responsibility, and understanding that there are sometimes some tasks we need to work on for the benefit of Debian in general. So this is it. We have about 10 minutes for your thoughts, question or anything you would like to share with me. Thank you. Thank you, Stefano. I just want to make a very small suggestion, but one point in time through you had a slide that said, you know, the non-geeky tasks, they need more support by us, and I would like to suggest that we don't talk about them as non-geeky tasks and non-cool tasks because they can be quite geeky, being someone who puts a lot of, I forget the word now, but a lot of energy and love into what he's doing and does it more than the average person, and I can tell from my own experience that for instance writing documentation is very cool because you get a lot of people who write back what thank you notes, and that actually is sort of like rewarding, good feeling. So they are also cool tasks, and we should accept them as such. Okay, thanks. So I agree. So the presentation is suboptimal on that front, but we need to learn how to attract these people doing those stuff, explaining that it's cool stuff that is always very needed and rewarding. I basically want to say the same thing, just with another example. I think doing marketing stuff is a real cool thing, even so cool that it gets confused with having technical skills in that area. I'm doing marketing for K3BC port, and people start asking me strange C questions of which I have no knowledge, just because of my talks and interviews I give. So folks, what are you waiting for? Do marketing for the fact of how cool those tasks are and how badly we need them, in Debian. Any further questions? Ashish. No, he's leaving. Hi, so you said, okay, so do marketing. Well, I guess one reason that we don't is that it's a lot harder to know what is the right next task. With packages, it's extremely clear. If there's a new upstream release, I package it. If there's a bug, I fix it. There is a publicity team now, and there is a website team, but something isn't as smooth in getting us, I don't know, in helping me know what the next step is, I guess. Yeah, so actually, you're right. So essentially, you're saying that there's not enough documentation to explain what needs to be done on that font, and so you're right. I think part of the reason is that not many people in Debian face directly the need of working on non-packaging stuff, but with software and with packages, it happened to us that we each reach out and discover, okay, that's something which needs to be done there, and we just do that. So maybe we just need to think about them and just try to be imaginative, and how can I improve this specific process in Debian, for instance, and try to work on that. I just wanted to point out that the next talk is actually gonna be in this room by Tolomar. It's the publicity team and you. So if you're wondering how to get involved, stick around for that. Yes, and by the way, I think that publicity is a very nice example of the fact that we can actually be very successful in work on non-packaging stuff. The publicity team has been doing a wonderful job as long as I've been starting to look at it, so yeah, big kudos to the publicity team. Okay, slightly different tack. So how many people is this the first ad conf? Hands up. Wow. How many new Debian developers for the first time this year? How many new Debian maintainers? Okay, cool. Please tell me, promise me you're gonna get involved. Infrastructure, all of the cool non-packaging stuff. Awesome. Thanks, Steve. Hi. Could I just ask or make a comment, perhaps, about the social contract that you mentioned? All of the times I've seen the social contract discussed before, it was almost a personal philosophy of how we should live our lives. And in your last couple of slides there, I thought it was a very important point that you were talking about it as a means of making the economy work. And it struck me that we needed to get across to managers more, the understanding about that economy to explain that it's something like the rules of the stock exchange as a way of doing business. Could you sort of say some more about that, please? So yeah, well, I'm not sure I fully gawk the analogy with the stock exchange, but yeah, so you have a point. So essentially, I think that the point of, the second point of the social contract is we will give back to the free software community. And we were used to think, well, yeah, of course, we need to work with our upstream. And the fact that there have been derivatives which are so popular, actually way more popular than Debian itself, has made this equation more complex. But I think it implies that Debian should go to those people and explain you need to give back. And on one side, so if you want all this to work, essentially, if you want this pipeline to work, you need to have a very low viscosity in the pipeline. So any patch which is added in any point of the pipeline should go left, should go upstream, so that more people benefit from that patch. And I think that explaining this aspect is something Debian should do because Debian is the root of an incredible amount of derivatives. But to do that, we need also to be exemplar. So we cannot go and ask other derivatives to give back to us or to give back to upstream if we are failing to do that ourselves. So that's a very important moment in the way we do distribution, which we need to show that every single brick in that chain should actually do the right thing and push things upstream, including Debian. Can you write that down somewhere, please, so I can send the link to people? Because at the moment, if I send them the social contract, it kind of looks like a declaration of independence rather than a sort of statement of commonsense economy. Yeah. Lucas? Yeah, about the lack of manpower, you said that, okay, we won't get more manpower. It would be hard to get more manpower, but we should make the best use of the one we currently have. Could you give concrete examples of what we should do to get to that? So, okay, so essentially there is a trade-off in having the notion of package maintainer. So Bidale has spoken various times about the Easter of Debian, the fact in the beginning we didn't have a notion of maintainer and we now do. So the notion of maintainer is kind of weird because on one end it enables to have more social package maintenance because you can easily define areas which are the responsibility of one maintainer, but it also creates a barrier in contribution because if you see there is a fence, there is a maintainer fence, well, you're a bit scared of crossing the fence. So that actually trying to cross the fence more often is I think the best example of how we could do to put it to better use what we have. And that's why I think we should be way more liberal with NMUs, accepting them more. And I also would love to see having some very widespread version control system access rights. So having, there are packages in the archive where anyone can commit, any Debian developer can commit, and those are great examples. So in general try to see where there are barriers, where there are things which blocks people to contribute and tear them down. We will have some flames about that because there will be people who are very, you know, they have an important sense of ownership of the package. But that's the, I think the best way we have to scale. I have some thoughts regarding the licensing issues you were seeing regarding the, for example, the Intel wireless cards. The now Intel will strike back on me. It was just an example. Yeah, yeah, yeah, yeah, just an example. I think I have a different opinion that and I think it should be regarded not the same depending on if it's run on the machine in the same space or the same memory with other things and drivers with developers free software or it runs on the specific device. I think it should be regarded something like the basic input output system on your machine which is also closed source. I'm not saying this is a good thing but I think it should be regarded a bit differently. Okay, so. That's my take on it. Yeah, I know, I mean, you're surely not the only one thing in that. And you released another CD version which contains these drivers and I think this is very essential because it's a must. So I'm sure you do. I know you do but I think this is a must at least for me. So I mean, I'm sure there are a lot of people with the same opinion. Personally, I disagree but the other question is to what we should apply DFSG. I think Debian has essentially decided over the last three or these cycles to actually consider firmware as something that should go under DFSG. I agree that. We have been working a lot on that and I think that as a result of our work and in particular of the kernel teamwork we have actually also encouraged upstream to separate free firmware from non-free firmware and I think it's a very good outcome, a very good thing that Debian has contributed to free software in general. So. So you mentioned that Debian is still growing and my questions are what is your workload as DPL? Because you nowadays have to manage more and more people and I would like to know what is your workload and if you think if it is sustainable to have one person being the DPL? No, I honestly think it is not. So luckily the DPL role is not really doing a management in the project management sense. So luckily because otherwise we'll be like three work, three full time job at the same time. So this is something which helps but I do think it's not scalable. I do think that so no, I think it is not but I don't have yet a better solution to propose. So the DPL is sort of the public figure of Debian. It can do some sort of moral suasion in debates and this kind of stuff but that's potentially a problem, yes. But right now it's written in the constitution and so figure out a better governance model is something which is pretty difficult and pretty difficult to imagine upfront how it could work. So potential problem, yeah. I think time's up. So thanks for all your question and thanks for being here.