 Okay, now I'd like to introduce to Mark Schuttleworth. Yeah, everybody knows about Ubuntu and everything, so I think there's a good chance to discuss a lot of things now. Mark, it's yours. Thank you very much. Thank you guys. It's great to be here again. Brazil last year was fantastic. I think this year has been even better. And I'm looking forward to many, many more deb-confs. I thought what I'd speak about briefly this morning is a little bit of my own background and story because I hope that that will put Ubuntu into context for you guys. I'll talk a little bit about my dream for Ubuntu, what I am doing it for, why I'm doing it. And then I'll talk a little bit about the team that we've brought together, how we go about creating the team, the processes that we follow, the community structure, the way we work, how, at a code level, we kind of weave in and out of the Debian world and why I think that's a really healthy and good thing. Potentially the relationships that we have with other people who live in the Debian universe. Then I know that there are guys with tons of questions, so the most important thing maybe that we can do in this session is to answer as many of those questions as possible. If you guys are on HashDebconf and fire questions away as well, then will someone make a note of those questions? Okay, Mako will grab questions like that so that we can kind of rapid fire work through any questions that you want to submit by IRC in person or anonymously, and then obviously if you have anything, any question about anything that I'm saying, please just stick your hand up. Mark, can I just briefly interrupt you? If you want to ask a question, please raise your hand and get the microphone up to you. Okay. Right, so my free software story starts back in 1994-1995, the early days of the web at the University of Cape Town, and I discovered Slack Relinux and then very quickly moved on to Debian and also discovered Python. And those two have really been, Debian and Python have really been the free software platform that has empowered everything that I've done. We used that combination at my foundation, we used it at thought, we've used it everywhere. In those early days, most of the hacking that I did was in C and Python, mostly the C stuff that I was doing was maintaining Python interfaces to various modules. It was maintained at the MSQL, which is kind of before my SQL came along, SQL database, and other Python modules. I got really drawn into the crypto world. Crypto was going through a fascinating time and this was treating crypto as tanks and RPG guns. In those days, if you were a German bank and you wanted to set up a secure web server, you had to fill out the same set of forms to the American Bureau of Export Administration as if you wanted to buy a tank and ship it over to Germany. So there were all sorts of opportunities for crazy young South African kids in the free software world. I did quite a bit of hacking on OpenSSL, which was then called SSL-E-A-Y, and got drawn effectively into that crypto game. The whole .com thing, when the musical chairs game stopped, I was very, very lucky and found myself suddenly out of a job with the potential to do almost anything, which is quite a daunting thing because you really defined yourself according to one thing. It's crypto and Python, and then suddenly that's gone and you have to figure out what else you want to do. So I asked myself, what is the one thing that I want to do before I die? And the answer came back, flying space. For like a day or two, I really wished it hadn't because I suddenly thought, shit, if I don't go and try, I'm going to feel like a coward for the rest of my life because it was kind of scary to go. So I went to Russia and spent a year and a bit working on that project. Along the way, after thought, I set up something called the Shuttleworth Foundation in South Africa, and that focuses on innovation and education. So trying to find ways to transform the education system so that we can actually realistically hope to deliver education in a developing country to millions and millions of kids on very, very low resources. As part of that foundation, we fund tons of open source work. There's a project called Tux Labs where we funded, I think it's up to 200 schools now with complete open source, K-12 LTSP, based computer laboratories. The Freedom Toaster. I don't know if any of you guys have heard of the Freedom Toaster. That's a project of the Shuttleworth Foundation. We pulled off the biggest LPI certification day in history in South Africa when I think about 160 guys came in and wrote the LPI exams. One guy who's totally self-trained from the townships wrote all the LPI exams in one day. Just, I think, to prove you could. Learning Linux, those free content licensed complete set of Linux training materials. That's all the work of the foundation. And we also worked with the ICDL guys. We were the first guys to convince them to make under a free license available the training materials for the ICDL. The stuff that we have done that's quite fun as well. There was a case in South Africa, a court case against some students who were making T-shirts with funny rip-offs of corporate trademarks. They'd been sued by the South African breweries, which is sort of the most important company in South Africa. They'd lost all the way up to the constitutional court, and they'd run out of money. We went in and funded them, and they won. They got a unanimous constitutional verdict that humor is more important than trademarks. Some of the stuff that I'm really interested in that we're doing now over there is, again, all got to do with applying the principles of open source to education. So, collaborative content creation, getting teachers using MediaWiki to create textbooks effectively for one another. We're also finding stuff that's more related to Ubuntu itself. For example, in the translation space, those of you who've heard of translate.org and Pootle, a web-based translation thing, which is open source, I was the initial funder for all of that work, which is not Rosetta, the project that we are working on inside Ubuntu. A school tool and school bell. A school tool is kind of school administration. I think it's very important that we have an absolutely free GPL platform, like an SAP for schools, so that they can run themselves. And the reason I think that's important is when you go into developing worlds, the amount of money you give a school that matters, it's how well-organized they are that matters. So, that work's being done. And as part of that, we've produced school bell, which I think is the first complete open source from the ground up calendar server. Brian would be able to tell us more as the release manager of that. I also run a global bounty program, which started around with Mozilla and trying to accelerate the development of Mozilla and now also covers GNOME and a couple of other areas. And in partnership with the South African government and HP, funds something called Go Open Source, which was basically a marketing campaign for the concept of open source, which was the first time that had been done in the world. And we produced a TV show, which I think is available under an open content license. It's being distributed in Africa freely. And it was very cool. We got interviews on that from sort of all of the big guns, talking to people in South Africa about open source. So, that's kind of the background of the work that I have been doing in open source. About two years ago, I became very frustrated with the state of the distribution market. You know, since 1995, I've kind of had an idea of what I think is important, what open source can deliver for everyday users. And I've been waiting for somebody to do it. I've been waiting for Red Hat to do it. I've been waiting for Novell or Sousa or someone to step up and actually deliver for the world what open source can deliver. And it was getting increasingly frustrating to see that nobody was actually doing that. If you did the analysis of replacing every computer in South African breweries, taking all the windows out and replacing it with Red Hat, socially and financially, it wouldn't look really that different. And that just seems to me, you know, a travesty of justice. You know, open source and free software are capable of delivering far more. And so, I figured, you know, what the hell? Why not climb in and see if we can build that model and see if we can make it work? There were a couple of other things going on at the time that I thought would make it a really interesting time to start doing that. And the first of those is something called distributed revision control. Distributed revision control is suddenly coming to the forefront now, but it's something we've been working on for the last year and a half. Many of you both will have heard of BitKeeper. BitKeeper is a commercial distributed revision control system that the kernel guys used for about two and a half years until the whole situation imploded as all of us free software nuts predicted it would. But what BitKeeper did for the kernel was dramatically accelerate the ability of ordinary people and other people to participate in kernel development because suddenly you didn't have as much of a bottleneck at the center effectively. You could create branches and you could collaborate, you could create ad hoc groups to collaborate around features and then sort of land those features into A.J. Morton or MMS, Andrew Morton's branches and move those over to other people's branches and ultimately bring them into Linux's tree. Distributed revision control effectively lets us keep track of different patches all over the world, whether they're in or whether they're out of any given particular tree. And it seemed to me that this was going to be one of the key platforms for again accelerating open source development. So I started funding something called Baz. We started with sort of two opposite ends of the spectrum. We started with TLA on the one end, which was distributed but had all sorts of dash, dash, dash, dash usability issues. And we started with the kind of from scratch clean reference implementation that's being done by Martin Poole. Some of you may know him as a contributor to Sambar and Kernel and others, he works with Tridge and other folks like that. So Martin's doing a kind of from scratch Baz.ng in Python and the Baz team are working from TLA to try and converge on what I hope will be a phenomenal revision control tool. Both of those are under the GPL and absolutely freely available. And I really hope that those are going to replace BitKeeper and bring the social power effectively distributed revision control not just to the Kernel but to the whole... So I really hope that Baz is going to bring to the whole of the upstream world what BitKeeper did for the Kernel. Why I think that's really important for what we're doing is that it speaks to the heart of branching and forking. One of the really difficult things in a CVS style world is to have different groups working on different features. In a distributed revision control world, that's exactly how you work. You get teams of people to work and collaborate on a feature on a branch and then merge that in. And you can have multiple branches with people cherry picking effectively. I want to have that feature, that feature and that feature and everything else that's in mainline. And so you can stabilize, you can test new ideas, stabilize those ideas and then move them into the mainline effectively. It seems to me that there's a huge amount of work that happens in the open source world that falls on the floor, right? Every distro, Debian, Red Hat, Sousa, Gentoo, every distro does valuable work, the maintainers do valuable work and that work never makes it upstream. And that's a tremendous friction in the open source world. And one of the ways I hope we can eliminate that friction is through the use of distributed revision control because every patch will be connected to its upstream, which means that you can move code from Gentoo into Red Hat into Ubuntu into upstream and always know which patch is where. So as I started to study this, it was kind of the emergence of distributed revision control at that time that I thought would really underpin everything that we're doing. So what are Ubuntu and Ejibuntu and Kubuntu all about? Fundamentally, they're an attempt to deliver to the desktop user the promise of free software. And in the free software world, we're often very quick to say, you know, it's free as in speech, not free as in beer. Don't expect it to be free. You know, there are all these other charges. We've almost become allergic to the idea of the free word because people in the early days limited it to kind of free as in beer. But you know what? That free as in beer thing is also really important. You have to have, I believe, you absolutely have to have both. Desktop software should be both free software in the Software Libre sense and free software in the sense that you don't have to pay anything for it. And so we've set ourselves the challenge of providing a fully supported for, you know, a reasonable length of time set of releases of the free software world for which nobody has to pay anything. And the absolute commitment is that will always remain the case. One of the questions that sort of people have been bouncing off me over this week has been, you know, will there be a red hat enterprise version of Ubuntu? Will there be some sort of corporate enterprise version which you have to subscribe to? Absolutely not. I will, you know, pack up shop before taking that step. There's, I have no desire to join an industry, a software licensing industry which I effectively think is dying. To me, it's all about trying to figure out how to make this work and keeping it free. So deliver on the promise of open source for the end user. We, in order to deliver that, one of the first sort of things that I considered as I was going through this was to work within Debian. I decided running for DPL but I decided, you know, there were both far better candidates for that and potentially better ways for me to achieve goals that I was setting out to do. And one of the key problems I had with that idea was that in order to optimize for a particular narrow use case we have to make a bunch of trade-offs which would be wrong to impose on Debian. So for example, in order to hit our release goals we shrink the set of packages that we absolutely care about and we shrink the number of architectures. And both things I think would compromise us to the core values of Debian. Debian being the universal operating system. There is an enormous benefit to the open source community and the fact that across all of these architectures, you know, all of these packages get compiled. Upstream guys will tell you they only get, you know, in many cases they only get porting patches from this community. So it seems to me wrong to come into this community and argue passionately to get rid of that. Combine that with distributed revision control and it seems to me that the best way to do this is to build a community that's focused on a subset of the goals in order to drive that agenda forward but to do it in such a way that the broader family, the broader community can actually benefit from that work where it's appropriate. So the kind of goal we set ourselves was to work to a narrow set of objectives but with a completely open agenda. There's no Ubuntu private, right? Like there's a Debian private mailing list. There's no Ubuntu private. Everything we do happens on IOC and on public mailing lists. There is no behind the scenes setting of agendas. We don't take a decision. My team would not let me take a decision without putting it through the kind of Ubuntu governance process. I am the self-appointed benevolent dictator for life. So I do carry a swing vote. But I'm very conscious of the fact that every time I use that swing vote or every time I advocate for something which the core team is not that interested in, effectively it costs me, I call them brownie points but ultimately it's sustainability points, right? Every delta that we have to carry is a financial cost and potentially a social cost. Anything that we do that does not meet the core values of our core team effectively weakens our community. So I'm very, very conscious of those things. What I'm really proud of over the last year is that we have managed, in fact, to lead the way on a couple of key features. Zorg was controversial. We decided to do it. And because we had a smaller subset of architectures and a bunch of other factors, we were able to do it. And I'm really proud of the fact that that work, that excellent work, is now going after an appropriate security review and audit into unstable as we speak. On a couple of fairly tricky transitions like GCC4 and Python 2.4, our team has effectively led that work. And so you can go to a location which is well known where we publish every day all of the patches of the deltas between ourselves and Debbie in a format which is easy for DDs to take and bring in. And you can get patches that are going to make the GCC4 transition for Edge a whole lot easier. And there have been some much rings about binary compatibility. And as far as I'm aware, there are two examples of binary incompatibility that have been thrown out. The first is a binary incompatibility between our Horry release and the Sarge release. And I think it's important to know that right up to the point when Horry released, our LibCs were binary compatible between Debian and Ubuntu. And after the Horry release, something came up which was potentially a problem for Debian. And after a discussion between the release managers in Debian, the guys in Ubuntu, the guys in Debian, which involved a clear recognition that this would be breaking compatibility between the two, it was decided to upload to Debian a compatible version of LibC. And I absolutely support the right of the Debian maintainers to do that. I think it's very important that we not put ourselves in the shoebox of binary compatibility. Imagine if, you know, I wouldn't want to feel responsible for a decision to say, do not fix that issue in Debian because it's going to break binary compatibility with an existing Ubuntu release. But it was not us that introduced that binary compatibility. The other, of course, is now the GCC4 transition because we're moving with GCC4 now. Our next release will be at the C++ level, ABI incompatible with Debian unstable at the time. But I'm pretty confident that H is going to include GCC4. Doca? Yeah? And so effectively what we're doing is all of that C++ ABI transition work in a way that is very easy for DDS to maintain. If we could bring up on the slide, you guys, the directory where we publish, literally for every package in Ubuntu and Debian, patches of the deltas so that it's possible for you guys to see just how easy it is. The goal of this was to say, okay, we're going to forge ahead in particular directions and we're going to do it in such a way that makes it trivially easy for DDS to take the work that they're interested in having. And I think we've absolutely delivered on that kind of commitment. So I think it's really important for other groups within the family to be able to diverge. I think it's very important for groups to be able to explore things that are particularly interesting to them. Embedded Debian looks different to normal Debian because it has to because it's important. There are priorities in that environment that are different. And so there needs to be a delta. The delta only needs to be big enough to address the specific issues that that community is interested in, but there does need to be a delta. And if you get scared of a delta, then you're effectively going to be constraining the whole Debian world in ways that I think will will limit it. You'll be reducing its freedom effectively. The flip side is that if there is going to be a delta then we better be bloody sure we're doing it in an open source way. And so that's why we have a total commitment to only shipping open source applications and user applications. We do include some binary drivers. I think it's very important that I think that's a compromise of important values in Debian. And I think it's very important that Debian has stuck absolutely to its guns with regard to the DFSG and the freedom of every piece of software that's in there. I think that's one of the things that binds this community together. But at the same time, it's useful to have within the family people who are willing to make trade-offs. For example, in embedded systems we're not going to install dock files, right? Everywhere else we do. And in the Ubuntu community, we're able to make those trade-offs. I would feel very uncomfortable with the original plan of coming into Debian and saying we should allow binary drivers because it would have been a compromise of the core values that bind this community together. In as much as we've made compromises of those values, they're very clear, very explicit, and they're there for a good reason. And I can only do them in good conscience because I know that Debian maintains those core values. So what are the core areas of investment? Where are we actually spending money? We hire, we employ, I think, just 20 Debian developers. I think it's exactly 20. It's 19, but I'm reactivating my key. I became a Debian developer in 1995, but my key is now dormant and I've mailed the damn guys to go through the reactivation process. So with me on board, there will be 20 Debian developers. I think that's about seven times as many as any other organization that I'm aware of. That's a tremendous number of DDS that work full-time doing work on Ubuntu and all of those patches are available. Just to give you some idea of who's on that team, our CTO, Matt Zimmerman, is the maintainer of Apt and Debian. Matt, do you guys know? Fabiani Massimo Donito, he's on the X-strike force. He also is part of the Ubuntu team. Matt Zimmerman's troop, the legendary dam. A pretty maintainer of Postgres. He is full-time working for us and focused on security. Doko. You guys know Doko? He is a maintainer of GCC and Python Bash in Debian. He's also on the Ubuntu team. Mako, he maintains Sanity in Debian and works on the SPI board. SPI. DAF, Keybuck, D-Package maintainer. He works in, he's on the Ubuntu team. Daniel Stone, X-strike force, Michael Voigt, Synaptic, Tolif, Fogheen, CFEngine. Injaxon is joining the team. He's on the Debian technical committee. Seb Sebastian, Seb128 is our denominator. I think that's many of the guys. That's the lion's share of the investment that we're making effectively is in people who work full-time on the distribution. We're also investing quite heavily in distributed revision control, Baz. That's getting to the point now where I can absolutely recommend it for upstream projects. If you're starting a project, then try Baz. It's a hell of a lot cleaner and better than TLA was. If it's something experimental, then try BazNG because BazNG is a lot easier to contribute to. It's in Python. It's a fresh thing, and I really think it includes the best of Bitkeeper, Docs, Monotone, and Arch. How do we organize ourselves? There's the community council of which I'm a member. Other members on the community council are Mako and James and Colin Watson. Some of you guys know Colin from Groff and DI. We also have a technical board and that's chaired by Matt Zimmerman, CTO. Technical board is responsible for technical issues, community council is responsible for social structures and processes. The appointments to those are effectively confirmed by a vote of all the members. We also have local teams, local community teams, which are guys spread around who form local advocacy groups and so on. In terms of process, fundamentally we freeze unstable every six months and then we spend a certain amount of time polishing and integrating the various pieces of that. What it ends up looking like is something like this. If this is CID, we end up doing something like that for a few months and then we end up doing after our release we end up sort of doing that and then we come back. For a few months after our release the Ubuntu release is horribly broken. Breezy was scary for about four weeks while we were breaking GCC modularizing X, moving X from user X11 R6 to user bin and doing all of those scary crackful things. We have this kind of alternating thing that varies around effectively what CID is doing. We absolutely depend on Debian's continued success because this is effectively the anchor to which we have to come back. It's a hell of a lot of work to merge back when we have to merge. At this point generally after upstream version freeze we are merging in a lot of changes both ways from Debian and changes that we've made previously. What would make that work a lot easier is if Debian maintainers took more patches from Ubuntu and so that's why we sort of go to the trouble to make those patches available in real time and in the easiest possible format. This is not thrown over the wall open source. If we make a patch and make the upload within hours or days that patches are directly published with no extra work for the maintainer. That actually makes me think of something that I think is really, really important. We have to try and do this stuff in an automated way because getting 20 guys to collaborate with 1,200 guys doesn't work if it requires detailed personal relationships and conversations. If we wanted to have a five minute conversation with every DED it would be the whole day gone just having that conversation. Something that I really hope that we can get a bit of an appreciation for is to the greatest extent possible what we're trying to do is make it possible for people to collaborate with us in as much of an automated fashion as possible. It's easy to say hell, why didn't you come and explain to me why you were going to make this patch? But if you multiply that up across 1,200 maintainers it becomes effectively an impossible communications burden. Small organization can effectively compete with Debian for communications balance. Debian is highly parallelized and we're not. That's why we focus so much on the automation. The next step for us is, for example, is to automate our relationship with the BTS so that when we fix a bug which we know is in Debian we will notify the Debian BTS automatically. There's some controversy around that because we have had DEDs when we've gone into the BTS and said here's a bug that we found and here's a patch for it, right back and say fuck off, don't disturb me with your patches I don't consider that a bug. And that's kind of difficult to deal with because socially it's a huge burden to go through that and if you have people telling you they don't care then it wittles down your willingness to continue to make that effort. So that's why we're going to do it to the greatest extent possible in an automated way and we'll extend the existing infrastructure we have so that you as a DED can automatically effectively say, yeah, send me all the patches you've got, automatically send me all the patches you've got, send me information as the status changes in Ubuntu so that you can have the best possible framework for doing this. If we want to realize this dream of different groups that focus really hard on particular areas but with tight collaboration between them we need to recognize that that collaboration will not happen in the same way that it happens within a single organization. It just can't work that way. One analogy is if you consider a mountain range you can be the best mountain area in the world. There's no mountain there that you can't climb but you can't be on top of all of the mountains at the same time. I absolutely think that's true for individuals. The road to misery is to try and be good at too many things at the same time because you'll end up sub-optimizing across the spread and I happen to believe that there is absolutely no mountain that open source cannot climb. And there's no mountain, there's no goal that you could set for this organization that it couldn't achieve. If we wanted to put Bdale into orbit we could do it. Right? Absolutely. Yeah, it'd be a two-way ticket. Exactly. There'd be a small crater in Arizona called Bdale. So whatever goal we wanted to set for a particular organization we could do it. Right? But in doing that we would make trade-offs elsewhere. And so I absolutely think if we want effectively this family to extend to the point where we have people waving flags at the top of all of those peaks we need to accept that there are going to be differences between them. And those differences cause a certain amount of social stress. So there was a very long thread on Develle about a fork or a branch and there's some excellent constructive suggestions like it's a spoon. Thank you for that. Appreciate it. And I read that and I sort of spent time trying to get to the bottom of this problem and what I currently think is that the difference between those is social. And the key difference between those is your fundamental assumption about the nature of the character of the person on the other side of that. Effectively different groupings like this we know what Gen2's brand is. The other day we have one of our servers called Gen2, it's named after the penguin not the distribution. But the other day James told me there was a problem with one of our production instances of Apache and he was just pulling a patch from Gen2 to apply to it and I nearly plucked. He meant the machine, not the distribution. So we know what Gen2's brand is right. And when you meet a Gen2 user you have an immediate kind of assumption of what they're about and the approach that they would take right, bling, crack. The I hope there are no Gen2 users here. What I'm worried about is the fact that the representatives of the media are typing as I speak. Okay. Those sort of assumptions about what's going on in the other community are really important. So I hope that what we're able to do here is give some sort of window into what's going on in the other community. These are Debian developers right. I think they are superb Debian developers right. These are guys who care very deeply about Debian. They have in many cases carried Debian right over the last 5, 6, 7 years through some quite difficult times. So don't to the extent that you have a knee-jerk reaction that is negative and that that colors the kind of communication that you have you're effectively creating the social circumstances in which we could get a fork. It's a failure to communicate that creates a fork and nothing to do with source code and everything to do with communication. So a couple of questions that people have thrown at me. Hey, are we getting any questions on? Okay, cool. I just want to run through some things that people have asked me that I've answered then and I'd like to sort of answer for wider consumptions. First, will the Buntu be around? I heard a rumor it'll only be three years. When we started this I was basically asking guys to leave good jobs to come and work with me on this crack-full project and I needed to be very clear with them the extent to which the risks that they were facing. When you ask someone to leave stable employee and come and work for effectively a startup venture with tricky revenue prospects you need to be very clear with them. I couldn't go out there and say whatever because I didn't know if it would. There's been no point if we couldn't actually achieve anything for me to continue to fund it. After one year I extended that again for another two years because I thought the progress in the first year justified an additional two-year commitment and recently I figured this is actually a really good way for me to deploy the funds that I have. So I've set up the Buntu foundation and I've stuck enough cash in there and made provision for it in my will that you can bank on it that for certainly a technology generation in our time. So the world that we're living in is that both Debbie and Buntu are going to be here for our careers effectively. This has become one of the ways in which I want to leave a mark on the world for better ways. This is one of the things that I absolutely want to see there. It's one of the best things that I think I can do. So the foundation essentially creates a long-term framework for that that is independent of what happens with Canonical, independent of what happens to me to a certain extent. Another question is why did we start off secretly? There was SSDS, I think that was an HP nickname for us, the Super Secret Debbie and Startup NoNameYet.com was our domain for a while and the corporate name was very unfortunately chosen by the bank as Mark Richard Shuttleworth's virtual development otherwise known as Mrs. VD which didn't go down well given that our first release was called the warty warthog. The reason behind that is that I hope you can appreciate that I live a somewhat unusual life and if rumours spread about something that I'm doing then it tends to get massively blown out of proportion in the media in South Africa. So I'm generally very careful about saying that I'm interested in something that I'm committed to something that I'm doing until I actually really know that this is full steam ahead. At one stage I thought that the stock exchange in South Africa was inefficient and that we needed a pan-African highly liquid, automated, real-time stock exchange, sort of an interesting thought to wake up to in the morning. So I went to Nigeria and I met with the stock exchange guys there and I potted around and the word got into the media and the next day I had the finance minister of South Africa calling me saying what the hell are you this is such a cool idea, what are you going to do and I hadn't made any commitments to it at all huge chunks of people had figured that you know I was going to go in there and build a stock exchange and it turned out that I wasn't going to do that when I looked into it, it was just not something that I could particularly add any value to. So I learned from that experience you know don't go shooting your mouth off and don't you know publicize what you're doing until you're absolutely clear about it. So for the first six months while we were pulling a team together and figuring out how we were going to do this we kept it confidential and we didn't have a name once we had the name you know since from the moment we came out with the preview release and effectively said that this is a project that I was working on there's no passion point to private or private mailing list what you see is for better or worse what you get. I've addressed the binary incompatibility issue let's talk a bit about money because it is the root of all evil. So I have set up a set of structures effectively to hopefully in my lifetime but if I get hit by a bus over the course of what would be a normal lifetime deploy those funds into things that are I think important and good. Mostly that goes into the foundation in South Africa but now also it will go into Ubuntu. Of course I also enjoy my old gotten gains and I will be going back to space so you know by no means a monk the important thing about that though is that just off the back of normal investment processes I in a good week make more than the entire Linux technology and service industry put together Red Hat, Novell, Inspire, Zandros Progeny, Canonical this is not about trying to make money it's very frustrating for my financial advisors that I devote three days a quarter to them when they effectively continue to grow the assets of the foundation and everything else to Ubuntu will certainly never deliver any sort of substantial return so much of what I'm doing here is because I think this is a really important infrastructure to set up. I think over the next 20 years we need this. It's very difficult to see beyond 20 years but over the next 20 years we need this at the same time if we can get this to be sustainable then we should. Partly that's a challenge and that's interesting and partly because remember the big dollar I spend on Ubuntu is a dollar that I don't spend on something else that I think is very important math is eating somebody else's lunch so if I can get people who have money to effectively make that to our investigation field just skinny enough as it is if I can get this operation to be sustainable I think that's a very admirable goal I also think it's very important for the health of the whole ecosystem that if you have something like Ubuntu you have ways that the community can interact with it ways that nonprofits can interact with it ways that corporates can interact with it I don't believe that Canonical will ever make substantial amounts of money out of technology, service and support it's revenues for the entire future from software licensing from Ubuntu are going to be zero and professional services and support is not a great business to be in it's just not going to make a huge return it's not really an economically rational way for me to be spending my time but I think it's important it's important in the same way that in many countries you have a reserve bank which is a small private company that doesn't make much money but which is kind of a lender of last resort it catalyzes the industry it's the organization that the other banks can go to effectively to help set the pace of the market and Canonical is there and will publish a price for desktop user support means that we create effectively a reference platform and every other company and there are hundreds of other companies that provide Ubuntu support they use that reference platform as a way of justifying their own revenues they say that's our pricing because Canonical provides it at that also it gives smaller companies a way to compete with bigger companies because they can go effectively to the reserve bank and get a banking loan which I'm using financial and economic terms but basically a way of saying we can provide escalation support so I think it plays a very important role in the health of the ecosystem to have each of these pieces pieces of the puzzle and yeah, I like a challenge I like the idea that we're effectively changing the economic patterns in the software industry and I think it would be very cool thanks, very cool to do that in a sustainable way I have a minute alert I've addressed most of the questions I had let's see what do we have do we have anything quickly maker from I'll see you guys okay cool okay will you link with the timing guys so we know where we stand who's got a question, let's get a microphone up there so there's a question a question up there and do we have anything from one question was who broke the spatial models sorry okay I have to take that bullet I broke the spatial nautilus in Horry and for that I apologize for the GNOME people that I offended, I apologize there let me give you some background to that at early on in the process I had problems with spatial and so I asked us to try something different and for communication failures internally that patch got dropped and then right before release I was going through my list of things that I'd asked for that wasn't it and so I asked the decision for the patch to be applied knowing that it would be rough knowing that it would that it would be tricky but just said you know this is my call let's go in now to put that into perspective I make maybe 50 different calls around packaging organization docs code bits and pieces that are kind of things that I really want to see in and this is one of those there have been lots of other ones that ended up working really well decisions that we made around how we organized the desktop and so on and this one sucked ass you know I'm sorry about it but that is part of what we can do in Ubuntu right we can take risks those risks don't cost you anything and I think it's fairly clear that Deleon has learned not to put in the kind of spatial not to modify spatial in the way that we did I think that's a valuable contribution to if nothing else science it's a negative result so that was entirely my fault please don't flame Seb or Jeff about that that was my call and they protested vigorously and and I asked for it to go ahead anyway let's take Jeff's question go ahead Jeff yes I was wondering with the Ubuntu patches and the changes that you make to Deleon packages in cases where Deleon maintainers disagree with the work that you've done do you have any kind of process or could you go into the process that you use to resolve those conflicts so that you don't turn into a fork or that you don't have a dispute there so any delta is a cost any delta is a cost to me and it's a risk and you know as soon as we have an indication that there's going to be a delta there's always going to be a delta anytime we do something new but if we have an indication that there's a delta that might be a sustained delta then I have to really review it and in some cases those have happened and we've said we're going to go ahead some cases we've said we're not going to go ahead in each case we simply have to review it and sort of figure out what as a group we're going to do and whether or not we or I am willing to carry the cost of that delta in most cases in most cases when you actually have an extended conversation that the delta gets closed but not in all cases and I'm absolutely willing to carry a delta right if it's something that's important for us to stay on this peak over here he's not going to carry the delta he's not going to carry the delta and Debian may well not carry the delta but it's important for us to address a particular need so we're going to do that Jen we've got a question at the bike let's just take another question over here and then maybe in you can chip in after that this relates as well during the threat that you referred to earlier the Ubuntu fork there was one post that there were bugs in Debian that had not been picked up by the maintainers from Ubuntu and one of those bugs I looked into and I saw that the patch that was submitted assumed that Udev was available and Udev isn't available in Debian yet because it's not across all platforms we don't have the kernels yet so is it possible to distinguish between patches that Debian is ready for and things that should probably go into Debian but not yet that'd be quite difficult to do on an automated basis because we could probably test if the patch will apply cleanly but testing patches that infer policy machines would kind of require us developing a Turing machine Matt, breezy and that that would be tricky what we could probably do is, or what I hope we'll do is extend the infrastructure around the patches to the point where there can actually be a conversation and maybe where you can mark up and search I don't want to look at it again part of the thing with distributed revision control is to assume that every patch is going to necessarily apply cleanly or be the right thing when you do emerge there's some responsibility to say what am I merging and is it going to work in general I think the process will work was it a big problem for you, did you apply the patch and then have it fail spectacularly okay look that is going to happen for example architectures we have a different architecture set so a patch may not work it may fail to build from source but I think that's part of the healthy process there are better guys in this community to address that issue than in the Ubuntu community to the extent if you have ideas as to how we can avoid that we certainly can do especially if we can automate it but I can't guarantee that every patch will apply cleanly in both cases Ian, you wanted to just clarify further yeah, so there's been a lot of sort of is Ubuntu a fork there seems like the same question as Debian a fork of all the upstreams and what Ubuntu is doing to Debian's packages is pretty much exactly the same thing as Debian has been doing to its upstreams for years and each time we make a decision about you know we'll apply some patch and we send it upstream and if the upstream hates us then we say well you know I mean we want this patch and that's our decision and I don't think there's anything that Ubuntu are doing that's wrong and I don't think it's going to could choose they could choose to actually fork it and make it so that the two versions weren't compatible but that's you know as Mark's saying that's just so expensive and such hassle we in Debian don't want to do that for our packages and make them you know so that we can't apply the new versions from upstream either and it's the situation seems entirely parallel okay cool so one of the cool things I think is that every single guy here is a line of code there's a 99.99 9% chance that that code is going to land up in an Ubuntu release with semi-naked people on it the just kidding the flow I hope will continue to be that good effectively that anything that you guys work on will also reach that community right and I know that the majority of guys in the free software community are not shipping high quality stuff to the greatest possible audience and so I hope that we're providing in one sense a really valuable service effectively taking this phenomenal code taking it into places where it otherwise wouldn't have got or wouldn't have got yet and so in some ways I hope that that's the kind of a critical service that we provide Debian provides critical services of its own it is in many ways the conscience of the open source community right it's the one community that has remained connected to the fundamental principles of free software and in partnership I think that's tremendously powerful thing Brandon? It's not a follow on question it's one from scratch so I mean okay I was wondering because it's difficult for me to accept as an article of faith because I'm a pretty skeptical guy that Ubuntu is necessarily a good thing for the Debian project in all possible respects I have to wonder how would we measure that if Ubuntu were somehow harmful to Debian how would we know that how would we measure it and how would you react to it if you saw those same measurements So I'd certainly you know I'd welcome that and I don't expect you to take it as an article of faith right you know I could be wrong we could be wrong they you know I don't expect this group in particular to take anything as an article of faith I think in this case constructive paranoia is part of the engine of the success of Debian paranoia is a healthy thing I'm a pretty damn skeptical guy myself I hope that over time we have an open line of communication we've had some very good conversations and it's important to me that my relationship with the DPL always be clear and not just with a person in a role capacity but within developers I hope that Joey had a great expression for this debate he said we should try to bring more light and less heat and I think that's an excellent way to phrase it right I hope that we can continue to have a good conversation my phone number Brandon did I actually answer your question Brandon's question was how do we know how do we measure that Ubuntu is actually a good thing for Debian and for the free software community it's really important to me that we get this right I do not want to go screwing up what I see as the big fundamental wonderful thing that's happening in technology I absolutely want to get it right so if you have any clear indicators that we can use then call me far away okay thanks about software startups and Linux in general you said something like lots of innovations come from from small software companies now I see a problem here that that they try to protect themselves from big companies and other competition by patenting and so on now imagine there is a software company with really good usability innovation what would you say company head why go open source because there are so what is there to gain because there is so much to lose you know they have put maybe 1 million dollar to make this thing there are so many a new software company today can you use the ones behind the podium there are so many reasons for a new software company today to go open source you know there you can argue that there are moral and ethical reasons but the one that is a killer to a business guy is simply this is not about right and wrong it's about winning and losing and you are going to lose if you are not an open source platform because you are going to be competing with people who are building on an open source platform and if they are building on an open source platform they are almost certainly going to be using an open source platform and they have the community behind them I absolutely think that the prospect of building a proprietary software business in 10 years time is going to look and feel about the same as starting a wooden horse-drawn carriage company you know did in about 1950 clearly a very very bad idea and sort of missing the point of where the industry is gone at the moment that's still you know there are still a lot of guys out there who don't see that but you know in my mind it's absolutely clear and I make that argument anytime I meet somebody who is in the business one way or the other the really hard position to be in is to have a big vested interest in one way of doing it the guys who are really going to struggle will beat up a Microsoft but it goes deeper than Microsoft it's anybody whose size of company is currently determined by the revenues they can generate through software licensing because those revenues are going to come back by a factor of 10 at least and they are going to have to restructure and re-engineer and reinvent themselves and while they are sort of beating this steady retreat young companies are going to come up starting from fresh with the right attitude the right values, the right approach they are going to be very vulnerable in the interim so it's actually very difficult I think for existing and trenched companies to get to where they need to be it's easier if you're starting out to get it right from the beginning yeah Andreas thank you at first for making Debian popular in the world and I think it's a success of Debian was very popular before I came along but as you did it more people learn to know success always creates rumor and so I hope to we can a little bit calm down and I hope that's a cutlery of spoon and forks there's no knife in between and my question is how is this kind of universe related to this graph I'm a little bit afraid that the Bundy universe is some kind of sit in parallel and there's a potential to split up and why are these volunteer there is a risk it's the same risk that the Linux kernel will fork they're that's something that people argued that's something that Sun and others waived around as a big stick you can't trust Linux because it's going to fork you can't trust the GPL you can't trust open source because it's going to fork but in fact there is absolutely no indication that the Linux kernel is ever going to fork for good reason right you see Linux, user Linux user mode Linux those are effectively sort of sustained long term branches but we're not going to see a fork in the Linux kernel unless there's a real social problem in the way that Zorgan X386 forked because there was a social problem and so that's why I say there's no code or technical frankly business pressure to fork Red Hat has effectively been found out I think that it's very expensive to maintain a fork of the upstream world I mean Debian all destroys in a sense a fork of the whole of upstream as the end pointed out but Red Hat took this to an extreme and you know I would never have joined this industry if I felt that that was a natural endpoint because frankly you know remember every dollar I spend on this comes out of you know other projects education and health and so on that I think are really really important in places that I really care about I don't want to carry 500 developers maintaining you know vast numbers of patches that's pointless yeah let's get the microphone over here Linux simply carries a lot of trade marks if you oh sorry the question is why is Ubuntu, why is the tagline Linux for human beings and not Debian for human beings first within Ubuntu if you go panel about Ubuntu you'll read about Debian I haven't yet met somebody who uses Ubuntu who doesn't know that it's based on Debian we don't call it Debian there's reasons why I chose the name Ubuntu it's important to me it's a particularly special word in South Africa and I think it speaks beautifully about why free software is all about there are some folks who will never be satisfied with the way those two brands interact but I think we do a reasonable job if you actually fire up Ubuntu and look at its own documentation you will immediately see that Linux in terms of the specific question of why Linux for human beings and not Debian for human beings absolutely we're simply carrying on the excitement the world has about Linux and sort of saying this is a Linux that everybody can use Jeff okay do we have a microphone there go ahead and then Jeff will come to you alright my question is actually kind of related to that and I think I would have something that might be a simple solution to it in that you continue calling it Linux for human beings but whenever you give handout trainings to local customers or when we get around developing something that might be an Ubuntu certification system in place then we market Ubuntu Linux and we deliver an Ubuntu Debian training Ubuntu Debian Linux yeah right okay and by the time we add the BSD license to it right becomes impossibly long but my point being that to keep that leveraging that popularity of the word Linux would be simple enough to keep on doing it that way but when you do deliver something then you take the opportunity to point out I think you identified some sort of key communications points that we need to make sure we preserve that message and I'll work with you to do that okay sorry before we continue well first of all it's have to be Ubuntu Debian GNU Linux secondly and more importantly we're extending into the launch period now if people want to stay and continue asking questions that's fine but be aware you may run out of time to eat lunch so it's up to you I want to take Peter's question because he always asks good ones sorry also there has been a person waiting here quite patiently for a while so I think okay Jeff do you mind if we take some from here okay okay go ahead so from the from the SPI trademark committee I'm not entirely sure that we can say this is based on Debian you can use Debian descriptively but as long as something is using Linux the trademark they can say this is Linux I'm not sure that it would be that our trademark policy or our ability to keep a Debian trademark would allow us to allow people to call non-Debian distributions Debian is that DFSG compatible that's a conversation for another okay let's get the patient question and then Peter's question and then Jeff's question okay here we go switch it on come down here Peter or just shout and I'll repeat it just just ask me and I'll repeat the question the biggest missing features on the Linux side at the moment which is Java and the other thing do you have an opinion on software patterns and are you doing anything to push your message to the right people okay so questions where we care about desktop Linux are we doing anything about Java and Flash which Peter describes as the sort of key stumbling blocks I agree I think those are two of the critical things we need to get before people have a seamless desktop experience there will always be those critical stumbling blocks and it's something that we feel more keenly in others and remember there will always be some people who just want to retire before Linux actually happens in their company and they'll say I bought this PDA yesterday and it doesn't sync so this entire company can't move to free software I don't actually see critical blockers in the same way that other people see critical blockers to me it's all about percentages in any large organization there's a percentage that can switch right now they don't need Java they don't need Flash so I don't see any blockers to the process of starting the deployment of Linux in terms of Java and Flash I don't invest in either of those DoCo and others have banged on the use of GCJ particularly in the open office context but that doesn't really solve the problem I know that there is some interesting work now on a sort of free reference implementation of Java and I'm pretty certain that this problem is going to go away but be honest we don't invest very heavily in upstream development except in the areas that I described for division control, bug tracking and so on and your second question was software patents software patents are evil before before you clap patents themselves are not evil patents are the original open source and here's how patents are effectively a viral GPL style mechanism to get people who've learned something interesting to disclose it so in the old days if you learn something interesting like how to make asparagus soft you would keep that in the family for generations and the rest of the world wouldn't know that secret that was a trade secret and companies in those days would say trade secret that's how they advertised that they had something cool and nowadays people say patented formula that's how they advertised that they've got something cool but effectively what a patent is is a trade with an inventor for disclosure like open sources about disclosure in return for a short-term monopoly and that's reasonable the problem with software patents and business process patents is that there's no trade we give these guys a monopoly for something which they could not keep a secret you can't keep a software process a secret you can't keep an algorithm a secret and you can't keep one click or a business process a secret the moment you do it everyone says cool idea we'll do it too so in terms of the benefit to society argument software and business process patents are a complete rip-off society giving away its rights to an idea in exchange for an idea that they would have had anyway the moment the guy started to do it so that's an argument I know people sometimes don't like it when I say patents as a whole are not evil but software patents and business process patents are they think that's equivocating but this argument is one that really catches legislators because it's a way of giving them a bullshit test against the lobbyists when the lobbyists come and say you know this is something that you need to do they can ask them the question what is the economic trade that society is making when you do that it's the same with copyright extension the RIAA goes in and says you must extend copyrights or the Beatles will become worthless and we need the continued royalties from the Beatles music so that we can find new stars and support the music industry what we need to be saying is when copyrights expire they don't become owned by nobody they become owned by everybody and you need to make an economic argument because that's what legislators are looking at they're looking at the benefits to society but cool thanks for the question Jeff yeah I decided to move down here so the microphone would move quicker if I could indulge a little bit of paranoia for a second looking at the roster of employees and looking at the roster of very core people in Devin you find a great intersection there's several people who might become nervous about this and who might wonder for example if Ubuntu is going to become the horse that drags Devin the cart behind it simply by virtue of the fact that that Ubuntu is paying all of these people and thus has a lot of influence over the direction that Ubuntu takes and also then as the direction that Devin takes I was wondering if you have any response to that or perhaps you've set up any kind of procedures to ensure the independence of things and so on I certainly do, I have one absolute rule which everybody knows and that is that specifically to ensure independence I will never employ the DPL well every DPL it's a rotating job so Brandon they'll come in time that's a tricky thing that we haven't yet had to deal with but it's a conversation that I generally have with anyone who clearly has made the sort of commitment that would put them in line for that position and it's a tough one but I think it's really really important and absolutely this is no question of the independence of Brandon I think he's doing an excellent job and I've enjoyed the conversations that we've had thank you but can you imagine the constructive paranoia when Michael employed the DPL I would feel uncomfortable with that and so that's why from the very beginning it's been sort of one of the key things positions that I would not want to employ folks in and it's sort of worked out that we do in some cases sort of unexpectedly for me but I kind of just deal with that and we go on I think the independence of Devin there are a couple of things that are absolutely critical values for Devin the first is the DFSG the critical focus the single-minded focus on that Bidale pointed it out in a meeting the other night the second is its independence and so it would be a real problem for me if Canonical employed the DPL it's not so much a problem for me if somebody else employs the DPL because that's between them and you know but it would be a problem for me ports are a critical thing there was a rumor that somehow the Vancouver proposal was my idea you couldn't be more wrong I think one of the critical things that this group does is sustain architecture independence in ways that are interested we are seeing Nokia doing really interesting things we're seeing Nokia doing really interesting things with Devin because of the ports infrastructure and that's really really important and that's going to get more important because this world is getting more complex architecturally not less so these are sort of key values that I would never want Devin to compromise on any other questions anything else from IRC I have one go ahead who do you think has the responsibility of submitting patches to the really upstream I mean that you make the if I can get a patch upstream that's prize number one because then it goes to Gen2 it goes to Red Hat it goes to Devin it goes everywhere I think we should all remember that open source is about upstream and if we can get something into the kernel upstream that's the first prize if we can get something into X upstream that's the first prize it helps all of us one less patch that everybody has to maintain so you are also working about with the yeah absolutely I mean for example I work on Xorg our Xorg maintainer is also part of the Xorg upstream team so that has really helped our ability to do that and to the extent we can get work in upstream for example supporting multi-seat multi-arse as we call it 441 style configuration where you got multiple windowing terminals chunk of work or that to the extent that we can get stuff upstream absolutely that's a win for everybody in the open source world upstream downstream midstream is not as simple as a clean picture would suggest you take the most efficient route possible I think we're cutting too far into people's lunchtime so I'm going to stay here we can also Mark and Croft asked me to get together over a beer and I asked him to invite anybody else has more questions so it's Mark can I do this okay I'm going to do it anyway so it's 6pm sort of over at the hotel at the covered sort of drinking area drinking pivot in there we'll over a beer continue questions and answers and I'll stay here now if anyone has particular questions they want to come so thank you very much thank you guys