 My benefit, how many of you are Debian developers? How many of you are Debian users? That's very cool. The more interesting inverse question, I guess, is how many of you are not Debian users yet? That's cool. It's OK to admit it. I mean, that's the whole point of today, right? I mean, if all of you are already huge Debian fanatics, then having a Debian day where we talk about the project and how it works and all is less interesting. That's right. There are some who are, hmm, well, let's not go there. So what I want to talk today about is, I was asked actually to talk about a topic that's near and dear to my heart, which is the relationship between the Hewlett-Packard company and the Debian project. This is something that I have been sort of in the center of or acting as part of the connection for for quite a while. Who am I and why am I here to talk about this? Well, I've been around for a while. I made my first contribution to what we now call the Free Software Community sometime around 1979. It was a little piece of assembly language for a long, forgotten, strange little microprocessor board that got published in a newsletter in Canada. I discovered UNIX when I arrived in Pittsburgh to attend Carnegie Mellon University in 1982. That was the era of Berkeley 4.1 running on vaccine. There seemed to be a thing at CMU at the time that if you started a new research project, you'd get a grant and buy a VAX. And so they were all over the place. So I'd done all sorts of interesting computer related things for a long time before I discovered Linux and in particular the Debian project. That happened sometime around 1995. My real focus over the years has been on software portability within the Debian project. I had a lot to do with getting the ports for alpha and spark and arm. And more recently, HPPA, or PA risk as it's called, and IA64, which is the architecture for the Itanium processor family, included in the Debian distribution. I've also done some interesting infrastructure things over time. A very long time ago, I built the first master.debian.org and sort of squirreled it away on an HP network for a while without anybody really knowing about it. And there have been some other major things that have happened in the Debian project over time from the implementation of package pools and more recently, the custom Debian distribution work, which I used to call creating flavors of Debian. There are things I've contributed ideas to. I served as Debian project leader for a year. And I'm one of the participants in this thing that we're trying as an experiment this time around called the DPL team. In fact, I guess we have everyone who's participating on that team except Steve Lancasec, present here in Helsinki or on the way. And so you'll have a chance to beat us up in person, if you'd like. I've also been on the board of SPI for a little over a year, I guess, and had served as an advisor to the SPI board for a while before that. For those of you don't know, SPI is the nonprofit corporation that's organized in the United States to act as the financial and legal umbrella for Debian and some other interesting open source projects. From the HP side, I've been an employee of HP or it's spinoff Agilent technology since 1986, though for a very long time I worked in the older test and measurement part of HP. And it wasn't until I was invited to leave Agilent and go back to work for HP in 2001 that I actually started working on Linux related things as part of my official day job. And for the last couple of years, I've been serving as the chief technology officer for all of HP's open source and Linux activities. In that capacity, I report to a vice president whose title is HP VP Linux, among other things. So what I want to do today, well, HP was one of Debian's earliest and I think remains one of Debian's strongest corporate sponsors. And what I really want to talk about is what HP gets in return for that. There are a few other things that I'll pick up along the way. It's impossible to talk about this without talking a little bit about HP and the whole concept of community development and how we think about that and how we try to participate. I'll tell you this sort of funny story or the interesting sequence of events that led to HP having sort of a significant development relationship with Debian. Talk a little bit about some of the things that's enabled in some of the ongoing activities. Now if you go to HP marketing pitches about Linux, this is one of the sort of cute standard slides that gets thrown up. We have this whole marketing motto thing about delivering open source and Linux for the real world. And if you look at this, there's all sorts of things that get wrapped up in that. And some of them matter to those of you that are doing Debian things and some don't. The part that I really focus on a lot is this middle pinkish kind of box where we talk about a commitment to open industry standards, not proprietary architectures, maximizing the value of vendor and partner independence. And this notion of trying to have a leadership role in the open source community to help preserve the freedom of Linux in the long term. And this is something that our marketing guys happily put up in front of real customers all the time. So it's not just when BDL goes and wave slides around. This is a strategy that seems to be working pretty well. This is my only other quote unquote marketing slide that I'll throw at you. While some of our competitors talk a lot about Linux and talk about how much money they spend trying to contribute to and support Linux from a business standpoint, we're actually very happy with the results we've seen. And when we talk about the Linux attributable revenue that HP is receiving as a consequence of our participation in Debian and the larger open source Linux community, we're talking about numbers in the range of multiple billions of dollars per year. And yes, that's billions with a B. So this is big business now. It's not a hobby anymore, if it ever was, for a company like HP. And I think it's important to understand that so that when you think about the things that we do and the ways that we try to contribute, you understand that this really is, from a corporate perspective, all about generating value for our shareholders. But I don't think that that's incompatible in any kind of way with doing the right things in the open source space as well. So how do we get there? Well, we have this R&D approach that says that we really need to embrace Linux for what it is, a disruptive technology. When I say disruptive, what I mean is that I don't think there's a single business plan for any of the businesses that make up the Hewlett-Packard company that doesn't have the word Linux in it somewhere. If you're building printers or other peripheral devices, you have to care about Linux device drivers and you have to have a strategy for how you're either going to deliver those or explain why you're not delivering them. If you're building any kind of computer these days, some customer somewhere is going to ask you what your Linux support strategy is. Doesn't matter whether it's a good strategy or a bad strategy, you better be conscious about it and know what the answers are. And just across the board, there are places where we're embedding Linux technology in products. There are a couple of hundred products that HP ships today that have Linux and then the people buying them don't know have Linux and then it's just part of delivering value to our consumers. And in terms of the implications that this has for our R&D operations, you have to be careful not to presuppose that you know what the ultimate answers are because we don't. We need to participate in and contribute to this ongoing evolutionary process and sort of ride along with what is happening in this space. We try to contribute in places that are going to make some kind of business difference or benefit for the company, but in the process, do this by participating as a real citizen of the community consistent with the community's values and behaviors to deliver enterprise capabilities that matter to HP and HP's customers. And in the process, work with various Linux distributions including Debian and various software vendors to deliver solutions that our customers will be excited about and be willing to give us huge amounts of money for. So it's popular when you start talking about the relationship between large corporate participants and the general open source community to raise all sorts of questions about is this a good thing and is this going to generate some kind of an uneven influence and so forth. The perspective that I have on it is that I think large companies can make important and valuable contributions to the open source community, but we have to be conscious of the fact that there are often conflicting expectations. As I've already mentioned, the first priority of a corporation is profit. It's all about generating return on the investments made by your shareholders when you're a public corporation. You may have a set of corporate values as HP does that includes community citizenship and various other well-meaning things. And those are all part of running a sort of morally acceptable corporation in the modern world, but all of those things have to be done in the context of good fiscal behavior on the part of the company on behalf of its shareholders. At the same time, the open source community is really focused on freedom. It's all about freedom, stupid. And this can sometimes lead to an interesting set of conflicts. For a successful partnership to occur, the corporation has to behave as a good citizen. It has to play by all the rules. It can't cut corners on license compliance. It can't take all the time without giving and all of those sorts of things. But at the same time, for corporate participation in this model to be successful, the community also has to figure out how to appreciate and incorporate the contributions that are being made by these corporate participants. If the corporations are behaving as good citizens and participating in the level playing field and the sort of development commons that exists in the community development model, that's not nearly as hard as it sounds. Because if the company is behaving as a good citizen, then the things that it's doing are things that the community is probably going to be appreciative of anyway. And one of the things that I spent a lot of time talking about is this notion that even once we get to the point where the kernel really does all of the things that most users expect, and a Linux desktop kind of scratches all the itches that the average user has, it's going to continue to be important for us to participate in and to help to foster this community development model. Because this is where all the goodness and where all the cool innovation is coming from. So I talked a little bit about ways that conflicts can arise. Some of them are really obvious. Some of them might not be, if you haven't thought about this a lot, schedule predictability is, quite frankly, a really big deal. It's something that gets talked about a lot when you start working with the Devian project, of course, because we've had a very strong opinion for a very long time that will release it when it's ready, not according to some specific schedule. I'm one of the people that for quite a while has been suggesting that there ought to be some way to balance this a little bit. We certainly don't want to release the bread before it's baked, but we ought to be able to predict how long it's going to take to cook with a little better accuracy than we've done in the past. It is true, though, that volunteers are generally less predictable than paid developers. You don't have the ability to crack the whip and say, dude, you need to work harder or we'll get somebody to replace you. And there's an interesting set of social dynamics that occur when a volunteer contributor isn't meeting some set of expectations that those around them have built up based on their prior behavior that causes us to not be very effective about replacing people that have become inactive even when it's pretty clear that there's some kind of a problem going on. But I think it's also important to realize that predictability is really more important than some specific interval. It's not that a release needs to happen in every certain number of months in order for things to work right. It's that when a company is making development investment decisions, they need to have some idea what the thing is that they're going to be working against when they're going through that financial planning process. There are all sorts of interesting things that happen from a supportability standpoint. And I describe this as the difference between obligations and dedication or differently, the difference between having contracts or relying on reputations and prestige and so forth. If you think about this, one of the sort of traditional models of behavior in the information technology community is to want to have support contracts even if they cost a lot of money so that when there's some kind of problem, there's somebody else that you can point to. There's somebody else that you can punt the problem to. In effect, what you're paying for is somebody else to be responsible, to take the blame, to fix the problem, whatever ends up needing to be done to make things right in the end. And that's an expectation that isn't always easy to meet when we're talking about a pure open source community kind of project. So one of the challenges that I think the corporate participants in open source development community projects in general face is figuring out how to wrap their brains around how this stuff really works. And if they want to participate as good citizens in the development process to not have expectations that aren't realistic in the context in which they're participating. And then the ugly D word documentation, it's always a challenge. In this particular place, it's less about whether individual pieces of software are well documented or not, though that's always an issue. It's really more about whether the processes and the ways that you can participate and take advantage of the work that's being done by the community are well documented. Debian is actually, for all of our desire to be an open and collaborative development project, there are lots of important processes about how things happen in Debian that are sort of tied up in folklore and the comments and the scripts and things like this. That's not necessarily a bad thing, but it does pose a challenge when someone in a corporate environment is trying to figure out whether that's a piece of technology they can take and make use of for creating a custom derivative or something like this. So these are all things that come up in one context or another. And from a control standpoint, one of the conversations I get to have a lot is with people who think that it would be okay for us to do something that's a little bit different and it's okay because it's open source and we'll support it. And it just demonstrates a complete lack of understanding of the cost of ongoing support of stuff that isn't standard. And this comes up, you know, everything from binary device driver modules. We in HP really hate them. They're really expensive for us to support and maintain. Every time somebody changes a kernel, having to go chase our vendors to get updated module builds and all this kind of stuff is just as frustrating for us, times in customers as it is for each of you trying to keep your individual machines working. And at the other end of the spectrum, there's always interesting questions that get raised about, oh, there's this market opportunity over here. If we were just willing to add this extra thing to the kernel, maybe we could sell a bunch more stuff to this particular set of customers. And I will show you a little later that one of the things that Debian has done for HP is it's made it possible for us to chase a couple of those business opportunities when they appear to be lucrative enough. But these are all things you have to think about and trade off and that can become potential areas of conflict. A couple others that are things that, intellectual property issues, I think get a lot of press, but sometimes it's more heat and light than reason. The big issues here, honestly, are to make sure that corporate software developers understand the obligations that are part of being a good citizen of the open source development community, particularly when they're building products or overall solutions that might incorporate both proprietary and open source content. HP has this thing that we call an open source review board, which has a set of processes so that anyone engaging in developing a product in the company where there's gonna be any kind of contact between proprietary and open source software is expected to run that project through the set of approval processes that we have where things get reviewed by people with business, legal, and community concerns to make sure that we're doing the right thing and behaving as a good citizen. And in the end, I'm actually very happy with the results that have come out of that, but there are a lot of people inside the company that get frustrated when something they think they ought to be able to do doesn't really comply with the terms of the licenses of the software that they're looking at and they have to go through a learning process and figure out how to deal with that. Another thing that can be interesting in the corporate environment is if you choose to make non-trivial contributions to existing projects that are GPL licensed and happen to be projects that are associated with the FSF or other groups that have this expectation, you can find yourself needing to go through assignment of rights paperwork where you say, not only are we doing this in the context of the GPL, but we explicitly assign our rights and this over to the primary copyright holder. It's not a big deal, but it's something that corporate lawyers have to learn how to deal with. The whole patent thing, I'm not even trying to talk about that, we don't have enough hours in today, but it's a thorny problem, it's a situation that I'll be happy to talk about some other time this week. And then one thing that is sort of interesting is, and this comes up in the purely Debian context as well, is that anytime you start talking about funding development, there's an interesting set of pressures that get applied, in particular when there are boundaries between people that are and are not getting paid to participate in the same project. One of the things that we've discovered in HP is that we're most successful when we do a combination of trying to hire some existing open source developers that are knowledgeable or participating in some project. And at the same time, encouraging some of our current employees to join those same development communities if they're gonna be working on that particular stuff, there are a significant number of HP employees who are now fully registered Debian developers and some of them are doing really interesting stuff, which is a very pleasant consequence of this ongoing relationship. So I've talked about some of the conflicts, what are the benefits, what do you really get out of this? Well, companies really benefit the most from participating with Debian and other like open source projects from the notion that they can focus on the value that they want to add and that their customers are willing to pay for and not spend as much time focusing on things that are, quite frankly, purely commoditized. The community gets a benefit from corporate participation in that companies like HP are usually happy to throw resources at projects that matter to them. They often can provide focus and attention that will increase the size of the user space. And one of the things that I've observed personally directly in HP's relationship with Debian is that we submit some mighty fine bug reports from time to time, particularly the ones that come with well thought out solutions that cross the boundaries of user space and kernel and libraries. And if there's a customer at a national lab that's bought a gazillion of our best servers and they have a stability problem and they call us in and we root cause it and figure it out, we're not shy about articulating every detail what we found at everybody upstream. And that really is pretty cool. It can be frustrating sometimes when you see just what's going on under the covers but it's really neat to get high quality bug reports and be able to get those things taken care of. Companies are often willing to fund the unpleasant parts of projects. And a good example on HP was some of the work that needed to be done to get Debian's itanium port up to a sufficiently high level of build completion to be able to be included in the Woody release. We actually spent a lot of money making that happen. And we're very happy to do this because the architecture mattered a lot to us. And we were to the point where I told my boss one day since I've been doing a lot of the work on this myself, gee boss, the problem is everything I care about in Debian works now. So it's time to start paying somebody else to do some of the rest of this. And it's interesting. I've seen many other cases where other companies have said, oh yeah, that piece is ugly, nobody wants to do it. Well, can we just pay somebody to do that and get past that hurdle? It's not an unusual thing to have happen. And then again, the companies can get a benefit sometimes because the community, if they engage in a development activity with partners, whether it's other companies or individuals in the larger open source community, the community at large may choose to adopt and preserve some piece of technology even after the company's interest in it wanes. And this provides a better sort of life cycle arrangement for the customers that have chosen to embark on deployment of that technology than if the company just walked away and said, gee, sorry. So these are all things that I think are positives that come out of all of this. Now let me sort of shift gears a little bit and talk about how HP first got involved with Debian specifically. By a few years ago, folks were sort of looking around in the era of trying to make Linux the kernel, work on more and more stuff. And we all of a sudden realized that PI risk was really the only major 32 bit CPU family that was not running Linux. And for a bunch of us inside old HP, this is frustrating. It was sort of embarrassing, I guess, is the right way to put it. But despite a bunch of discussions inside the company, we really couldn't figure out how to get anything useful done. Part of the problem is that since PA risk mostly only ever ran HPUX as an operating system, there was this propensity for resolving problems that occurred in ASIC development by hacking something into a device driver and never getting around to updating the reference documents that explained how the chip was supposed to work. So without going and looking at HPUX source code, it was very hard to understand how the hardware worked. And if you looked at HPUX source code, you were sort of tainted in going off and doing anything with that in an open source operating system project, posed real conflict of interest in intellectual property problems. Plus, almost all of the people who thought this would be really cool to work on worked in parts of the company where they were pretty sure their bosses would be really mad if they went off and did this. So the thing that finally sort of broke the camel's back is that a bunch of guys in Ottawa, Canada were sitting around one day thinking what would be a cool project that they could go work on for fun that might get them enough visibility and notoriety that somebody important might hire them and they'd all get rich in the end. Well, part of that worked. I don't think any of them have gotten rich. But this group of guys formed this organization called the Puffin Group. And they were doing various consulting work. And one of their fairly high profile projects is that they made a big public announcement that they were going to start a port of Linux to the PRS architecture. And in fact, they showed up at ALS one year and used one of the project incubator facilities that was provided at ALS that year to get a lot of work done. And they had a very thin path of functioning code that did allow them on one specific model of PRS system to get up to a shell prompt. And everybody went, oh, that's so cool. And in effect, they talked to the right people on HP and somebody finally got shamed into saying, it's kind of weird to have somebody other than HP doing this and to look like we don't care and aren't participating. So maybe we should figure out how to participate. And after a bunch of discussions and agreement was reached, we're in HP agreed to make various previously proprietary reference documents related to PA risk architecture available. And further, some HP employees were encouraged, not just allowed, but encouraged to go help this project a little bit. And things kind of started to snowball and mushroom from there. Not long afterwards, the success part for the Puffin guys is that Linux care noticed them and acquired them. And all of a sudden, they were getting paid real money to work on Linux things. The problem is that meant it was no longer just a fund project for them. And all of a sudden, contracts had to be signed to get Linux care to let them keep working on this project and so forth. But after a certain period of time, the kernel was kind of working. We had a tool chain that was pretty reasonable. And everybody looked around and said, well, this would be a whole lot more useful if it were a complete distribution. But there was already this public message that had gone out from HP that itanium was the future and PA risk had a finite lifetime. And so I think quite reasonably, all of the commercial distributions that HP went and talked to that they already had relationships with for providing the Linux support for x86 systems and so forth did a huge ho hum and said, we're not excited about this. We don't see a huge business opportunity. So why don't you pay us huge amounts of money to go do this work? The problem, of course, is that for HP, this was sort of a community involvement project. Let's learn how this open source thing works. Let's do the right thing with respect to the PA risk architecture for Linux. But there were no obvious direct business benefits that would come from this. So there was a real problem coughing up a big chunk of money to a commercial distribution to go and do the work. The good news is there were some people working in and around the guys that were working on the kernel who knew something about Debian. Frankly, they're people that I had managed to taint with the Debian virus before the HP Agilent split. And I got a phone call inviting me to come up to a meeting that was happening in one of the HP facilities at about this time. And I was expecting it to be sort of a hack-fest kind of thing. When I arrived, I got escorted off to a conference room with two or three levels of managers who wanted to ask me all sorts of probing questions about how the Debian project worked and could they do this and could they do that and how would you achieve this and how would you achieve that? And at the end of the day, they decided that the right thing to do is to pursue a Debian distribution port for PA risk. And they sent me home with a really nice PA risk system to set up in my basement and use as an auto builder. And it all sort of snowballed from there. There were a bunch of engineers who in HP who as I said knew Debian and liked it and so it was sort of a natural thing to chase after. When they decided to do this, and this is before they hired me to go back to work for HP. It was when I was still working for Agilent. They decided that if they were gonna do this, they wanted to do it right for some value of right. And in particular, they didn't want this to be some sort of a fork. They didn't want to go grab a snapshot of Debian, hack on it to make it work on PA risk, put it up on a website somewhere and say see look what a great thing we did. Instead, they really wanted to figure out how to participate in the project and make a real Debian HPPA port happen for the next stable release. And that is in effect what ended up happening. HP chose to continue the contract with Linux care for a while because that's where the cool tool chain guys were at the time. They hired some existing Debian developers and added them to this gradually starting to build thing called the Linux systems operation which has changed its name a bunch over the years and is now the core of what we call our open source and Linux organization R&D lab, Oslo R&D for the the acronymically inclined. Also a bunch of HP engineers who are working in and around this PA risk Linux team were encouraged if they weren't already to go become Debian developers. And there was in fact a little flurry of activity in that regard enough so that our dam at the time accused me of trying to get the value of Q entirely within HP. Those of you who understand how our constitutions are written understand that if you have Q developers you can propose things and have a majority in meetings and all sorts of interesting things. And I acted surprised because it never occurred to me that HP would ever get so involved with Debian that that would matter to us but maybe it'll happen someday. But at the end of the day, a lot of interesting work got done, a useful distribution for PA risk systems did result and even though HP never figured out how to sell it to anybody, a lot of HP customers really appreciated the company's participation in and sponsorship of that community oriented project. And it allowed HP to learn a hell of a lot about how the open source community works, how to make things happen when you're not putting lots of money on the table. And at the end of the day, I think this helped to establish the pattern of behaviors that has carried forward until today. This led to the use of Debian or some of the itanium enablement work in that same R&D lab. And there's lots of development work in various parts of HP including HP labs that gets done on Debian boxes. So I pulled this out of an old slide deck and it's not entirely current, but this is I think probably the closest I have to something I can throw up that talks about how HP thinks about the Debian project. What it's really all about is this notion that we want to be able to deliver open source functionality to our customers even when that functionality isn't necessarily available yet in commercial distributions. This slide is from the era when we were pushing hard to get the initial releases of some of our itanium two based servers out and customers who wanted to do early software development on those systems under Linux had a hard time because the commercial distributions which most of them told us they really wanted to run in the end hadn't made very useful releases yet of their distributions for that architecture. And so there was a sort of time to market issue where we had things that we had made work that were sort of asynchronous with the release schedules for the commercial distributions. And if we wanted to help customers succeed in doing Linux related development work in that time window between when we made things work and when they would show up in a commercial distribution we needed some way to do that. When we talk about delivering open source functionality HP continues to really not be interested in developing or delivering or maintaining our own distribution or trying to create a competitor to the existing commercial distributions. Quite the contrary we work very strongly with the leading commercial distributions and in fact when we go to market with customers in enterprise spaces we go to market with those distributions pretty regularly and we have very strong development business relationships with them but we are interested in delivering valuable open source functionality that's desired by our customers whether commercial distributions are prepared to do that or not. So this really sort of leads us into this situation where we find ourselves using Debian often to deliver things that are either not yet available or unlikely to become available from our commercial distribution partners. And participation in Debian has really become a primary vehicle for HP to be directly involved in the larger open source and Linux development community to try and influence areas that are important to the company. And this happens because Debian is such a wonderful proxy for the larger open source community. It's a big enough project that and it incorporates enough software in the Debian packaging and distribution system that almost anything that you might need to hack on to make some new system that we wanna ship work is either something where Debian already has a relationship with an upstream maintainer that we can sort of take advantage of by working through the Debian bug tracking system and related mechanisms to get changes pushed up or it can just provide a good way for us to try things out before we go try to push them into further up streams with X or the kernel or whatever. So some of the results that we've seen from this, Debian Woody was actually the first Linux distribution that supported HP Zytanium II systems based on HP ZX1 chipset in a stable release. This was one of those funny things that happened just because we agreed that it was okay to include the IA64 port in the Woody release and the timing of the Woody release was after we got things pretty much all working and before any of the commercial distributors had done another stable release. So it's not sort of all that hugely significant but it's one of those funny little facts of history that I don't mind pointing out when I'm talking about cool things that have happened in our relationship with Debian. It is interesting though because it was an occurrence of something that we now are not sure we would wanna support from the Debian side again in the future in that we shipped something in a stable release where you couldn't actually buy the hardware to run that binary architecture yet. So, all a little strange. But then one of the other interesting things that happened again because there was this time window where we had Debian bits available and the commercial distributions hadn't given us stable releases where because of the rules that the spec benchmarking folks have, you can't submit a spec benchmark using a software recipe that a customer can't reproduce. So in other words, if you want to publish a spec benchmark, there is a time window in which you have to commit that all of the bits that were required to make that work will be available in sort of the normal ways. Unfortunately, that time window meant that if we wanted to use a commercial Linux distribution we would have had to have waited some number of weeks perhaps months before we could publish benchmarks after the hardware was ready to be benchmarked and that was something that we didn't wanna do. So the initial benchmarking that we did for our fastest early IITANium II systems was done using Debian and a custom kernel which allowed us to have a recipe that was easy to duplicate because that custom kernel since I was the IA64 kernel maintainer for Debian at the time became the stock Debian kernel for the woody release. And at the end of the day, it actually all worked very well. We published some industry record making benchmarks and the marketing guys were reasonably happy. And it is true that several months later when we had a commercial distribution to use for the next round of the benchmarks the numbers were even better. But that isn't so much because the distribution per se was better. It's because a few months had gone by, the tool chain had gotten improved, the kernel was faster and all of those things. Nonetheless, this gave us several months of opportunity to go brag about our new hardware before we otherwise would have been able to. Another interesting little thing is that every HP IITANium system that has shipped to a customer that said Linux was going to be their primary operating system has gone out with a CD dropped in the box called the HP Enablement Kit for Linux on IITANium systems or something like that. That's actually a thinly disguised woody installer CD that's had the charoute blown up to a massive size since you can get away with that on IITANium systems. And lots of extra tools put in and one extra level of menu that allows you to choose some optional behaviors that aren't normally part of a Debian install like restoring a factory preconfigured system image from another unit of media, initiating a system imager network installation from a golden image server and things like that. And it's actually been fairly helpful to some of our customers, though I admit it's long on the tooth and no longer nearly as relevant as it once was. And there are a bunch of other examples of where new hardware that we were ready to ship that we did not at the time have commercial distribution support for went out with Debian Bits as the Linux that was available for it for some period of time before commercial distributions became available. And probably the most interesting example that I can talk about in public is that HP continues to sell a carrier grade Linux solution for our telecommunications customers that's based on Debian with a custom kernel and some custom protocol support that runs on top of especially Neb's compliant modified version of one of our two-way IITANium systems. The customer that came to us and, is that readable? Okay, good. I was a little worried that putting this much text on would make it totally unreadable. It's not my normal style, but I snatched this out of another presentation and actually blew it up much larger than it was before. So I guess it worked. At the time that the customer in question came to talk to us, Red Hat and Suza didn't meet their requirements either for features or schedule or support model because what the Telco customer that motivated us to do this work really wanted to do was for us to deliver them a piece of infrastructure that would consist of hardware and an operating system and some HP value-added components that come from our Telco software people, which they would then layer their own proprietary Telco software stuff on top of and sell to other customers who were the ultimate people who would go deploy this stuff. And once these machines were deployed, they wanted five and 10-year support life for things that we were not accustomed to supporting that long and so on and so forth. And it just was sort of, a business model was different than anybody in the Linux commercial distribution space was willing to chase at that time. We realized that there was an opportunity to sell a lot, a capital L lot of itanium servers if we did this. And so we agreed to do the work and figured out how to meet this customer's needs with a Debian-based solution. I'm not gonna go through all this detail, but there were some interesting experiences that came out of that. We figured out all sorts of things that we could do with relatively modest patching of the kernel and adding a couple of additional packages to the Debian system. One of the interesting examples is this OSPF routing support where gate D for a long time was the demon that people used for implementing OSPF on Unix-like systems, but support for it on Linux had basically been abandoned. And it wasn't clear what the answer was. We shoveled around some and found this other package and helped to motivate the activity which led to it being included in the Debian main distribution. That turns out it meets the customer's need and they're quite happy with it. So this is another example of sort of where there was a cooperative effort that in the end added a capability to Debian that anybody can go use, but it happened to meet the needs of this particular customer. And so it was a valuable thing for us to fund the work on. Another example that I love to talk about when I'm in places where I can talk about it and not have people look at me sort of funny is that there's an R&D lab that does IC design for the chip sets that go around processor chips in our servers and workstations that was faced a year and a half or so ago with the fact that they had almost all of their stuff running on PA risk systems and PA risk systems were rapidly approaching end of life. So they wanted to move to 64 bits. They wanted to, in effect, upgrade their infrastructure and replace a lot of stuff. In the end, what they decided to do without any real urging or encouragement for me or the rest of the internal Linux community was to go basically by a lot of x86-ish systems and some Itanium systems and run Debian on all of them. And this has done some really cool things for them. They've gotten faster machines just because it's newer hardware with higher clock rates and all those things that happen when you replace old boxes with new ones. But they've also been really excited about the productivity they get from running Linux instead of HPX as the operating system because now they have access to things like open office and VMware and so forth that work on x86 boxes running Linux that don't work on PA risk systems and so forth. And in the end, it's of course lowered their total cost of ownership. And it's interesting that they actually went through a pretty serious evaluation before they decided to do this. There are some things that helped them to make this decision and to be successful making this decision. One of them is that they have their own dedicated support organization that is full of long time Unix geeks who thought figuring out Linux was no big deal. And they were willing to do things that a lot of customers don't have the ability to do which is why you don't see me hawking this as a solution for HP general customers. In particular, they were willing to go buy large numbers of licenses to expensive IC design tools that were officially only supported on Red Hat and figure out how to make them work on Debian and at the end of the day, feel okay about running them that way. A lot of customers just don't know how to feel good about running things that are that far from being officially supported. But the bottom line is there are now a couple of major R&D organizations inside HP that are running effectively on a percent on Debian not just on Linux. I think that's pretty cool. So I've talked a lot about sort of how HP benefits from all this and a little bit in general about how the community benefits from corporate participation. Here are a few things that I wanted to throw out to mention in passing that I think are interesting things where HP sort of contributed to Debian's overall benefit and evolution. First of all, we've done it at a lot of hardware. Frankly, I have no idea how much hardware we've done it but there are a lot of Debian.org servers running on HP hardware these days. I was amused actually in Brandon's latest DPL report, one of the requirements that our SysAdmin guys had was that they needed to be able to plug the ILO in and ILO's an HP term for integrated lights out which is the remote management interface for our servers. So obviously they've gotten really used to having remote manageability stuff that works right and I think that's very cool. And I'm pleased that Debian's running on the finest iron. We also host some of those servers particularly in our Fort Collins facility and we provide a fair amount of network bandwidth. I haven't paid attention recently to what the reports look like but we're hosting one of the mirrors that's in the top level U.S. rotation and it gets beat on pretty hard as well as some other development boxes. As I've already mentioned, HP directly sponsored a lot of the work on the PA risk and ITANI imports and continues to pay some passing respect to those though those have now become fully community involved and supported activities. One cute little thing that I'm sort of proud of because a couple of us in Colorado helped to make it happen was that HP funded the legal opinion that was required to allow our FTP masters to feel good about putting crypto into the U.S. main archive and that substantially reduced the complexity of having it possible to have a Debian installation include good crypto from the get go. It's also something that I don't think a lot of people realize that all of the work that's been done to support Linux on IPACs and related handheld devices that's represented by the HP sponsored handhelds.org website is actually done with Debian derivative distributions. There are two different distributions for the IPAC for example called Familiar and Intimate and both of them are derived from Debian to varying degrees. Yeah, you have to know the right sci-fi to understand where those terms come from but there are a whole bunch of development projects as I've mentioned some of which I can talk about else when during this week and some of which I can't where in the end they're gonna directly or indirectly benefit the Debian project as a result of what HP's working on. So a few parting words HP really is steadfastly committed to open source and Linux when we talk about our OS strategy for the future we talk about sort of a three OS thing because we do see a fairly long lifetime for HPX we don't see it going away anytime soon and it's still generating a very pleasant return on our investment. We see lots of Windows stuff, it's unavoidable and we make a lot of money from selling a lot of hardware to a lot of people who wanna run Windows but we feel that Linux is every bit is important and we are trying really hard to have the things that we do in support of Linux make it possible for our customers to treat it as a fully equivalent first tier operating system. There are some things that HPX continues to do better particularly with regards to manageability tools and so forth. There are some things where some features and capabilities are available on Windows that aren't available on either HPX or Linux. So they're not equivalent in the sense of absolute functionality but they certainly are things that we're trying to give equal attention and levels of support to. I'd like to point out that our support of open source is in the community is genuine. We're not manipulative or divisive about this at all. We really have, there are, we do have an agenda. There are things that we would like to see worked on that aren't being worked on as much as they could be. Some of those things are things that we can afford to put some money behind and some of them are things we can't. The ones we can't afford to invest in directly we try not to make too much of a stink about cause that would be poor citizenship to complain and not be willing to do anything about it. That doesn't seem to keep a lot of people on Debian mailing was from behaving that way. Who am I to comment? And we do confidently deploy open source and Linux software including Debian in our own internal life T infrastructure and we will continue to do that and it continues to grow in terms of the percentage of systems that are running Linux one way or another. So with that, I thank you for your time and attention. I'll be happy to take any questions you might have until they kick me out. I guess actually we have to get out of here in another 20 minutes or so and you wanted to do some general Q and A, so. Nani, yes, I have an announcement to make. The thing is that with all the delays we've had today we're unfortunately gonna have to move the Q and A session to some other location because this building has to be completely empty from anyone by six o'clock and that's in 20 minutes from now. So should we take about maybe a few questions here? Yeah, well, you can basically take a few questions and basically 10 to six we're gonna just. And I am by the way going to be here for the whole week. I will leave on Sunday and go directly to Ottawa for the kernel summit. Hopefully I'll be awake for that but I will be around all week to take questions there but I'll be happy to take a few here under us. Would you call security support an unpleasant part and would you think that company could fund it? There's actually been a lot of discussion independent of HP's participation about how you do security and is it possible to fund a part of it without screwing it up totally. Yes, it is an example of something where I think we actually have in indirect ways spent money improving security and I wouldn't mind being approached about doing something in a more direct way but there's this general problem which I identified early in my talk that when you get in a situation where some people doing a thing for a project are being paid for it and some aren't. You have to work that very carefully so that the people not being paid don't somehow get demoralized or unmotivated or you can end up in a situation that was worse than when you started where nobody wants to do anything on it unless they're being paid and then it's a job and not an adventure and the whole thing gets weird. I myself have a question since you were mentioning earlier upstairs. Yeah, okay. You were mentioning earlier the kind of work that HP does with the open source community and I was just curious, since I'm local here, what kind of open source and free software activities HP does in Finland, are you? To be honest, I don't know the answer to that. I think that some folks from HP and Finland will be in and out through the week and maybe I can pester one of them to help us understand. I would be quite curious, yes. Okay, well, during the week then. Thanks. Yeah, up here. What is your view with your HP head-on of the Vancouver proposal or to ask it differently? Oh, the Vancouver proposal, yeah, yeah. Or to ask it differently, how important is it to have the Linux community keep supporting systems that have been declared end of life by a hardware vendor? Yeah, so the interesting thing that we have learned in HP as a result of the interesting sequence of mergers and acquisitions that's led us to the HP that we have today. Yeah, alpha, PA risk, MIPS based things. HP has this amazing array of stuff that we're still supporting for customers in one way or another. And we learned in the process of working out the roadmaps for what would survive past the compact merger that sometimes you do have to just say, we're done with this, we can't do this anymore, there's no business motivation and so forth. And I believe that it's completely reasonable to expect that at some point the Devian project will look at one or more of the architectures we currently support and go, this just doesn't make sense anymore. Now, when we talk about the Vancouver proposal in specific, I'm actually horribly disappointed that I wasn't able to be in Vancouver because I'm one of the folks that was invited who didn't get there. But I had been traveling insanely just before and needed to travel insanely just after that. And it was one of the few weekends in my schedule that I got to spend at home with my kids. So I decided to stay home with the kids and I guess I still think that was the right decision. But boy, it sounds like it would have been fun to be a fly on the wall in some of those discussions. Whether the specific set of proposals that came about as a result of the Vancouver meeting are the right ones and what we ought to do for the future, there's still some white space around that. In particular, I've had some interesting conversations with people who were there about just how important is it for things like I-64 to be first tier, second tier in our support structure in Devian and things like that. So there's been a lot of discussion. I don't know what the right answer is, but I don't think it's reasonable to expect that Devian will remain committed to supporting every possible architecture forever. It's one of the reasons I haven't proposed the Vaxport yet. But actually, the funny story about that, the day the compact merger was publicly announced as being successfully completed, they were past the lawsuits and all that and it was gonna happen, I happened to be with some friends at the Dayton Amateur Radio Convention which is a big amateur radio thing in the US every year with a huge flea market full of electronic stuff. And I managed that day to acquire for really cheap an old Vax station. And so I put a note out on one of our internal mailing lists announcing that I had just acquired a cheap Vax since my old Vaxes were all gone. And with this, I would begin work immediately on the Devian Vaxport. And the message I got back from my boss, which was pretty funny at the time when I still get a chuckle over was, boy that sure makes the PA risk port look a whole lot more relevant now, doesn't it? So, you know, yeah, I fully expect that we'll turn some architectures off over time. I think what's even more likely is we'll get into a mode where we don't make them completely go away but they drop out of the main mirror network and they don't try to be included in stable releases. I think there's also an interesting question that can be asked for architectures like ARM where the primary use of them is in embedded sorts of things about what do the people doing the derivatives of Devian for those embedded devices really need from Devian? Is it important to them to have all of the features of a stable release or is that noise? And I don't know the answer, but I think there's a lot of discussions we could have that would lead us to be able to get away with doing less work and that would be a good thing. Other questions? I have the mic. Where are you? Up here. Ah, hello. With a Gwadak shirt, got a load. My name is Yuha and I don't know, you would perhaps like a Debian question but I don't know how much this is about Debian and I don't know if this is a question or a comment, but many businesses want to benefit from the open development process and like HP, Novel, many businesses, let's not call this, but you almost touch the forking thing, like if a desktop project like GNOME is producing software and a business wants to have a feature for the customers or something and in effect, if it doesn't get into the main project and then it's going to be a commercial fork, so well, I don't have to say anymore, you know. So there's a trade-off in all of these things and one of the questions that our open source review board always asks when a project comes along inside the company and says we want to do this with some open source project is they ask, how's that going to be supported? What's the support life of this thing you want to do going to be? Are you committed to providing support for that over the long term or have you not thought about all of the consequences of your actions? And so we try to make sure that people in our company are engaging in those sorts of actions where they might be doing something that solves a short-term problem but not doing it in a way that's clearly obviously going to be accepted by the community in the long term. We try to make sure they understand what the obligations and the sort of implied commitments are. I mean, to some extent there's no absolute commitment beyond the normal sort of indemnification clauses and so forth that customers expect from a company like HP for the products that we sell them, but there's certainly an implied degree of support if we ship something to a customer, even if it's open source and we give them all the source code and adhere to all the terms of the licenses. If six or months or a year later we go, oops, sorry, we don't care about that anymore, they won't be happy with us as a supplier. And so we try to think through all of those things. There's definitely a cost associated with maintaining anything that isn't fully accepted by whoever the appropriate upstream is but sometimes that cost is completely justified if the business opportunity you're chasing is big enough. So there's no one answer that fits everything. I would like to point out that Debian is only one of the projects that we provide substantial hardware and bandwidth and other resources to the GNOME Foundation. Main servers are running on HPI right now. We recently donated a couple of quad dual core Optron servers with great gobs of memory and 10 terabytes or something of disk apiece to the kernel.org guys, freedestop.org, ex.org, the FSF, awful lot of projects we all know and care about are running on iron that we threw there away. So it's not just a Debian thing. This is really part, our relationship with Debian is an important part of a larger set of relationships that we're trying to foster. With that, obviously we're about out of time. I'll stop taking questions here. I'll be happy to take others during the rest of the week while we're at the conference. Thanks. Thank you, guys. Thank you.