So, good morning. Out of curiosity, how many of you have never heard me give a talk at any other kind of event? Well, 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 FOSNAM 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 happen to also be my friends. And they asked me,

Beadle, why do you never come to FOSNAM? 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 FOSNAM works. And I said, 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. So who am I exactly? Okay, I tell people that I made my first personal contribution of source code to this thing we now call free software in about 1979.

It was 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 in 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 met Steve yesterday, and I know Martin Nicklemyre is 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 gonna be checking your facts.

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, Napix, Xandros, one or 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 gonna 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. 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. And 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, you know, things like Estes model rockets, the little ones as kids and stuff?

A few, yeah. Many of us did at certain points in history. Well, that's my son Robert, and he and I now play with, you know, 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 weeks ago in the fundraising auction to raise money

to help try and cure the seemingly disastrous disease afflicting the Tasmanian devil population, and I somehow in the middle of the conference banquet agreed to let Lena 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 gonna 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, ask 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. I, yeah, 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. 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 sort of physical, real, practical sense of what Debian's product is in the form of a GNU-Linux distribution that I think is unarguably one of the more interesting software platforms on 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 this 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 merrily 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 in our 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 a 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 in 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 GNU Manifesto. It was written by Ian Murdock, who was the original founder of the Debian project. And 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 0.93 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 95 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 change log 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? Obviously, that worked well for small distribution but would have been an incredibly unwieldy process as the project continued to grow. So we had this concept of explicit package maintainers and that's when dpackage showed up for the first time.

By the time we got to later that year, you noticed the release cycle in 1995, it's a little different than it is today. But by the time we 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 who had 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. But 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 SunSite, which was one of the major redistribution sites in 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.

I have the privilege of participating as 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 a beer or something, I was gonna say beat each other over the head, but that wouldn't be appropriate. I'd strongly suggest going by and taking advantage of that opportunity today. And then the sort of 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 floodgates really opened. Once we had figured out how to support more than one architecture, folks like me got excited.

And over history, there were five different ports. There's the, 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 money. So I talked about the WNNX 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 Debian 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. Slackware, yeah. Early Slackware, SLS. Red Hat actually got started almost at a, you know, the RPM packaging system and the Debian packaging system

sort of grew up in parallel. Debian 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 Debian project leader tried to convince the folks at Red Hat

that they should abandon RPM and switch to Deb. And they actually thought about it seriously and then came back and said, well, actually, we've sort of already done a lot of work with this, and we don't really wanna change. 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 Debian was being carefully and conscientiously put together and would be maintained and supported with similar care is 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 do 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 software. That's why things like the recent general resolution end up being so contentious. We all believe this, we all want this, and 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 as being strong enough and steadfastly 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 the little pieces of code that is buried in everybody's X system these days, the GLX stuff, and 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 CEN 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 long-standing issue with the Sun RPC 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 they 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 degree of 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 Murdock 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, you know, there was a fairly informal process where he looked around and talked to Bruce Perrons

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 wanna 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 Murdock 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 oughta be. And even more than that, we oughta 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 gonna 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's 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 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 stable 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 Condorcet 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 promise 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 last beer-less, 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 POMed, 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 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'd 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? And 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's 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 I would 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 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 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 FOSDEM and do a keynote about Debian that I would be 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 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 were 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, may find themselves 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 a 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 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 the 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. There also have recently been a couple changes in the technical committee. I won't spend much time on this. Anthony Townes resigned from the committee after several years of substantial contribution.

And we chose to add Wes 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 doesn't matter to anybody outside of the project,

but I think it's a sign of continued health and stability within the community. And 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. So 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. 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.

All your rockets are 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 Wirth and I are currently collaborating on some projects. If you go to altusmetrum.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 fly on the rockets is teeny-tiny little microcontrollers that even Debian's really not gonna work on. Yes, over here. Hi, I'm from France, and we have a new industry

which called the Ministry of Immigration and National Identity. I know it might scare a few people. And these people are using open source servers to running Debian. How does such questionable reasons, or maybe the fact that the Ministry of Defense

is mainly using Debian for battle and open control, how 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 be licensed. It's never gone well. And in fact, we ask ourselves the terrorist question from time to time. 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 for that. 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 that 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 in my own personal experience, where folks in Ubuntu or in Xandris or in Mepas, 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 the Debian community and the size of that community. I've used the analogy that if you think about Debian as being a town, there's now all sorts of suburbs

sprawling out around the town, and we have to make sure the center of the city is lively and active or 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.

I think it enhances 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 and, oh, here we go. I work on a 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. Yet they read our documentation using Debian and it doesn't correspond to what they see or vice versa. That makes for quite a support nightmare what they do.

Okay, there are arguments that say your way of doing it is better than there are arguments that say ours is, but yeah. My suggestion is when you do this, I know you do without various packages,

shouldn't 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's 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 the 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 gonna 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 Epson? Like, what about hard kernel or open source kernel running on the Debian? Well, I mean, Debian's interesting because we have already got communities within the project working on the use of the BSD kernel

and the use of the Hurd with Debian user space packages. There've 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, instead of 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, if somebody comes up with a radically different 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. There any more questions, though? Yeah, I think we'll wrap it up there and 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, so thank you very much for your time.