 First, an announcement. If you have questions, ask for a mic and wait for it. Look at the camera in the front and please don't cross the camera on the back in the front. So now Mark Shatterworth will be talking about Davian and Ubuntu. So please, your turn. Thank you very much. It's great to be here in Argentina. I'm speaking from the perspective of Ubuntu, but really what I wanted to talk about was Davian and Davian's relationship with derivatives. And Andreas Tiller has organised a great, what I hope will be a great panel session right after this, where we will hear from a bunch of different derivatives. So the perspective that I really wanted to bring to this talk was to articulate the case for strong and compelling relationships between Davian and its derivatives. A strong meme of collaboration with derivatives, a positive attitude towards derivatives and a good discussion around how both sides of that equation should be optimised and should work. We collaborate brilliantly when we agree perfectly. It's extraordinary how much gets done in the free software community when we bring people together and we allow them to sort of find a consensus and to figure out how things should move forward. There is an incredible willingness when the atmosphere is right and when the conditions are right for people to be enormously empowered and productive. Conversely, when we don't agree perfectly, we often descend into a very, very unproductive state. And this is an observation that I have across the whole of the free software community, not just within specific projects. But if we look at years and years of quite unproductive discussions between people on different sides of the BSD versus GPL debate, I wonder how much more productive we could have been if we had figured out how to work together very well while acknowledging that there are some things that we don't agree on or some things that we want to do differently. And so that's really the goal of my talk here, is to sort of figure out how we can be super productive, super empowered, super effective even when we don't necessarily agree on everything. So there's a real question about whether or not there's an imperative for Debian to scale, and I believe there is an imperative for Debian to scale. I believe that Debian articulates its vision best when it describes itself as the universal OS. And this question came up quite a lot, I thought, during the DPL's talk, and someone actually asked the question of, Steve, why do we need more developers? Well, to me, that's very, really quite clear. I think free software is going to grow, and if Debian wants to retain its position as the universal platform, as the universal OS, then it is going to need to figure out how to scale. And it's going to need to figure out how to be continuously productive and effective and efficient as it scales. And we've already seen significant challenges to that scalability, significant breakdowns in productivity and effectiveness. I think that derivatives offer a very compelling way for Debian to scale, to reach new markets, to reach new audiences, to experiment with new ideas. So to scale not just in terms of the numbers of people participating, but in terms of the number of challenges that it can tackle. The key, though, again, is effective collaboration. If you imagine a world with Debian and 50 derivatives, if there's poor collaboration between those different groups, then effectively you haven't scaled. If there's effective collaboration, then each derivative is bringing new capacity, adding new energy, new ideas. This is a saying that I think is really very true, that the difference between joy and misery is often in how you define success. I meet people who by almost any standard that one could apply should be extraordinarily happy, and yet they're miserable. And often I think it's because their definition of success in life almost precludes them from being happy. I think that's a very dangerous position to be in. You want to define success in such a way that it's a challenge, but that it's attainable, and that when you achieve success you really feel good about it. And in the free software world, often I think a lot of the deep conflict that we see comes from really differences in the way people define success. And possibly the best person in the free software community that I'm aware of, the person who understands this the best, is Linus himself. Linus defines success as the whole forward movement of Linux. And it's extraordinary how he's managed to always reshape a debate around that idea. When the community is busy splitting itself up and tearing itself apart and dividing itself, Linus finds a way to say, well, actually, you know, we're all running Linux. And as long as more people are running Linux, that's success. There's a particular issue that I think highlights this, and that is the relationship between kernel.org and the distro kernels, which is a very colorful relationship, right? It has many complex dimensions to it. Now, there are many people who believe that, in fact, the world would be a much better place if all of the distros ran stock kernels from kernel.org. And there certainly are compelling arguments for why one should always be converging on that trend, right? We all understand that it's at kernel.org. The real progress is measured at kernel.org. But I think Linus understands that there are also real benefits to the diversity that you get from different distros and from different kernel teams within the distros. And so he manages to sort of socialize and shepherd this idea of continuous progress forward, recognizing that bad ideas will get weeded out. And so we've seen this pendulum swing. We've seen distro kernels that are hugely massively patched where distros effectively try and not necessarily hoard, but certainly differentiate themselves on the basis of their intellectual input into their kernels. And we've seen that pendulum swing right back. And Linus, throughout it all, has sort of said, well, you know, every additional computer running Linux is running Linux. And that's success. And so I think on that basis he's a very happy person. And I think there's a real challenge here for Debian. And that is, you know, how do we define success? So I spoke earlier about the universal operating system. I really do believe that vision of the Debian system as being the universal operating system. I think the world would be a better place if we had more and more computers running on the Debian system. But I don't define that as etch, or lenny, or sarge. I think the Debian system reaches out to include the pool of all of its derivatives. And this is an enormous, I think an enormously important point, because if we define success as lenny versus hardy, or sarge versus a release from Zandross or one of the other derivatives, then we put ourselves in tension. Whereas if we define success as the whole Debian system, I think Madduck describes it as the Debian system, right? It's not so much a release or a platform. It's a system. It's a way of organizing code, components, and thinking. If we define success as the expansion of the Debian system, then I think we can potentially have a very happy and very constructive relationship between Debian and its derivatives. I'll come back to the idea of defining success, because another challenge for Debian I think is that each of us effectively has our own view of success. And within Debian, each of us really has an equal say. And the challenge then as an organization, the challenge for Steve, for example, is to figure out how do we articulate success in a way that meets all of those requirements without effectively making our own job impossible, without trying to be all things to all people. I know there's been a lot of discussion about this sort of one-hit wonder of social philosophy, the geek social fallacies, which is I think quite an insightful piece of writing. It talks about how basically good ideas can become very dangerous if they're taken to too much of an extreme. And often I think there's an issue between Debian and derivatives that kind of boils down to this social fallacy number two, this idea that sort of friends accept me as I am, and therefore if there's any criticism of what I do, then you can't be a friend. And that's actually profoundly untrue. But there's also sort of a conflation of two fallacies. The other sort of fallacy is that the existence of a derivative is in some way a criticism of Debian. And that's sort of profoundly untrue. I often run into people who genuinely believe that the mere existence of Ubuntu is a criticism of Debian. That the only reason to do Ubuntu is because there must be something wrong with Debian. Obviously I don't think that's the case. As far as I'm aware, none of the major leaders in Ubuntu or any of the other derivatives of Debian actually thinks that's the case. The existence of a derivative is usually an opportunity to experiment, an opportunity to explore new ideas. It's not inherently criticism of Debian. And so provided we bear all of this in mind, I think it is perfectly possible for us to remain friends and yet maintain separate identities or focus on different definitions of success. Another question that often comes up is this one. Why can't derivatives just do what they do inside Debian? And the answer is that much of what we do should be done within Debian. And so I'm very proud when I look at the lists and I see a lot of participation in the lists of Debian from people who I know are paid to work full-time on derivatives, whether that's the triple EPC, which is a derivative of Debian, whether that's Ubuntu, whether that's any of the other potentially hundreds of derivatives. When I look at the lists, I see a tremendous amount of participation from folks in Debian. But there are reasons why some things can't be done directly within Debian or can't be done immediately directly within Debian, even if they should flow there later. I asked some of the guys that I work with and they drew up a list. One of the differences is policy differences, right? A derivative will often say, look, we want to move to a new version of Python or we want to move to a new version of GCC and that precipitates changes throughout the system. And those transitions I think are actually a significant good, a significant benefit to Debian because often derivatives are in a position both to act quickly across the whole archive or big chunks of the archive and also to experiment, right, to figure out what's going to blow up and what's not going to blow up. So we've seen significant floods of patches and work and knowledge and insight come back to Debian from derivatives that were the first to make transitions, things like C++ ABI transitions, modular X, Python, the shift towards a different way of organizing Python packages. Often derivatives will pick different versions and they do that for various reasons and I think we should respect the reasons that they do that. In the case of Ubuntu, sometimes we want to work on a newer version, a version that hasn't yet been packaged in Debian and so we inject that energy effectively, we drive that packaging and I believe that that does benefit Debian over time. Bug fixes. So there are many sort of practical reasons, technical reasons, why a derivative might actually want to change the packages rather than, separately, rather than expand the packages within Debian. Another reason is branding. Oh, sorry, let me make this point. Sort of a general meme that I see within the open source community is that the projects that are successful are the ones that optimize for participation and optimize for experimentation. So for example, I push very strongly in favor of distributed version control systems. Whatever your choice of distributed version control system doesn't matter. I like Bazaar and we use Bazaar but you should use whatever works for you. The key thing with distributed version control systems is that they unlock participation. They make it possible for someone to participate in a project even if they're not yet a core developer. They also unlock experimentation because they allow people to, instead of disagreeing about what goes into trunk before the work starts, they allow people to experiment and get work done on a branch, build community support for that idea and then land something which is functional. So in a very real sense, derivatives for Debian are the same sort of thing. They're like a distributed version control system, right? They're like the opportunity to go off and branch and then come back and merge later. The key thing is, can we merge? Are we committed to merging later? There's another meme about marketing and branding. It's very hard to build a single entity which can carry multiple different brands. And this comes back to this idea of the definition of success. It's extremely difficult to think about how we could build a single entity which could be branded as an embedded solution, could be branded as a GNOME desktop solution, could be branded as a KDE or XFC desktop solution, could be branded as a server solution, could be branded as a virtualization solution. It's extremely difficult to imagine how we could build one organization which can, in people's heads, convince them that it can deliver across all of those things. And some people don't believe this. Some people think that one organization can do that. I disagree. I think true branding, really. Branding is when the heart shines through. Some people think that branding is quite disrespectfully. They think of branding as an exercise in lying. You'll often hear technologists talking about, oh, the marketing department. And there's a dismissiveness there because there's a sense that the marketing department tries to convey, tries to hide the deficiencies and promote the features. And the reality is good branding is really about letting your heart shine through. It's really about saying these are the things we really, really care about. And an organization that has great branding, by my estimation, is an organization where, for everybody that they really care about, the difference between what that person thinks this organization about and what the people inside think the organization is really about is very small. You have to minimize the difference in expectation, effectively, between the people that you really care about, the people who you're going to interact with, that's great branding. Now, derivatives offer Debian the opportunity, effectively, to have great brands, powerful brands, within the Debian space. There's a meme, for example, that Debian has terrible branding and that all that needs to be done is that Debian needs better marketing or better branding. I think that Debian has incredible branding. What are the key values for Debian? Technical excellence. Technical excellence above all else. Independence. Freedom. Now, if you talk to any Linux expert and you ask them what's Debian all about, they will almost certainly quote you one or more of those three things. That is a triumph of branding. This is an organization which has managed thoroughly to penetrate the hearts and minds of its target audience. The challenge now comes if you try and position that organization, it's not only about those things but also about an amazing this or an amazing that or an amazing the next thing, then suddenly the picture gets very cloudy. Again, this comes back to a definition of success. If we focus within Debian on the key values of universality, technical excellence, freedom, componentization, the ability to have literally any piece of free software that you want at your fingertips, if we focus on those things then we will be successful. If we start to fragment in our definition of success, if we start to try and fragment the brand, then I think we run a real risk. So, to me, collaboration with derivatives is the best way for Debian to scale. It's the best way for the Debian system effectively to truly become universal operating system. It's the best way to make sure that everybody's individual investment of their time and energy and thought in either Debian directly or in any of the derivatives that the value of that is maximized because they are defined as being part of a broader ecosystem. So, what are the challenges to that collaboration, right? The most significant one, I think, is actually one of scale. There's a great article in Wired that says more is not just more, more is different. And this is really true that things that work at one kind of scale don't work at another kind of scale and in particular, patterns of communication that work within certain dynamics don't necessarily work within others. So, if you look at the ecosystem within which we work, there are probably 10,000 upstreams out there. I'm not counting everything on SourceForge, I'm counting the things that might be packaged, the things that might get sort of reasonable amount of use. We have a thousand some, maybe it's actually quite a bit higher, but it's roughly an order of magnitude fewer DDS. And then your average derivative has probably 10 people working on it. That's not so much true of Ubuntu, actually. We probably have 200 people who participate fairly, actively within Ubuntu directly. But your average derivative is much smaller. And that means that patterns of communication that work within Debian, that work between Debian and upstream, are really going to struggle to work with derivers. And that's, I think, a really important thing for Debian to understand. That often we expect other people to behave the way we behave. And we don't take time to put our heads inside their, you know, not our heads inside their shoes, but to walk in their shoes and understand what it is that, you know, what it is that will actually work for them. When I talk to other derivatives, and we'll hear from the panel later, I think often the scale is a real issue. You have to figure out how to work effectively with a thousand different people. That's a real challenge. So our solution to that has been sort of two-fold. We socialize the idea of collaboration very strongly. And we try and provide tools which make that collaboration easy. And the reason I focus on tools is because I think this is human nature, right? Mostly in human nature we take the easy way. The interesting things about a person are the places in their life where they choose not to take the easy way. But for most things we take the easy way, right? Because you cannot be, you know, profoundly different and do the difficult thing in every single thing in your life. So for most things we take the easy way, the obvious way, the thing that makes sort of immediate sense without too much analysis based on our understanding of the world. And then afterwards we figure out how to rationalize that, how to justify that, right? And I see a lot of arguments where people, you know, are really arguing, they're arguing furiously about how they're justifying something that they did. But the reality is they just did it. You know what I mean? So the thing is we have to make the tools and the processes such that the easy way, the natural way, the right way to do things, not you know, is in fact the collaborative way. And so that's why sort of from our side we've focused a lot on trying to figure out how to make it so that our tools, our processes, in the course of doing what you do in Ubuntu make it relatively easy to collaborate with 10,000 upstreams and a thousand different DDs. To me it boils down to this this idea, this is, you know, I talk about tools but ultimately this is a social issue, right? We need to socialize the idea of collaboration. And I can probably phrase it best this way, collaboration is good and disrespect is bad. I, you know, I respect any organizations right to arrange its affairs the way it wants to. And that goes from, you know, Iran to Zimbabwe to America to Debian to Gen2 and so on. But I think it is also worth saying, you know, separately from that respect, saying that it really works well. What is effective, what is not effective? And then let's make sure that the organizations that we participate in, we try and constantly make them more and more effective. And this is a meme that I find very, very effective in open source, right? Socialize the idea of collaboration and discourage the idea of, like, profound disrespect. So I am generally very disappointed when I'm inside a free software community, whether it's, you know, FreeBSD or Debian or Ubuntu or any other. And I see people effectively destroying their social capital, effectively destroying their ability to work together, right? When you disagree with someone, it may well be because you don't yet understand where they come from. 90% of the time our disagreements are because we don't really understand the background or the experience or the context from which the other person is coming. And so harsh disrespect which makes it very difficult to get into that understanding is a really bad is a really bad idea. So one of the things I would really like to see with Debian is the socialization of the idea of collaboration as a good and disrespect as a bad. And that's a difficult thing. You come back to, you know, I think there have been long sensitive discussions with Debian about this. How do you move, how do you encourage some kinds of behavior and discourage other kinds of behavior without getting into censorship? But I think it's important. I think leadership is important. And I would like to see leaders within Debian sort of arguing in favor of these things. What I see often is that is that folks who talk about collaboration are criticized and nobody stands up to say, actually, this is a good conversation. We should be having this conversation. There's nothing wrong with this. So in practice, what can this mean for Debian? Well, we started just sort of a year ago, we started within Ubuntu, within Ubuntu, socializing the idea that people should tag the work that they do inside the BTS with user tags so that we could at least get a sense of where we are effectively collaborating and where we aren't effectively collaborating. And so this is really interesting. If you look down you see all sorts of patterns, for example, in some packages just between Ubuntu and Debian, there's really good collaboration in other areas that there isn't. At a sort of macro level, just looking at patches, there are more than 500 patches in the active part of the BTS, not archived. And interestingly to me, more than 300 of them have been accepted. So that suggests that there's actually a valuable stream of input coming from one derivative into Debian. And this is just, I think, the tip of the iceberg. If you look at conversations in the BTS and you start to look at the level of participation from people and I only know Ubuntu, but I assume that it's similar from the other big Debian derivatives, right? This is a very, you know, thousands and thousands of bugs within the Debian BTS have active participation from folks from Ubuntu. So if you just want to measure the raw materials of benefits, it's perhaps not as easy to dismiss the benefits to Debian as some people have made it out to be. There's been some fantastic work done in the last couple of months. Lukas, where's Lukas here? Lukas Nisbaum has done some really good work trying to connect, again, at a technical level, the processes. So trying to make sure that information about what's happening in Ubuntu, that's relevant and appropriate, is easily available to DDs in the package tracking system, for example. Just knowing that there are bugs on your package over there might or might not be useful. I'm not suggesting that anybody should change their, you know, should not do what comes naturally or do the easy thing. But I am saying that we should make it possible for the easy thing, effectively, to be an effective and constructive thing. And I think that work that Lukas has done is fantastic in that regard. On our side, we try to make it easier and easier, much like Don Armstrong's work on making it easy to query the BTS. We've published APIs and so on, so that you can query our bug tracker as well. And I hope that that will mean that we see an acceleration of the sorts of work in sort of sharing information and accelerating information. My ideal dream is that, you know, if a bug gets filed on Ubuntu, which happens to be a bug in, say, Nautilus, that within sort of 24 hours we're having an active conversation between an upstream developer and Nautilus, a DD and an Ubuntu developer, and each of them is just using the tools that they use. To them, it feels like a natural easy conversation, right? The Nautilus guy shouldn't have to worry about coming to the Ubuntu bug tracker, shouldn't have to worry about coming to the Debian bug tracker. And vice versa, right? Everybody should be able to use their tools and just have a natural flow of conversation. That's the sort of goal that we want to get to. Again, just speaking from the perspective of Ubuntu, and it'll be interesting to hear from the other derivatives, I asked, like where within the distro do we have good collaboration? And the things that came out are things like X, DI, Perlin, Python, GCC, Pam, Binder, Bind, Inkscape. Where we have developers in common, it's very easy. Like a couple of memes about where it's easy to collaborate and where it isn't. Where we have developers in common, it's very effective. There are still conflicts. Doko told a funny story about hearing all about some of those challenges with this guy called Doko, from guys who didn't realize that he was Doko. I think that's good. That's why we should have more developers come here. Because often those things can be solved just by getting people together. So the easiest cases are typically where we have developers in common. That hasn't been that easy because of the difference in the way Deleon is organized around packages and Ubuntu's organized around chunks. Which is an interesting thing. I don't think we could have the liberty of organizing around chunks of the platform if Deleon didn't have the rigor in each of the components that it does. We couldn't do that because then you wouldn't have solid and high quality components to be working with. So it's a very interesting counterbalance. But one consequence of that has been that it's been quite difficult as a DD to take an active interest just in your packages in Ubuntu. Because the social meme was that if you wanted to be an Ubuntu developer you needed to care about the whole system experience. And many very good DDs just aren't that interested. So there was a bit of a social hill to climb. So we started opening up to the idea of having explicit participation in particular pieces of the distro. And we've created the mechanism so that people can in fact have common teams and upload to both Deleon and Ubuntu. And that's, I think, there seems to be quite a lot of interest in that. Again, I'm not suggesting that anybody necessarily ought to do that. But if you want to, then we should make it possible for that to happen. I'm also seeing another meme which is that it turns out to be much easier for us to collaborate with Debian where there are teams in place. So I'm very strongly supportive of the shift towards team-maintainership. Particularly teams that cover a couple of packages. We just find that it's much easier to collaborate there. I think because it's a less personal thing, we're not arguing about your package in Debian. This is already a team and we're sort of joining them and there's a slightly there's already a sense of a shared ownership effectively in that piece of property if you think of it that way. Case Cook tells me that we have relatively good collaboration on security front, not just through the CVE level but also on specific issues. We had what I hope will be the worst security issue I ever see in both Debian and Ubuntu and I think the teams responded and reacted very well to that and I hope that there's appreciation from both sides as to how that worked out. I think it's worth countering a couple of myths. One is that a derivative is necessarily a fork. Some derivatives will be forks right? They'll say, wow, look at this great code. Let's take it and go off in that completely different direction and you know what? Good luck to them. It's free software and they will discover things on that road which are going to be interesting and interesting to them and it costs us nothing if they do that. And we have people do this with Ubuntu and I've seen people do this with Debian, you know, it's human nature. Some derivatives though are not implicitly forks. In the case of Ubuntu, we have merged with Debian nine times. There's no real suggestion that we wouldn't do that another nine times. You know what I mean? It's quite a lot of work actually, but we do it every time because we think it's of mutual benefit. It makes it much easier for us to collaborate and it's sensible. It's the right thing to do. And I think you'll find that there are some derivatives that stay effectively that maintain a delta. If you look at the stats the number of diverged packages has stayed relatively constant over the last couple of releases of Ubuntu. It will scale, the number of diverged packages will scale as the Ubuntu developer community scales but essentially there are two forces at work there. One is a merged force and the other is a diverged force and they're both constructed. They're both healthy. There's another idea I think there's a lot of fear when SSDS came along that Ubuntu would somehow supplant Debian and make it go away and that was never the intention and I think four years later with both organizations stronger than ever it's very clear that that's not the case, that both Ubuntu and Debian can be strong and that there's nothing to fear effectively in the existence of a derivative like Ubuntu. I was delighted when someone asked Steve if Zandros or if Ubuntu was a good thing and Steve said no, it's a good thing. It broadens the base of talent. We have some resources here. These resources look both directions. They're resources for Ubuntu developers who want to understand Debian. There are lots of people who come to free software through Ubuntu and I'm very, very proud of that. It's a very, I think it's a significant contribution that we make. Some of them go on to become developers in Ubuntu some of those go on to become DDS. I don't have a count but I'm guessing it's a reasonably significant number of DDS who have just come through the NM process or in the NM process who will have gone through that process. Think of a couple that I know who are DDS who explicitly came to Debian because of Ubuntu. There are also resources there for Debian developers. If you want to understand more about Ubuntu, how we work, how we organize, where we're different, where our processes are different, how our release cycle works and what that release cycle is, then that's the place to go. That's where we organize everything. So, where could we collaborate more in future? Well, I'd like to see more concrete discussion about the future technical direction of the platform. We need to evolve, we need to marry together incremental component based evolution. This idea that something like policy kit comes along, well it gets introduced as a component. But then there's also a systemic view. How do we bring these components together? There are many things which are truly systemic and on those things I think it's very, very valuable for us to have a proactive conversation. I'd like to see the Debian technical review board or technical architecture group be more active and if we can help inject resources into that, if we can help provide ideas, if the derivatives can provide experimental evidence upon which to direct some of that thinking, then that's a valuable resource. I think Debian works incredibly well with relatively little planning. I think that's a good thing. But I also think that there are some big questions which are systemic where it helps to be able to provide guidance and direction and to commit people to a particular direction. Particularly, I think that's true on things like packaging. I was very excited by some of the work that Martin Kraft is talking about. How you can figure out to be effective and to collaborate at the packaging level across multiple distros and with upstream. That's the key thing. We have to try and include upstream in this. For upstream right now our world is a little bit of a mystery. They deeply respect it. But it's a little bit of a mystery compared to the RPM world which is fairly well understood and often easier to interact with from an upstream perspective. We have to figure out how to get upstreams to really understand the benefits of our way of organizing, our way of packaging. Along with packaging goes processes. Again, I think Madduck was talking a lot about processes. How we organize the flow of work. We've done a lot of work in this regard. So we're learning a lot of things. By the end of this year you'll literally be able to branch any package in the distro. So we're trying to build workflows that will scale using distributed version control system. So systemic things like packaging, system initialization is another one. I think we need to figure out how to make Debian both the universal OS that it is, but also the fastest booting OS. And those two ideas are intention. But unless we sit down and really say how can we make it possible to achieve both of those things, we won't actually make any progress. This is one of the areas where I think Debian runs the risk of going in the worst possible direction. Where it says we must support every possible way to do this. In a sense that's good because it means it allows one to discover the best one. But if you never actually then converge on that best one and drive it you simply make everybody's life more difficult and everybody's life slower. So system initialization is another area. Which is sort of across the whole system. Configuration management, I think we do great with Debian but I don't think that's the end of the story. And again what we want is we want these key characteristics of the Debian system which are true whether you're on Ubuntu, whether you're on Zandros, whether you're on Lenny. We want those key characteristics of the system to be powerful and good and better than anybody else's platform. How much time do I have left? Ten. Does that include question time? Okay, then I'll try and wrap up quickly. So that's everything that I wanted to say about formal collaboration. There are two quick memes that I'm pushing and that I wanted to bring to this conference because I'd love to talk to people about them. So if you don't mind I'll take the opportunity to speak about them briefly. One is synchronization across the free software space. And I want to sort of be clear about what I'm not talking about. I'm not talking about limiting people's options. You know, I think projects should set the schedules that absolutely work for them and if those don't have cadence to them that's absolutely fine. But I think in many cases we simply haven't had these conversations. We simply haven't talked about whether there are benefits to having a cadence for a project, whether that's a three-month cadence or a four-month cadence or a six-month cadence or a one-year cadence. The evidence that I see from the kernel from GNOME, from Ubuntu is that there are from internal projects like Launchpad. There are enormous benefits to having a regular cadence. It's cathartic and energizing effectively. There are also challenges. The KDE guys have a very valid point when they ask the question of GNOME, how do we organize a dramatic transition? If you're limited to six-month cycles, how do you do something which is just going to take longer than six months? And it's a really hard problem. And I think the answer is not to say, you know, you're wrong, no, you're wrong, no, you're wrong. The answer is to say, wow, we've learned a whole bunch of things and we've learned a whole bunch of things. How do we bring those together? I think collaboration is much easier. I think developers want to collaborate. Oh, it's fun, right? I think it's much easier when we're collaborating across when we're trying to achieve similar goals in our cycle. You know, if one group is trying to sort of freeze and stabilize and another group is trying to break everything, that's just a recipe for bad conversations, right? When you're trying to achieve similar things in your cycles and when you're working across common versions, I think it's just that much easier to collaborate, that we would see that collaboration go, you know, from 1x to 10x in a short period of time just by changing that. So I'm actively trying to figure out how we can have a conversation between within upstreams is to say, what's the appropriate cadence for them? Because I think if they get onto a cadence and it makes it easy for us to say, well, if we want to be shipping in April, we want to freeze in February and therefore we're likely to be freezing on that version of the kernel and that version of GNOME and that version of X and that version of the cadence is for distros, it gets a lot easier to say, well, let's have a conversation about when we'd like to freeze and what the upstream world would look like. We can reasonably have these conversations now with quite a few major projects and I'd like to expand that to more. But it also allows us to have a conversation across distros where we say, look, if we're going to be freezing at roughly the same time, or if we can agree to freeze at roughly the same time, it doesn't mean we release at the same day, it doesn't mean we make the same decisions and it doesn't necessarily even mean we pick the same components, but it means that at least when we don't do that it's because we have our reasons to and that's perfectly reasonable, right? But if we don't have a reason to be different, if we can arrange to be, you know, aligned, then we will make it so much easier to collaborate. I'm guessing you all know implicitly that it would be much easier to do this with Ubuntu if we happen to be, you know, on something common. And if we can't arrange to be that, I respect that, that's fine, but Ubuntu, I respect the Fedevian, if there are reasons to be different, great. But where we can, let's do it. Let's get Novell involved, let's get Red Hat involved, let's get Gentoo involved, and figure out if we can't start to coordinate this. My sense is if we can do this we will dramatically accelerate the process of the adoption of free software by the rest of the world, people who don't think of themselves as technologists, because they will see this wall of dialogue about, you know, a substantial movement in the free software space and they will have, you know, publicity and communications and discussions, it will catalyze their thinking because they will see, wow, Red Hat, I've heard of that company, Novell, I've heard of that company, Debian, I've heard of this platform, and they're all doing amazing things, and they've got different takes on that, but there's this pulse that will really transform that pathway. We go from being on the face of it disorganized to being on the face of it more professional than the proprietary software world has ever managed to be. So that's the one idea. The other idea is a focus on user experience. BDAL mentioned this. At Canonical we choose very carefully the areas where we can make a difference, and I think this is one of the areas where we're going to try and make a difference. I very much want us to help shift the free software user experience dial from its current set of strengths which are on technical quality, scalability, robustness, efficiency, security and so on and add to that user experience. And this presents some really interesting challenges for us which I'd love to discuss with folks here. The profound challenge is this, how does one help to move that along without creating tension with the upstreams themselves? You've all experienced tension with an upstream I'm guessing, right? You have a patch, you genuinely think that patch makes the system better, right? And now you have to figure out how to engage with upstreams. So we will, within Canonical we will be separating those teams. We're hiring Gnome, KDE or GTK, QT, X, GL type developers and Kernel device driver writers but they're not in the distro team. We're separating those. So there still is this independence and I very much wanted to figure out how we do this without creating the sense, I think the danger in that relationship is that it's an asymmetric relationship. Upstream has the moral high ground, right? But distros ship the code and unfortunately that asymmetry has caused all sorts of poison. These upstreams resent the fact that a distro maintainer can ship with no reference to them something that they dislike intensely. That's why we have all this poison about I don't want to look at your bugs, you patch the package, it's not my bugs, which is toxic and conversely we have poison with distro guys saying look I don't care what you think, I'm going to ship it. I'm the maintainer. And we have to figure out how to have a better conversation there. So any thoughts that you guys have on that I'd be delighted to hear. Thank you very much for the opportunity to speak here. This is a community which means a lot to me which I respect, so thank you. I'm happy to take questions. Andreas? Thanks Mark for your nice ideas. I think it's how you talk it explains something why Ubuntu is that successful. But I have one question about your model that Ubuntu is kind of an experiment. If you do an experiment you have a theory with the outcome you do the experiment, have a result conclusion. So if this is an experiment from Debian what would you suggest to Debian from the result of this experiment? Okay, so in a sense Ubuntu is a series of experiments, each release we have the opportunity to experiment. And I don't think there is one experiment in Ubuntu I would never describe Ubuntu as a whole as an experiment because I feel it has much stronger footing than that. But in each decision which we take which is either different or in advance of the decision being taken of Debian that's an experiment and it's either going to work or it's not going to work. We started experimenting with the modular X and that could have not worked but I think it worked and it was subsequently embraced by Debian. Now, sometimes those conversations are constructive conversations sometimes they're not constructive conversations but where I think if we think about them as experiments, in other words if you give permission for a derivative you go and do something different and say hey, we need a framework by which you come back and say, what worked? What didn't work? So I would like to have more Ubuntu developers come to Debian because it gives us an opportunity to talk about both the experiments we have done and the experiments we want to do. So pulse audio was an experiment. Is it going to work? Is it going to work? Will it what's that? Pulse audio is an audio middleware layer effectively. There have been many of these and pulse audio was yet another one and it was quite a controversial decision within Ubuntu to move pulse audio especially since we did it in an LTS release. It's worked out and as a result the code base has got much better testing it should be much more robust and much higher quality when it ships in a Debian release. So that's what I really mean by experimentation. Same with distributed version control. Every branch is an experiment. It's not work. In the past we used to have to argue about where the experiment is worthwhile because as soon as the experiment started it was going to be tainting trunk. But now we don't have to have that argument. Allow, going to give permission for the experiment to happen. Yeah. A question from Baz Soutikow on IRC. Apart from changing release schedules etc. Are there any concrete technical changes you'd like for Debian to make? So, yes. But it's perhaps inappropriate for me to sort of push for a particular technical change. What I'd rather do is have conversations between developers. So I'm reluctant to sort of push for a particular idea because I have, jeez I'm a man with a lot of opinions many of them wrong. So asking me for opinions is dangerous ground. I'd love to see stuff specifically around packaging and around system initialization. I think those are two areas where we have done very well in the past and we can do even better. I'd like to see really strong thinking done there. Just echoing something what I've already been saying this week and I see Mark's picked up on as well. Something I'd love to see more is more of the Debian drivers actually getting involved directly in our packaging teams. It would be absolutely wonderful if we can actually have... The drivers have developers let's steal them. Let's steal their time let them directly contribute to the work that we've got fundamentally the smaller the changes they have to make the more efficient it's going to be for those guys as well. And if we can get upstream involved let's try and break down some of these barriers let's make it work better. I would like to report from the package games team and respond directly to what Sledge said we actually managed to get some people from Ubuntu involved in the games team and it's really working out well and as much as I was myself opposed in earlier days of Ubuntu about getting things back it's really much improved and if you approach the Ubuntu people more friendly and don't really object to them it's working out extremely well I've noticed this myself in the last days I'm delighted thank you for saying so and I hope it continues and time's up alright thank you very much everybody bye