 So, good morning. Out of curiosity, how many of you have never heard me give a talk at any other kind of event? That's really exciting. Thanks very much for coming out. I don't know what the excuse the rest of you have is, but hopefully we'll have something that's at least a little bit informational and entertaining. I'd like to start out by thanking the FASGEM organizers for inviting me to come. I had an interesting conversation in Argentina earlier this year with a couple of the organizers and some of their friends who happened to also be my friends. And they asked me, Bita, why do you never come to FASGEM? And I said, well, I've always wanted to go, but there's sort of two problems. One is, nobody's sort of ever invited me, and they immediately tried to explain that that isn't how FASGEM works. And I said, no, no, no, I understand. But there's this other problem, which is that we always have a big internal meeting at HP that happens at about the same time. And it's really important for me to be there. And it's really hard for me to be on two continents at the same time. So I want to thank both the organizers for actually inviting me this year to come and speak to you this morning. But I'd also like to thank whoever's responsible for the current economic downturn since, because of that, internal meetings in my company that involve travel are not happening right now. And that means I was free to come here. So who am I exactly? I tell people that I made my first personal contribution of source code to this thing we now call Free Software in about 1979. There's a little bit of assembly language for a microprocessor system which was pretty obscure back then and has been completely forgotten by almost everyone except a couple crazies now. But it was interesting because this was a little contribution I made by sending a typed letter on a manual typewriter to a newsletter from a small computer group that was based in Hamilton, Ontario in Canada. I was living in Virginia at the time and they published my letter to the editor with an explanation of how to solve a particular little programming problem in their newsletter. And the club president sent a letter back inviting me to come sometime and be a speaker at one of their monthly club meetings. And of course the problem was I wasn't old enough to have a driver's license, much less to travel internationally without some kind of support. But it very early on sort of taught me this lesson that if you were willing to do interesting stuff and freely make it available for other people to take advantage of to use and to build on, that really cool things might happen as a result. I've had the privilege of working for the Hewlett Packard Company and one of its flavors going back to 1986. And since about 2003 I've been serving as chief technologist for open source and Linux. And in that context I have the opportunity to try and help shape and guide HP's engagement with the worldwide Linux and open source communities. And that's a pretty cool combination for me. Along the way, the reason I'm here this morning I suppose, and certainly the reason that most of you may have heard of me if you have, is because of the long history I've had of involvement with the Debian project. And for the last few years I've been serving among other things as chairman of the Debian Technical Committee, which means that back in December I surprisingly, due to an interesting little clause buried in the Debian Constitution that I and almost everyone else had forgotten about, found myself suddenly thrust in the position of also being the acting secretary of the project in the middle of a relatively contentious general resolution process. Not really what I wanted as a Christmas present, but it's kind of worked out okay. Out of curiosity I think I'm correct in saying that there are currently three present or former Debian project leaders here this weekend. I'm not Steve yesterday and I know Martin Nicol Myers here, and of course I qualify. Are there any other project leaders in the audience that I don't know are here? It's always good to know how many people are going to be checking your fax. So how many of you in the audience are registered as Debian developers? That's pretty cool. How many of you use Debian? That's really cool. And how many of you use Debian or some derivative? Ubuntu, NAPEX, Sandro, one of the other? That's a big number. That's very cool. I'm very pleased to have the opportunity to talk to you today. Some of what I'm going to talk about to all of you may seem a little bit familiar, but I hope that maybe the perspective that I've accumulated over the years being part of the project since very early in its history and then spending a lot of time trying to think about the project and how it fits into the larger scheme of things in the open source ecosystem will lead me to have some things that are interesting and useful to you. But I also have to point out that I don't just do software things. I'm one of those people who does sort of have a life outside of computers. I've also spent time through history as a hobby working on things like amateur satellites and high-powered model rockets. And this is what I'm talking about when I say high-powered model rockets. How many of you have played with things like Estes model rockets, the little ones as kids and stuff, a few? Many of us did at certain points in history. Well, that's my son Robert, and he and I now play with these slightly larger versions. I succeeded finally on my second attempt as those of you who watch my blog will know in November in Colorado in passing the certification test for the level three in the high-power rocketry hobby, which means I'm now licensed to buy and fly the largest motors that are available in the high-powered rocketry community. This particular rocket is called a goblin, and it went to, I don't know, around 6,000 feet, so that's what. Just shy of 2,000 meters. That's what it looks like taking off. And for those of you who don't know Colorado Geography, that's Pike's Peak just to the right of the rocket in the background as it's headed up. I have video of this on my notebook. If there's time at the end in the Q&A stuff, somebody feel free to ask me and I'll figure out how to show it. But I also recently had an experience, actually two weeks ago yesterday, from which I'm only starting to recover my facial dignity. I don't know how many of you heard about this, but at Linux Conference Australia a couple of weeks ago, in the fundraising auction, to raise money to help try and cure the seemingly disastrous disease afflicting the Tasmanian double population, I somehow in the middle of the conference banquet agreed to let Linus shave off my beard for charity. And we raised $40,000 Australian for that charity that night, which I think is just completely amazing. I had no idea what a media circus this was all going to end up being. The Tasmanian local television station sent a crew. The newspaper was there. I have a video clip on here again if you really want to see it asked later, and I'll be happy to show it, of what got covered on the TV about this whole experience. Two weeks ago today, that's what I looked like. The funniest part was the email from my wife saying, please don't wait until you get home to start growing your beard again. So I'm pleased to report two weeks today, ago was the last time I cleaned up after this whole experience, and I now do have enough to start playing with again. So anyway, enough about all that silliness. I'm here to talk to you about Debian. What is Debian? Well, those of you that are using Debian in one form or another have, I think, a very physical, real practical sense of what Debian's product is in the form of a new Linux distribution that I think is unarguably one of the more interesting software platforms in the planet. But the more interesting thing to me is this notion that I've been talking about for many years, that the Debian project is really an association of individuals who have made common cause to create a free operating system. And in fact, some of the most interesting things that I think have been observed about this whole phenomenon and that have gone on to be lessons for other people in the open source world over the years are things that have come about by observing Debian more as a development project and in some sense as a social phenomenon than as just a piece of software or a collection of pieces of software. Why is it that Debian matters? Well, we heard a lot in our first keynote this morning about this whole notion of freedom. And I think that one of the things that really causes Debian to be differentiated from other operating system distributions of different kinds is that it really is strongly focused on freedom. It's all about the freedom. At the end of the day, we also want it to be a high quality, secure, useful, pretty pile of software that people do useful work with, but if they can't exercise all of the sort of core fundamental freedoms that we've come to associate with free software in the process, then it wouldn't be Debian. I think it's also interesting that sometimes those who look at the project from the outside have an interestingly twisted impression of what is really going on there, and they have the sense that there's something hugely dysfunctional about Debian. They see lots of acrimony on mailing lists and all sorts of struggles and tensions within the project. I actually have a very different view that comes from having been a core participant in the project now for, wow, 1994. So it's 14 and a half years or something. I see Debian as being an incredibly stable and functional development community. There is a huge non-vocal majority of participants in the project who just keep doing the stuff that they do. And as a consequence, every day there's a new release of our unstable distribution with a substantial number of bug fixes, improvements, new versions of software. There's this huge ecosystem of people using that software to do very useful things beyond the aspirations of the individual developers. And this whole thing has been working now very well and very consistently for, you know, on the order of a decade and a half. I think that's a pretty amazing testament to it all. Every time we get close to a stable release and we have yet another sort of issue that causes us to delay a week or a month or a year or however long it takes, we see, you know, all these things flying around in the media about, you know, is Debian broken? Is the project about to break? Is this the end of an era and so forth? And I just don't always understand. I think sometimes it's a consequence of the fact that there's a lot of noise generated by a small number of folks in the project while the rest of us are just merely getting our work done and enjoying being part of this amazing phenomenon. I also think that one of the reasons Debian matters so much and so many people have chosen to use it as the basis for their derivative works is that the project supports such a large number of processor architectures and has so many packages incorporated into the main distribution, you know, mirror network and so forth. I've had the experience personally of working with a lot of different operating systems over the years and even lots of different versions of Linux. Part of my job causes me to go off and install and play with other distributions at various times for various reasons. And there's something fundamentally different and better about not having to go look in lots of different places to find the extra software that you want to have on your system to build a complete solution to whatever problem it is you're trying to solve. There really is a benefit to having a set of consistent documented policies that are being used to drive the way that software is packaged and integrated into a cohesive system. That's not to say that all of the packages in Debian are of uniform quality. I think anybody who's ever run the distribution understands that there's some real crap in there along with the really great stuff. But there's a uniform process for filing bugs against those packages. All of those packages are held to the same structural standards and are run through the same quality testing mechanisms and so forth as part of our release process. And the fact that the project remains very open to new contributors means that there's no real reason to go do something separate somewhere else. You can come be part of the Debian project and make the thing that you want to accomplish be part of this grand work if you want to. And finally, there is this huge downstream dependency chain. Everything that Debian does ends up being taken in as input by a number of derivative distributions. I mean, certainly the most visible over the last few years has been the Ubuntu distribution, but there are a number of others that are really interesting. And one of the things that I find intriguing because part of my job is to sit as one of the members of HP's internal open source review board, which is the body that looks at all the proposed interactions between free software and HP's product development process. I'm intrigued at how often some product that's embedding a particular piece of open source software, maybe on top of Windows, maybe deeply embedded in our consumer product, when we look at the details of what they're proposing to do, I start to recognize Debian version numbers on the source packages that they're building things from. And so even in places where people don't walk in the door saying, I'm using Debian, I start to realize that this body of work we have created is being used and leveraged by just an immense number of people doing an incredible variety of things, all of which I hope in the end are bringing more free software goodness to more of the world. This is a plot that I grabbed last night from one of the Debian Associated websites. I love to remind people of just how broadly internationally geographically distributed the contributors to the project are. This is not like one spot per person. I don't know exactly how this gets created. I know you have to voluntarily opt in to have your geospatial coordinates included in this plot. But if you look at this, there's a little spot almost everywhere on the planet that there's a significant population of people using computers and software. I think that's pretty cool. It's also cool to me that when I look at this plot, there are certain spots on that map where I know that I personally had something to do with that because I was the person who signed the key of the first developer from that country some number of years ago or something, and that's personally rewarding. But the real message here is that this is a completely international phenomenon in the finest spirit of the internet enabled open source collaborative experience. I think it's also interesting to go back and think just a little bit about some of the very early moments in the project's history. Part of the reason I like to point to this is that one of the things that I think has happened a lot over the years is other people who want to start various open source projects or communities. When they go looking around to find examples of good things they'd like to emulate or bad things they'd like to avoid, invariably end up stumbling over Debian and using us as one or the other or both of those sources of inspiration. I also think it's important to point out that some of what Debian is all about today is absolutely stuff that was present in the very beginning of the project, and other things that Debian is about today are things that evolved and that we learned as we went through this whole process of evolution as a community. Now August of 1993 was when Debian 0.01 was released. I was not part of the project then. Some people assumed that I was, but I didn't actually personally show up until the time period between the 0.91 and 0.93 release series. But if you look at this, when 0.91 was released in January of 1994, that coincided with the publishing of the Debian Linux Manifesto. This is modeled a little bit on Richard Stallman's Gidoo Manifesto. It was written by Ian Murdock, who was the original founder of the Debian project. It's an interesting document in the history of the project because it acted as one of the first attractors to the project. It laid out what Ian's values and motivations were and why he was starting this project and what he was hoping to accomplish. And many people, myself included, when we saw that document went, ooh, that makes sense. That's what I would like to be part of and that caused us to want to become involved in the project. It's also interesting to think about a time in history when Debian was being released by about 12 people. I mean, today it's just such an incredibly huge phenomenon that the notion that there was a one-person release process and a total of about a dozen contributors just causes us to stop and shake our heads a little bit. It wasn't until March of 1995 with the ODOT 9.3 R5 release that we saw the first appearance of this notion of packages having explicit maintainers. Debian was the first distribution that had this notion of packaging individual pieces of software instead of just making a big system image that you could install. But it wasn't actually until 1995 that we started to have this concept of an explicit package maintainer. Prior to that, if you found a bug in something, you'd go look at the changelog associated with that package and see who the last person was who'd made a change to it and uploaded it. And you'd maybe send them an email and say, hey, are you still working on this or are you doing something else right now because I found this bug, I'd like to fix it. Should I give you the patch to put in or should I go work on it and upload it? And obviously that worked well for small distribution in the realty process as the project continued to grow. So we had this concept of explicit package maintainers and that's when de-package showed up for the first time. By the time it got to later that year, you notice the release cycle in 1995 was a little different than it is today. But by the time it got towards the end of that year, we had deselect, which was the first of the package selection interfaces. How many of you remember using deselect before apt? Before apt. How many of you used deselect before apt was introduced? And you lived to tell the tale, so did I. The amount of time it took to watch deselect go through every possible package in the archive every time you wanted to do anything. I still love deselect. In June of 1997, another really interesting thing happened. The project was starting to grow enough and there were enough people to come to be part of Debian that we started to realize that not everyone involved in the project had explicitly come to some agreement about why they were there and what they were trying to accomplish. And we realized that it was very important to solve that, that it was necessary for our success for everyone involved in the project to at least share some common set of values and a common vision about what we were trying to accomplish. That led to the creation of this thing called the Debian social contract. How many of you have read that? What's wrong with the rest of you? It's worth reading. It's an interesting document, particularly if you're thinking about starting some kind of software project yourself. Lots of other people since then have picked up on this notion of having an explicit contract defined between the participants in a project and their user community. I'll talk a little later about the part we didn't include that maybe we should have. One of the interesting consequences of writing out the social contract is we kept talking about how we were committing that things would be free. And the problem, of course, is that not everybody agreed on what free meant, so then we had to create a definition, the Debian free software guidelines that articulated what we meant when we said free. And that was one of the more intriguing moments in the project's history because not only did that all of a sudden give us a litmus test to use for deciding whether certain software should be allowed into our distribution or not, but it was very quickly picked up by the folks who ran SunSight, which was one of the major redistribution sites on the Internet of that era, who said, ah, this is great. We'll use this as our definition of what we accept. And then it also was copied and became the basis for what is now called the open source definition maintained by the open source initiative. The advantage of participating is a non-voting observer of the OSI board, and I understand there are a couple of OSI sessions being held here this afternoon. I know that there's been some interesting tension in the past between certain folks in the European free software community and the board of the open source initiative. If you'd like to have an opportunity to meet them in person and talk to them about what really matters to you and maybe try and buy each other the head, but that wouldn't be appropriate. I'd strongly suggest going by and taking advantage of that opportunity today. And then the last point in the early history of the project that I point to is the 2.0 release in 1998. This is the first time we had an architecture other than I-386, and that's when the 68,000 architecture was first supported, and that's when the flood gates really opened. Once we had figured out how to support architecture, folks like me got excited. And over history there were five different ports. If I can remember them, Alpha, Spark, Arm, PA Risk, and then the Itanium port that I personally had some involvement in helping to get started. And today, it's just a really huge list. I think 13 architectures were released in our last stable release, and I'm not sure how many we'll have in Lenny. So I talked about the WN Linux Manifesto. These were the four key things that I extracted from that Manifesto that I think are worth recognizing and sort of interesting from that era. The first was this notion that WN was a brand new kind of distribution. I mean, think about what was around back then. SLS? What else? No, Red Hat was not. Slackware, yeah. Early Slackware, SLS. Red Hat actually got started almost with the RPM packaging system and the WN packaging system sort of grew up in parallel. WN had a packaging system first. RPM had, I mean, Red Hat had a tool before DPKG became really useful. The exact history is sort of twisted and interesting. There's one interesting little conversation that I remember being a part of where the then WN project leader tried to convince the folks at Red Hat that they should abandon RPM and switch to Deb. They actually thought about it seriously and then came back and said well, actually we sort of already done a lot of work with this and we don't really want to change and unfortunately that was one of those missed opportunities. I think the world might have been a simpler place if we had one instead of two fundamental packaging mechanisms in the Linux space but maybe that's just one of those competitive situations we get to live with forever. I don't know. I think the notion that WN was being carefully and conscientiously put together would be maintained and supported with similar care, something that's proven to be very true over the years. It's the basis of the will release when it's ready, not on some particular schedule, for example. The design process is open to ensure the system is of the highest quality. That's an interesting correlation, the notion that if it's open that'll help improve the quality. We had already at that point in history had the chance to experience the Linux kernel community's behavior and had already learned the truth of the assertion that with enough eyeballs all bugs are shallow. But this was an attempt to expand that and take it beyond a particular software project and into the realm of an entire software distribution. And also this notion that by being open it would help to ensure that the work that was being done would meet the needs of everyone in the user community. That has of course created some interesting tension over the years. What the users want, what developers want. It's not always the same thing. And I think one of the more controversial aspects of the manifesto which I suspect Ian's had lots of opportunity to think about over the years as many of the rest of us have, is this notion that Linux was not a commercial product and it never should be, but that didn't mean that Linux would never be able to compete commercially. I'm not really sure how we should parse that today, but it's an interesting thing to go back and look at. If we look at the next document that was important in the history of the social contract, if you recall, the manifesto was an attractor. The social contract took the people who were being attracted to the project and gave them an explicit set of things to agree about as a part of the process of becoming part of the Debian community. It reiterates some of that same notion and made explicit things which previously had been implicit. The Debian itself would remain 100% free from the contract. That's why things like the recent general resolution end up being so contentious. We all believe this. We all want this. Every once in a while we trip over the fact that it's not entirely true and we get really angsty with each other about what that means and what we should do about it and how we should resolve it. I'm really thrilled that Debian has enough weight in some sense and has been perceived attached to this set of values for so long that we're actually able to get other people to make changes to fix the problems that come up. Last September, the folks at SGI re-licensed one of little pieces of code that is buried in everybody's X system these days, the GLX stuff. I was really pleased that about two weeks ago, we finally got word that all of the committers who had made contributions to that code since it was originally contributed by SGI whose contributions might have been copyrightable had agreed to the change in license that SGI made last September and so two weeks ago Thursday, we were finally able to close another couple of really old bugs in the Debian distribution that had to do with the fact that we were shipping stuff that didn't meet the Debian free software guidelines in Maine. I'm really pleased because that means we won't have to remove the X server from the distribution. I'm really thankful to Simon and the folks at SEM for going through the effort they've been going through. I know that it's no fun. I'm the guy at HP who gets asked these questions and has to go try and motivate lawyers to look at things they don't care about too and I know how much work's involved. The fact that they have been willing to go through the process to figure out how to resolve this longstanding issue with the SunRPC code is really cool. I don't know how quickly we'll actually be able to close the bugs in Debian because we actually have to do some work to account for the license change and again to make sure that we have a verifiable sort of chain of progress from that license change into the code we're actually shipping. But I'm really looking forward to having that closed. And there are some things that I think are still every bit as relevant about the social contract as there were when we started. Another thing that people don't think about very often that I already mentioned when I was talking about what made Debian so interesting is that since 1994 Debian has had a publicly visible bug tracking system. It's not only publicly visible, it's publicly malleable. Any one of you can file a bug against a package in Debian. Any one of you can help to perform triage on that particular problem, figure out what's wrong, file comments on those bugs. Any one of you can close a bug in Debian. If you close it without fixing it, we'll come hunt you down and shoot you. But the intriguing thing is for something approximating 15 years, we've had a system that's email in and web out. And while there are people who work pretty hard to chase down all of the spam that gets into various bug reports and so forth, we have not had to change the openness of that process. We still allow anybody in the world to contribute to the progress of understanding issues that come up in Debian. And in fact, anybody in the world can close a bug if in fact that bug has been fixed and is no longer there. That's pretty cool. I don't actually know even many other open source projects where anybody on the planet can close a bug. It's an interesting little differentiator. I think another really important success factor for Debian is this process we've been going through for many, many years of taking the best practices that we have collectively learned about how to package and integrate software and capturing those in this thing we call the Debian Policy Manual. The consequence of this is that there's sort of a set of standards that we can apply to all of the things that are packaged for the distribution to ensure that they're going to play well with others. It's the basis of our ability to create tools that assist in the packaging process and assist in checking packages and those collectively have led to a much higher quality because things sort of are correct by construction instead of by folks having to discover things and repair them. It's not perfect. If it were perfect we wouldn't have nearly as many bugs in Debian of the variety that are easy to fix. But at the same time I think it's the only way that we have been successful at building and maintaining so many packages for so many architectures for so long with so many different individual contributors from around the world helping with the process. After the project had been around for a while we started to realize that we had a couple of problems. One of them was that it wasn't clear how the succession of the leadership was supposed to happen. When Ian Mordak started the project, clearly he was the leader of the project, but when he for academic reasons decided he needed to back away from the project to go finish his degree and things like that there was a fairly informal process where he looked around and talked to Bruce Perens and to Ian Jackson and to me who I guess were sort of the three key folks helping him at that point with various things related to the infrastructure and release process, and sort of said so what do you guys want to do? I was at that time getting all excited about working on an amateur satellite project that ended up consuming many more years out of my life than I had really expected it to, and Ian Jackson was very focused on technical things that he was trying to work on, so Bruce ended up being the project leader after Ian Mordak for a while and for those of you who have been around long enough, when he got tired it was nearly disastrous, it was a pretty bad scene, and so somewhere in that process we realized that we really ought to have some better defined way of handling who the project leader ought to be and even more than that we ought to have some mechanism for collectively agreeing on how we were going to resolve conflicts that individual developers weren't able to resolve by themselves, this led to this thing we call the Debian Constitution and it's an interesting document to me for a couple of reasons, one is it doesn't really as most constitutions do describe goals of the project or how they're going to be achieved, it really is very focused on how the decision making process should work and who has what responsibilities in the project and why. The other thing that I think is really intriguing about the Debian Constitution is that it puts almost all of the real power in the hands of individuals because if you look at the Debian Constitution almost everything that matters that happens in the Debian Project is the responsibility of individual developers working on the things that they're working on. It's only a very limited set of responsibilities that get pulled away from those individual developers and handed to one or another groups within the project. I think that's pretty cool. It's true that when someone in one of these relatively small number of documented important positions in the project behaves badly that you know it still can create quite a fuss but the fact that almost everything that happens or needs to happen on an average day for people to do useful work in Debian and to get things ready for individual release and so forth can happen without needing permission or authority from some named figure is a pretty cool thing. And I think it maps very well into how the free software world wants to work. We're not all anarchists but we do have a strong sense of individual freedom and we really want to be able to work on the things that matter to us without having a whole lot of stuff in the way between us and the work we're trying to do. It's also intriguing that Debian was one of the first places where the preferential voting scheme the Condorset style voting mechanism was put to use in a big way and it's ended up being a source of interest for lots of people who worry about how voting processes should work. A substantial number of studies have been done of the way Debian votes on things over the years and I have to admit I still think that we end up with better results from contentious votes than with any other system I could possibly imagine. It's been widely studied and is widely respected. So what have I learned from this whole process beyond just sort of observing how the project works? The first thing which, and I promised we didn't synchronize our thinking before standing up to give keynotes this morning, one of the things that I've really learned is that we should never underestimate the value of values. A long time ago, not as long ago as when I was asked, but it's been a long time. HP did an interesting thing where they went around and studied product development teams inside the company that were particularly successful and they extracted from them a set of best practices which they used to create a training program for employees called the process of management. And one of the few things that I remember from that whole process of being palmed as we call it back then was this assertion that the first thing you had to do if you wanted to have a successful community or a successful development team was to agree on a commonly held set of values. You know, at least at that point in history, you know, everybody started talking about what the strategy was. Maybe, maybe they talk about the vision thing a little bit first. You know, where is it we're trying to get to? But this notion that you had to start off by agreeing on what's important to us. What are the sort of core fundamental things that we believe? Once we've agreed on that, then we can decide do we in fact have a shared vision of where we're trying to get to. What we would like the world to be like if the things that we're working on actually all come to pass. And only then does it make sense to talk about the strategy for how you get from where you are to that place that you'd like to be and from that to derive a set of objectives. It's intriguing to me how even today many people don't stop to think about explicitly that first step, this notion of values. And I think it's incredibly important because through the history of the Debian project even when things have been intensely contentious between different subgroups within the project for one reason or another, we can always fall back on that common set of things that we have agreed are shared values and find some common ground. It gives us a way to go, okay, you know, you and I may completely disagree about what the right way to solve this problem is, but I at least know that you and I both care about the same things and are trying to get to a good result. When we forget that our mailing lists get impossible to read for a while. But through the long sort of course of the project history, I think that this common set of shared values which end up being expressed in documents like our social contract provide an anchor when things get really stormy. And I think that's hugely important and it's something that I hope that other projects and other community development activities around the world learn something from. The other thing that I've really learned is that an internal social contract could potentially be as useful and important as an external one. We didn't think about this at all in the early days of the project. Why? Because we're a relatively small group of people who were all of like mind in so many ways that I don't think it really occurred to us that we needed to have some explicit code of conduct. But this is another thing that I think we have observed as the project has scaled. And as we've gotten to the point where there are many contributors who have never met each other. Not everybody gets to go to the annual Debian Developers Conference which isn't just a party. It's a place where people get to come together and work with each other and live together and learn a little bit about each other so that the rest of the year they're capable of interacting with each other in much more productive ways. Because they understand a little bit about who that other person is and where they're coming from and what motivates them. Not everybody in the project gets those opportunities. And so we do end up in this interesting situation where there are people who sort of have fundamental agreements. Even if they agree on some of the core values of the project, they don't always agree on how they should most productively interact with each other. This is something that's very hard to retrofit as a change after the fact. We've been talking for years now about should Debian also have a social committee in addition to a technical committee. We have, you know, user policies for our machines because those are physical resources that it makes sense for us to have some explicit code of behavior associated with the use of. But how would we today go back and retrofit into the Debian community some kind of a code of interpersonal communications conduct? It's just not clear. It's very hard to do. And as a consequence, I think the external view of Debian sometimes is accurate that there is this tyranny of a vocal minority. A small group of people who, you know, are willing to write the same opinion a thousand times in one email thread end up drowning out the voices of many other people on the project. I think this is unfortunate. It does mean that you have to sort of stop and pause every once in a while and think about the difference between the perception you're getting from reading the mailing list and the perception you would get if you were only watching the list of uploaded packages and the technical changes that are constantly being made in the distribution. So where are we going? What's the future of the project look like? Well I told the release managers a few weeks ago when I finally sort of had it sink into my brain that I was supposed to come to FOSDM and do a keynote about Debian that I was completely happy to announce the staple release of Lenny today. And I got exactly the reaction that you just gave me. A polite chuckle. I'm told it's really close. The last time I looked it was very, very close. I think beyond, you know, more things like Lenny happening you really shouldn't expect radical change because after all it isn't needed. The project's actually working very well. I think the Debian community is very strong. It's interesting that when you have an all volunteer project and you have lots and lots of different commercial entities around the world each donating physical resources and bandwidth for different reasons in different places around the world we're actually really well structured to ride through this whole economic downturn. In fact I think some people as they have less paying work to do while spending more hours contributing to Debian. I think that's nice. I feel sorry for anybody who all of a sudden finds themselves without an income. But in this kind of an economic downturn almost anything can happen. It's also interesting to me that the project continues to attract new contributors at a really significant rate. Not long back we added this new category of contributor called the Debian maintainer. And I'm kind of intrigued at the slope of the curve. It reminds me a lot of what the Debian developer signup curve looked like in the early years of the project. And these are people that are doing really useful work for the project. They're people who are in effect manage maintaining one or more packages on behalf of the project. They just don't have the right to tweak and change anything in the distribution that a fully registered Debian developer has. And I thought this was really interesting too. I actually stumbled over this yesterday when I was looking for the current status of the Debian maintainer stuff. This is a defect density plot showing the number of open bugs against packages being maintained by Debian maintainers. The interesting thing is I haven't actually seen the same plot for full Debian developers, but I bet it doesn't look much different. I don't think these are less capable, less qualified, or less useful contributors. They're just smart enough to realize that they don't have to go through the whole new maintainer hazing process to be able to do useful work. They also have recently been a couple changes to the technical committee. I won't spend much time on this. Anthony Towns resigned from the committee after several years of substantial contribution, and we chose to add Russ Albury and Don Armstrong. There are two new members of the tech committee. They're both very talented guys and have already participated quite a bit in discussions there. We're having some discussions about possible changes in the working policies within the committee. A lot of that happens outside of the project, but I think it's a sign of continued health and stability within the community. I really hope that we'll be announcing a new secretary soon. Actually, Steve McIntyre, our current Debian project leader, and I, as the constitution requires, have been through the process and have decided who this will be. We've also decided that life would just be simpler if we got Lenny out the door before we made the announcement. Expect to hear the announcement of a new Debian project secretary very soon, much to my relief. I've talked before in public a bunch of times about how HP contributes to the project. I wanted to point out that there are a bunch of ways that we use Debian and a bunch of ways we've contributed to the larger community over time, and really fundamentally it's just a great way for HP to stay connected with the free software community, and we use Debian in an awful lot of things that come out from HP. The ways you can help the project really haven't changed. So many of you are already contributing in one way or another from the show of hands I saw earlier that I won't dwell on this either. But if you're capable, committed, and want to maintain packages or do other work on behalf of the project, we would love to have your help. Finally, this is a quote that I use all the time when I'm giving talks. It's, I think one of the more significant observations over the time that I've been thinking about this from Margaret Mead never doubt that a small group of thoughtful committed citizens can change the world because indeed it's the only thing that ever has. With that I'll thank you for your time and attention, and I'll be happy to take questions. So if you've got questions raise your hand, Alistair's got a mic. Couple folks down here. Are your rockets Debian powered? The rockets themselves are not Debian powered. However, the avionics stuff that we fly on them is on the way to becoming fully open source and open hardware. Keith Packard and Carl Worth and I are currently collaborating on some projects. If you go to altosmetrum.org you'll see the current status of our work. All of the design stuff that we're using is running on Debian, but the stuff we're flying the rockets is teeny tiny little microcontrollers that even Debian's really not going to work on. Yeah, so over here. Hi, I'm from France and we have a new ministry which called the Ministry of Integration and National Identity. I know it might scare a few people. And these people are using open source servers running Debian. Who does such questionable uses or maybe the fact that the Ministry of Defence in France is mainly using Debian for battle or open control? Who does that mix with the values? Well, I think it's actually very important that we remind ourselves that one of our values is that we think everybody ought to be able to use free software and to use Debian regardless of what they're trying to accomplish. It's a very slippery slope if you start to try and inject a sense of moral issues about other things happening in the world into a discussion of how software should have gone well. And in fact, we ask ourselves the terrorist question from time to time, you know, is this license one that would allow a terrorist to use the software? If not, it fails the Debian free software guidelines. It's a kind of strange way to think about it, but the problem is if we allow the political scheme to define sort of what's good and what's bad then we all have the potential of ending up on the wrong side of that definition at some point and that's just not acceptable. Another question somewhere? Up there somewhere? Yeah, go ahead. Hello, first I'm very happy to meet someone who made Debian to be such a successful project, so thank you. There are lots of people here that you should thank for that, not just me, but yeah. My question is what is your relationship with the Ubuntu project and did Ubuntu change your internal philosophy or way of working in the Debian project? You know, it's an interesting question. The way you ask it is particularly interesting because no, I don't think the existence of Ubuntu really changed any of Debian's core values or the way that we work inside the project. My personal impression is that the relationship between Debian and all of its derivative distributions is generally good, but a situation where various details go in one direction or the other at any given time there have been some spectacular examples of places where someone maintaining a package in Debian and someone working on that package in Ubuntu have had differences of opinion about the right way to do something and in some cases, over time one of them has come to understand the other's position better and has changed their mind, in some cases not so much but there are an awful lot more places including, you know, in my own personal experience where it works in Ubuntu or in Xandras or in Mepis when it was a going thing various other derivative distributions have come and said, we thought about this, we think there's this other thing you could do in this package that would enable another kind of use of your software that you haven't thought about and have offered up patches and those patches have been belieffully incorporated and have become part of Debian so I think the thing that's changed if anything is how we think about sort of the Debian community and the size of that community I've used the analogy that if you think about Debian as being sort of a town you know there's now all sorts of suburbs sprawling out around the town and we have to make sure the center of the city is sort of lively and active where the core dies out and we go through the whole mess that lots of cities around the world have gone through but in the main I think the relationship between Debian and most of its derivatives has been really quite positive over the years the whole experience for everybody that they exist and do what they do Other questions? I can't see where folks are sorry I have to just jump up Oh here we go I work on the project upstream from Debian you repackage our software only the way you repackage it is sufficiently different from what we do and what we document that users can get pretty much confused they read out documentation using Debian and it doesn't correspond to what they see or vice versa that makes for quite a support nightmare of what they do and ok there are arguments that say your way of doing it is better there are arguments that say ours is but my suggestion is when you do this I know you do without various packages I think your developers at least get involved upstream make the case and perhaps come to something more unified I think the difficulty anytime you have a project that is as large as Debian with so many pieces of software packaged by so many individuals is that you get a huge range of behaviors and relationship styles and so forth I personally have worked very very hard over the years particularly with some of my counterparts in the Free Software Foundation to ensure that the versions of the packages that I'm building of some of their software that go into Debian are as close as possible to the upstream versions as they can be because I have that same issue and same concern there are a number of other places that I think are very well publicized and documented where that hasn't happened sometimes it's been because there have been fundamental technical disagreements about how software should work in a distributed environment versus generality that an upstream wants to include sometimes the motivations or reasons for those differences have not been nearly as noble and at the end of the day I think I certainly have this opinion that Debian ought to either be shipping software that's as close as possible to what the upstreams are doing or that we should be engaging with the upstreams to understand why not and to come to clearly understood agreements about why is our stuff going to be different and should it have a different name because it's different or what's the right way to accommodate that you know there's no one size fits all answer unfortunately yeah it's about will the future show new kernels to run all the cool apps on like what about hard kernel or opens large kernel running under Debian Debian is interesting because we have already got communities within the project working on the use of the BSD kernel and the use of the herd with Debian user space packages. There have been lots of folks looking at combining Debian user space and open Solaris kernel and libraries there are licensing concerns in that particular case that I don't pretend to be the ultimate authority on but my sense is that it's perfectly okay for people to take the Debian packages all of the Debian user space and combine it in any way that the legal sort of interpretation of the licenses allow with other kernels and if they end up building really useful results for themselves and others out of that that's great I have to personally admit that at the end of the day I'm not sure why the world really needs so many different kernels that differ in such small ways now somebody comes up with a radically way of thinking about structuring software that's cool but a bunch of kernels that all do pretty much the same thing with tiny little differences I don't get very excited about I think we're getting close to the end of our time are there any more questions? I think we'll wrap it up I know a lot of people are getting ready I will be around the rest of the weekend feel free to try and spot me I don't hide very easily thank you very much for your time