 All set, all set, up there, yep, fine. Okay, welcome to the afternoon session, and as you see on the board there, Jared Smith is from Red Hat, and he'll be talking about Red Hat and Fedora. So please give a warm welcome to Jared. Thank you. Thank you. Thank you, I'm very happy to be here today, happy to come out to LCA. Everybody enjoying the conference? Oh, come on, it's afternoon, come on, we need a little more energy in the room, come on. Is everybody enjoying the conference? Yes. Well, you know, I'm very much enjoying the conference, I'm happy to be here. This is my first time to LCA, first time to Australia, and very happy to be here. To kind of set the agenda for what I want to talk about here today, first of all, I want to give a little bit about me and what my background is. That's usually the first question people ask me is, who are you? The second question is well, how did you get to be the Fedora project leader? So I'll talk a little bit about that. And then I want to talk about how Fedora came to be, kind of the relationship between Red Hat and Fedora and how that works, and where we don't want to take things in the future. Does that sound good? Any complaints, questions, rotten tomatoes before I get started? I like to do very informal presentations, I'm not going to stand up here and do death by PowerPoint. If you have questions, raise your hand, we'll pass a microphone around so that we can capture the audio on the recording. But I do want it to be a very informal thing. I've probably got 20, 25 minutes or so worth of slides, and then I want to leave a lot of time at the end for questions and answers and that sort of thing. Does that sound good? All right, so to give you a little bit of background about me, again, my name is Jared Smith, I'm the Fedora project leader. What does that mean to be the Fedora project leader? So that's what I want to talk about. But I'm a firm believer that people are a combination of their experiences in life. And their experiences in life kind of set the direction of who they are. So I want to tell you a little bit about my background. I grew up in a very rural part of the United States in the state of Wyoming. As you can see, very beautiful place to live, lots of mountains, lots of rivers. But summers weren't very long, it was a high mountain valley, about 6,500 feet of elevation. And so we really only had three seasons, last winter, this winter, and next winter. And we'd have that two or three weeks during the summer when everything would actually thaw and you'd get beautiful pictures like this. But in those short summers, I like to go down to the river and I'd always be down at the river. I would be either fishing or swimming or floating or throwing rocks in the river, but I just love to spend time in the river. And so I want to come back and use this idea as a river, as an analogy in some of the things I'm going to talk about here today. How many people here in Brisbane like the river? Well, except when it floods, right? But it's too soon. But I love being near the water. There's just something about a river that's peaceful and I enjoy it. So a little bit about my background. When I finally left Wyoming, went to university, worked on a degree in computer engineering. Okay, I'm not quite that old. But while I was getting my degree, I happened to take a class on UNIX and kind of learned the UNIX way. I learned that my fingers were magical instruments and if you put them in VI, then they can do wonderful things. Any VI users here? Yay, Emacs users here? Yay, I won't harass you too bad. But I learned the power of the command line. I learned the power of the UNIX way of doing things, of having small little tools that work together. And that helped me get a job while I was going to school as a systems administrator and a programmer. By the time I finished university, I had no interest whatsoever in doing electronics, what I was supposed to be studying. I had a lot more interest in systems administration and Linux and that sort of thing. From there, I had a number of different jobs, most of them doing systems administration and web programming, some DBA work. Work for a company that had about 6,500 Linux servers, so I learned very quickly that while it's easy to do things on a single box or a couple of boxes, once you scale that up to thousands and thousands of servers, you've got to be a little more careful about the way you engineer systems, about the way you approach systems management. You find out in a hurry that servers are living, breathing animals. How many of you here, if you had a son or daughter that came to you and said, hey, will you buy me a pony? What would you say? What's the first thing, the first thought that comes into your mind? No, cost. You're gonna say, oh, we're gonna have to have a place for it to live and we're gonna have to feed it and we're gonna have to clean up after it. And so you start thinking about the logistics behind, okay, what's it really going to take to own a pony? Well, I think you should take that exact same mindset when you set up a new server. Too many times I see people set up a server and I'll just set up that server and then I'm done, right? That's not quite really the way that it works out. You should have a little foresight to think, oh, I've got to take care of that server, I've got to keep it maintained, I've got to keep it up to date. If for some reason it dies, then we're gonna have to replace it, those sorts of things. So I learned how not to be sloppy with systems management. From then I took kind of a weird path in my career. I really got into voiceover IP in a big way. Anybody here who used asterisk, voiceover IP platform, I got really, really heavy into the asterisk community. I was co-author on the O'Reilly book on asterisk, served as the community relations manager in the asterisk community, ran some of the training departments around asterisk, got into asterisk in a big way and spent five or six years really heavy in the voiceover IP industry. And then this last July, Red Hat hired me to be the Fedora project leader. And I haven't quite figured out if I tricked them into hiring me or they tricked me into actually wanting this job. I haven't quite figured that out. But here I am today as the Fedora project leader. So what does it mean for me to be the Fedora project leader? Well, there's kind of three roles that I play. One is I lead the project. I'm the chairman of the Fedora board. We as the board set kind of the direction, the strategic direction of where we want Fedora to go. In addition to that, I'm kind of a liaison between the corporate culture at Red Hat and this open source community we call Fedora and act as a conduit and a bridge between those two communities. And so in a lot of ways, I represent Red Hat to the Fedora community. I represent the Fedora community back to Red Hat and make sure that there's that flow of communication. And then last but not least, I'm kind of the head cheerleader and figurehead for the Fedora project. I get to travel around the world, speak at conferences, keep people excited and interested in what's going on at Fedora. All right, so that's a little bit about me and how we got to where we are, at least how I got to where I am. Now let's talk about how did Fedora come to be? How did we get to where we are in Fedora today? So let's go back in history a little bit and let's talk about a Red Hat. Okay, not that Red Hat. That Red Hat. Nice little company started up in the backwoods in North Carolina, not exactly a place in the United States you'd think of for great software companies to come out of. And they kind of had an interesting model. It was this company that they were gonna give software away for free and then make money on t-shirts and hats. And it worked okay sort of for a few years. And so there's probably many of us out there that had something like this, right? How many people started on Red Hat four or two or five or five, one, five, two? I started on four or two. I couldn't find a good picture of a four or two CD so I had to use this picture. But, and y'all remember kind of how it was every six months or so. There would be a new version and some of them were better than others. You probably can remember in your head, oh yeah, I remember that run release was really bad. Oh yeah, that seven, three release was really good, right? And so that's kind of where I came into things. And if you went out and bought the support contract for Red Hat Linux, you basically had about 18 months of support and package updates. The problem with that model is that it didn't work really well. To be frank, an 18 month release cycle just didn't give independent software vendors and hardware vendors time to get things up and working for the next version of Red Hat. And Red Hat wasn't very successful in really marketing that and making a lot of revenue off of it. Thankfully, someone came along and saw the light and said, we've really got two different competing interests here. We've got people who are really wanting to use Linux in an enterprise environment where people are very risk averse and like slow, steady, might even say the word boring approach to systems management. At the same time, we have all these really cool geeks that just like the technical bits and they want the latest and greatest. And they're a little more cutting edge. They're not really that interested in something that evolves very slowly. And so there was kind of a split and that's where we got Fedora. And by this time, Red Hat had kind of matured as a company as well. You know, they had found a business plan that worked. They'd become a public company. And at that time, they were really interested in being a little more open with the community, opening up some of the things that they did internally. And that's kind of where we got Fedora. And so Fedora is kind of the community focused, rapid evolution, rapid development piece at this stage in the game, managed by the community and Red Hat uses that to kind of set some goals, get some early insight into technologies that are evolving and that sort of thing. And we'll talk more about that here in the next few minutes. I think to be brutally honest, I think this was a big gamble on Red Hat's part. I think they had to take a pretty big leap of faith to say we're gonna put a lot of trust in the community and hope that they do the right thing. But for me, it was very refreshing because I was one of these community people who was helping out in Fedora from a community standpoint and was glad to see that level of trust come from Red Hat. And I think as time has gone on, the Fedora community has come to trust Red Hat in the opposite direction as well. Obviously on the commercial side, at the time of the split also created what we call RELL or Red Hat Enterprise Linux. So this is a subscription model. You buy a subscription for your support and your updates, that sort of thing. It's a 24 to 36 month release cycle. So slower, the old boring stuff, but it's rock solid. Comes with seven or more years of updates, which businesses love to hear. And it may be the old boring stuff, but for those very risk averse systems administrators, just something rock solid that they can depend on. The hardware vendors love it, that sort of thing. And so the question always becomes, and I love this picture because it says it so clearly, how do we keep the competing interests between Fedora and Red Hat from conflicting? Because there is some tension there. I won't sugar coat it. So what does each side get out of that relationship? So that's what I want to explore over the next few minutes. For Fedora, the benefit to us is that we have this, this benefactor out here, this rich uncle who can provide some salaries, help us out with logistics, help us out with things like export compliance and legal hoops that we have to jump through and that sort of thing. Without us having to worry about that on our own. We don't have to try to go out and make money with Fedora to solve those kinds of problems. Obviously, we can focus on innovation. The other thing that Fedora gets out of the relationship is we can serve as an upstream and be as close to the upstream communities as possible. So what does Red Hat get out of the deal? Well, they get a chance to see what's coming in the future with technologies. They have a chance to identify problems early on before they make it into Red Hat Enterprise. This also gives Red Hat a mechanism where it's much more transparent, much easier for them to interact with the software community at large. And so I really think it is a win-win situation. Let's dive in in a little more detail and talk about, well, how does that work, okay? So let's start off talking about software and particularly open source software. Where do software come from? You just wake up one morning and hey, there's software on my front porch. That would be nice. Fixie dust, I'll have to get some of that. Software theory, how about committees? Does software come from committees? Does innovation come from committees? Not usually, unfortunately. So where does software come from? From VI. And from VI. Smartness, I got a prize for you afterwards. Great answer. Software comes from an individual, typically an individual, every once in a while you get two or three people working together. But typically software starts with one person having a great idea and say, hey, I should go write this, right? And then as they write it, as other people start becoming interested, we build software communities. So what is a community? Bunch of people, okay, I've got a photo here of a community. Is it just a bunch of people who happen to live close together? Oh, they've got something in common. That might be important. So it's not just being geographically close to somebody, but it's having something in common with them. Okay, when we talk about software communities, what might we have in common? Shared values and goals, very important, okay? So it's important to think of when we think about software communities. I'm reminded of an interview that Linus Torvalds once gave and somebody asked him, well, what's the state of the Linux community? And Linus says, community? That's not really a community. There's a bunch of people using Linux for their own self-interest. It's not really a community. I thought that was an interesting definition. I have a little bit different definition of community. My definition is community is a table where we all sit down and we share ideas and we try to reach some common goals together. It's very much more of a meeting place than it is that we just happen to be in the same place at the same time. And yes, sometimes that discussion does turn to the picnic table itself and we have these nice discussions about all the, should the picnic table be painted and what color should we paint it and we get more caught up in the process and the machinations of what it is we're trying to do rather than focusing on the software itself. But nonetheless, it's a process that we go through to work together. Now, typically when you're talking about software communities, we kind of divide things up into a couple different directions and we use this analogy of a river or a stream and we talk about upstream code. So the code starts upstream, it starts where it's being written. And then it wanders down and we call that downstream and the downstream is eventually the end user using the software. And so I like to use this analogy of a stream when I talk about Fedora. The development community is upstream and the consumers are the downstream and the analogy works such that the closer you are to the source, the further upstream you are, the more influence you have on the ultimate result, right? If you're the author of the software, you have the most control over what that's going to do. If you're not the, let's say you're not the author but you're in that software community or you're a distribution that then distributes that software. You have a little less control over what happens with it you can't exert some control or some influence over that. If you're the end user, you have even less control or less influence that you can exert on that. So we have this concept of upstream and downstream. And one of the things that Fedora focuses on and has focused on for the past several years is doing a better job of interacting with those upstream communities and really tracking closer to those upstream communities. There was a time when Fedora was all about, while taking the part of that software, it was upstream, but then adding a bunch of patches onto it and trying to push it in our own direction. And I think it's done, we've done a much better job over the past, say, three or four years of reaching out to these software communities and following them more closely and following. Kind of being a better citizen in that regard. So obviously the major work product, the major result of what we do in Fedora is a CD image or a DVD image as it comes out every six months, right? So what is on that disk? Just a bunch of software, right? Is it just a collection of packages or is a distribution more than just a collection of packages? Hopefully it's something that's a bit more coherent. We'll talk about that. So let's talk about software packages in general. First of all, why do we package things up in a particular packaging format? Whether you happen to use the RPM format like Red Hat and Fedora and SUSE do. Whether you're using the DEB packaging, like DVN and Ubuntu and some of the other distributions use. Why do we package software up the way we do? For dependency tracking, for making it easier to install and uninstall? It interacts. So it's not just individual pieces, but there's some cohesion between the different pieces. Anytime I talk about software packages, I like to think of them as building blocks, okay? And these building blocks have little, if you've ever used the Lego building blocks, anybody here like Lego? I'm a sucker for Lego. I remember when I got married, my wife said, you know, I thought I was gonna have to say this to our kids, but Jared, you need to put down the Legos and go to work, you know? So I love the analogy of Lego blocks as software packages because you notice they have these little knobs on them and they fit together and you can build all kinds of cool things, right? And I might want to build a spaceship with my Legos. You might want to build a castle. You might want to build a boat. You might want to build a motorcycle. There are these building blocks and you can put them together in different combinations to create some really cool things, right? And so in Fedoro, yeah, we have a lot of packages, but what I think is more important than just having a lot of packages is having packages that fit together, that are, you know, work together to build something. Great. And so just like this set of building blocks that looks like a little European town, I like the fact that different pieces are working together. They fit together. They form more of a cohesive whole. Well, obviously it's more complicated than that, but that gives you just a kind of a general analogy that we can follow. Now, let's talk about the Fedora release cycle here for a second. This graphic shows that, for example, in June of 09, we released Fedora 11. We have a 13 month update cycle for that meaning we're gonna provide package updates and bug fixes and that sort of thing for 13 months. So while Fedora 11 is out there, we have six months of development, and then we released Fedora 12. And then there's another six months of development and we released Fedora 13. You can see right here, we've released Fedora 14, late last year, end of October, first part of November, and now we're in the development cycle for Fedora 15. So we've had these six month releases. This coming May will be the 15th release of Fedora, and then we're, again, on track, six months. And it's not necessarily just, hey, when that six month mark comes, ship whatever bits happen to be in whatever state they are. We focus very much on saying, yeah, we wanna try to stick to the six month schedule as much as we can, but we're gonna have release criteria and we're gonna say, these are the things we want to have working and if they're not working yet, we're gonna slip the schedule a week or two weeks or maybe even three weeks. But we wanna make sure that what we ship is high quality, but we don't want to let perfection be the enemy of something that's good enough. So there's some give and take there. We could say, hey, we're not gonna ship until everything's perfect and then we'd never ship anything, right? Because that's the nature of software. There's always that next version that fixes a few things and adds some more features and those sorts of things. So what this really means is that Fedora, you can think of as this gal on the kayak and it's always pushing to be upstream, okay? A little further behind that, you have things like Red Hat Enterprise. You can see this kayak down here is being Red Hat Enterprise. Little further downstream, not quite as far out there on the cutting edge and Red Hat Enterprise, Linux really tracks what's happening at Fedora. So when Red Hat decides they wanna do the next version of Red Hat Enterprise, they look and say, oh, what's been successful in Fedora? What things have really worked well in Fedora? Let's use that as a base to start from to build Red Hat Enterprise Linux, okay? Now, there's lots of different places where Fedora and Red Hat Enterprise Linux interact with what software communities. Let me give you just one example and this is probably the most notable example and that's with the Linux kernel. Everybody needs a kernel, right? And everybody knows the basic idea of how the kernel development works. You have, you know, Linus is our benevolent dictator. He's got lieutenants, he's got subsystems and maintainers and then development under that. But it really all kind of flows up through Linus and when he decides to pull into his tree, right? So Red Hat cares very much about helping out in that community. Red Hat employs over a hundred people specifically working on just kernel, whether that's generalist, whether that's specific subsystems, whether that's working on particular hardware. Red Hat very deeply cares about being in the upstream communities that matter most to Red Hat and to Red Hat's customers. And so we put a lot of effort and a lot of time and a lot of employees in the places that matter most like the Linux kernel because we care and wanna help out in those areas. To give you an idea, the Linux foundation every year or so puts out a publication that tracks who's putting code in the Linux kernel? Where did that code come from? Were they employed by a corporation? Or were they contributing things on their own? That sort of thing. Their latest release, which came out last month, says that 12.4% of all the code in the Linux kernel came from Red Hat and Red Hat employed folks. Which is pretty healthy. If you look at it compared to the other contributors, Red Hat has the largest chunk followed by Intel, Novel, IBM, and on down, you can see the different. And these change from month to month a little bit. Sometimes companies are a little bit more dropped down and for example, some companies will add a big device driver and that'll add a bunch of lines of code and then over time their contributions will be smaller again. But Red Hat has consistently been at the top of this list. This was last year, yes. Another interesting statistic is maintainer sign-offs on code. So when a patch goes into the Linux kernel, it needs to be signed off by somebody to check so that they've reviewed it and they're happy with it. Again, the numbers at the end of last year, 37.7% of the commits going into the Linux kernel were signed off by someone at Red Hat. So that, again, just an example of our commitment to the code. So now looking at the kernel from kind of the Fedora perspective, obviously our mantra is upstream. So we want to try to carry as few patches as possible to the kernel. We'd rather push those changes upstream where they belong. So every time a new kernel comes out, we don't have to go rebase all our patches and that sort of thing. So it's a slightly slower rate of change than the upstream kernel. But again, we want to push as many changes as we can upstream. And that really smooths out the user experience with open source. So here's an interesting slide. I should have re-pulled these numbers for a little bit newer kernel. But when Fedora 12 came out, you see we were using the 2.6.31 kernel. And you see how many patches against that kernel we had, somewhere in the neighborhood of around 120 patches. As time went on, when the 2.6.32 kernel came down, obviously over half of those were already in the upstream kernel. So then we were only carrying 60 patches against the kernel. And then as time went on, we got a few more and a few more until the next upstream kernel was released, then more of those were upstreamed. Again, the idea is to have carry as few of our own special changes as possible and push as much as we can into the upstream communities where it makes sense. Now, why do all this? What's the point? Why do we go to this effort? Again, I want to talk about what does Fedora get out of this? What does Red Hat get out of this? The most important thing for Red Hat is to be able to see what's coming on the horizon, to get some early insight into what are new technologies, what are people interested in, and that sort of thing. And so they can look and see what's happening in Fedora as a good way to say, is software working? Is it mature? Is it ready enough for people to be able to use it in the enterprise? Another thing that Red Hat gets out of it is an early feedback mechanism. Hardware vendors, software vendors, individuals can try out Fedora and then say, hey, this is really working. We want this in Red Hat Enterprise. Or, hey, you're making these changes in Fedora, but I hope this never makes it into Red Hat Enterprise because I don't think it's ready. Those sorts of things. It's a great feedback mechanism. Another thing it does is it's a place where people from the outside can help contribute and feel like they're part of building something that's making the world a better place. It's something that they can take pride in in helping and contributing. Because that's, frankly, the reason why a lot of us contribute to open source, right? It's not for the money, necessarily. More than that, it's for being able to contribute to something that's better than the way we found it. I love the phrase that says, none of us is as smart as all of us. Because I think that really truly epitomizes what open source is all about. That any individual here, no matter how smart they are, is not as smart as the community as a whole. And I think that's very powerful. Another thing that this gives to Red Hat and Fedora, there's some give and take here, is tools. I can't tell you how many times we in the Fedora community have implemented tools that Red Hat has its own internal tool for solving this particular problem. And after a couple of years, the Fedora tool ends up being so much better than the Red Hat tool that the Red Hat folks adopt the Fedora tool for doing those sorts of things. Innovation happens in Fedora. And this is one of the things that we see. The other thing is the opposite. A lot of times, Red Hat has internal tools, and they'll contribute those to Fedora and get those out and make those open source things so that the world can benefit from those as well. So there's give and take there as far as tooling goes. One of my favorites is a tool that started out as a Red Hat internal tool, and then got open source is a program called Publican for writing technical documentation. You write your technical documentation in DocBookXML and then use Publican to create HTML or PDF or ebook versions of that documentation. It's a very, very slick tool. So that's, again, one of the benefits. Now, I won't say that the relationship between Fedora and Red Hat is exactly perfect. Obviously, there's competing demands there. It's a work in progress. But I think we've done a tremendously good job of communicating through differences when there's differences of opinion or different conflicts. And again, that's one of my jobs as the Fedora project leader is to be a conduit for that type of communication, keeping the channels of communication open. Before I finish up my formal presentation here, the third question that people typically ask me about my job and what I do is, well, what do you see the biggest enemy of Fedora as being? What's your biggest challenge? And there was probably a time when I was going to say, well, the biggest enemy to Fedora or to Linux in general was some other large software corporation. And there was a time when I thought, well, maybe Red Hat's going to be the biggest enemy to Fedora. What are they going to do with Fedora? To be honest, my biggest concern today is the biggest enemy we have inside of Fedora is Fedora itself. I don't think that Red Hat's ever going to do anything to destroy Fedora. I don't have any indication that they'd ever do such a thing. I don't think that another large software corporation is ever going to be able to come along and do anything to hurt Fedora. I think if anything, Fedora gets held back by its own people sometimes. Sometimes we're so busy tearing each other down that we don't do a good enough job internally in our own community of taking care of each other and lifting each other up. We tend to be too focused on the negative sometimes and not enough focused on the positive. I think we tend to be more vocal when we have complaints than we do with vocal with our praise. And so that's something that I obviously focus on in the Fedora community, is making sure that we take good care of the people who take care of us. To kind of finish up the formal part of my talk here, I want to talk about why do we do all this work? Why do we build software distributions? Why do we work in open source software? And I think this sign right here sums it all up. We all live downstream. Have you ever noticed if you go out here to the street and there's a drain in the side of the street, have you ever noticed what it has stamped on the side of the drain there? What does it say? That's right, it says, hey, this drains into the river or this drains into the lake or this drains into the ocean. Wouldn't make sense to go pour a bunch of motor oil down the storm drain, would it? Why? Because we all live downstream from somewhere. I think the same goes for software. We make the world a better place because we're all end users of the software that we're building. We're all end users of whether it's Apache or Asterisk or VI or one of the distributions, whether it's Debian or whether it's Fedora or whether it's Ubuntu, we all live downstream. And I think that sums up why we do what we do. With that, I want to just open it up for questions or comments. Again, we'll pass around a microphone so that we can try to capture the audio on the presentation. But again, I want not only questions, but if you have comments or feedback, I'd love that as well. Just hands up and I'll pass it around. Hold it right very close to your mouth. OK, like that. One thing that I've always wondered about is going on this downstream thing. What sort of relationship does Red Hat, if any, have with Centos? So it's an interesting relationship. And this is just my own opinions. Don't take this as official Red Hat commentary. But it's an interesting relationship. Obviously Red Hat believes in the open source model. It's part of the very fabric of what makes Red Hat. And that's why all the sources are available and they're available source RPM. So it's, frankly, very easy for someone to come along and rebuild those. I wouldn't say that Red Hat dislikes the Centos community. I think there are some people, I've got to be careful how I say this, but there are some people, particularly in the sales side of Red Hat, who don't understand maybe the model as well and how open source works that might be scared of it. But in general, I think it's a pretty, you know, Red Hat understands that that's part of what comes in playing with open source is you take the best bits from other people and other people take the best bits from you. And it's a give and take relationship there. I wouldn't say there's any animosity towards Centos. Like I said, if anything, the biggest thing I've seen is when people are trying to sell Red Hat Enterprise into a business and feeling, you know, maybe fear isn't the right word, but some consternation as to how can I sell this if Centos has given it away for free? But that's kind of par for the course. We've got 10 minutes. So plenty of time to ask some more questions or comments, folks. Actually, on the similar vein, perhaps you can repeat. I asked Jared just as he came in about I'd actually shifted to Ubuntu when it first came out on the basis of, as I thought, that it had a superior package manager being Debian, which I thought at the time was somewhat superior to RPM. And Jared managed to convince me in about 45 seconds what a complete bungle it was that I should have shifted in. So perhaps you could explain, again, the differences as they are now rather than back then between the package management and anything significant. Sure. And what I explained is that I think all package management in Linux has come a long way over the past 10 years or so, whether you're using the RPM format or whether you're using the Deb format. They're both great formats. They both do a great job of explaining what's in the software package and what are the dependencies and how do those fit together. Obviously, there's differences on how we handle individual cases. And that's another topic for another day. But I think around the individual packaging formats, we've also done a better job of the tooling that finds those packages, finds their dependencies. We've done a better job of organizing repositories so that you can go out and find different collections of software that weren't better. I think software communities in general have done a better job of saying, oh, I'm not just going to provide a tar ball when I make a new release, but working with distributions to say, hey, I want my software in Debian or I want my software in Fedora or I want my software in Ubuntu or OpenSUSE or whatever the case may be there. I know most of my own experience has obviously been on the RPM side. I think our young tool has come a long way. And to be frankly honest, it was suboptimal when it first came out. And it had some interesting challenges. But I think we've done a great job of overcoming some of the challenges we've had. I know that a lot of the tools around the Debian packaging format have come a long ways as well. And I think we're all better off for it. Again, excuse me, ignorance, because I'm still on Ubuntu, but would you say that it's the young RPM combination that really is important or RPM on its own? No, I would definitely say it's the combination. Just like if you're on Debian or Ubuntu, you need both the dead packages themselves and a tool like apt-get or aptitude to help you manage those packages. I think it's the combination of both the packages and the tooling. And to be honest, there's a lot of work going into right now getting the different software distributions to work together on the tooling, whatever the underlying packaging format has to be, trying to come up with a little more unified front as far as the tooling itself. Well, you kind of just preempted my question then. When you brought up package management, I've used young and apt and, as you said, I think they're all great tools. I'm pretty distra-agnostic when it comes to that. But it seems to be duplicating work, not just in package management and lots of areas. Now, the ultimate goal is, of course, upstream in any code for everyone to benefit. But does Fedora have much of a relationship with other distros try to stop duplication of work? I would have to say that traditionally, we probably haven't. That's one thing that I really want to focus on, and I'm hoping to work on. If you turn around and see Stefano there, he and I have actually started up some conversations. We're actually going to be kicking off a conversation that phased him here in a couple of weeks in Brussels to actually talk about how can we, as distributions, work together, communicate better, treat each other with a little more civility, and work together. Because nobody gains, if we're wasting time and effort, competing against each other, instead of focusing on what's really important here. And that's to move all of Linux and all of Open Source forward. We don't need to reinvent the wheel five different times or six different times or 60 different times. So there will be some. Oh, go ahead, please. So we have just had, like a week ago, a wonderful example of cross-distro collaboration. So Vincent Oomph from GNOME from Open Source actually proposed a cross-distribution meeting on how to develop application installer, let's say, a la software center. So and people from several different distributions, Dabian, Fedora, and Magia, and Open Source sit at the same table and design technologies and look at the existing technologies to refactor them and design something together. So that is something very good that we need in distributions. But the idea of having universal packages which work on all distribution is kind of a hard herring. Because as someone said before, a distribution is just not just distributing software. It's actually blending together in some uniform way. And in the choice of how you blend together, they're in something specific of every single distribution. So in Dabian, we have a policy, which is not necessarily the same they have in Fedora. And actually, the difference in the policy actually are good for the ecosystem. So people can try with different policies and see what works best and give some diversity to the ecosystem. Still, we need to refactor stuff and minimize efforts elsewhere. This is almost following on again from that. One issue still at the moment with some of the distributions is support for a variety of architectures and platforms. There's still a number of areas where 64 bits, almost a second class platform, even on Intel style architecture. What can we do about this? Because especially when we're dealing with vendors who are distributing their software outside of the Linux distributors tree, because they're not entirely open source or for whatever other reasons, it's often a struggle to get it for your particular architecture, be it x8664 or PowerPC or whatever else you happen to be running it on. What more can we do in that space? Well, I think first of all, we have to make sure that those architectures are working well with the software we do control with the open source software. So for example, in the Fedora community, we've focused heavily on we have our primary architecture, x86 number 32 bit and 64 bit. But we've got a strong powered PC community in Fedora. We've got a strong Spark community that Dennis helps with, and there's oftentimes struggles when you take even open source software and try to port it to a new architecture. We're doing a lot with ARM in Fedora right now. And just this past week, we've got all of Fedora 14 now running on the S390. And so I think that's the first thing that we can focus on is just getting our own house in order, so to speak. But second is the way that we communicate these changes up to upstream communities. One of the biggest examples that comes to mind is Adobe and Flash Player. The company that I was working for, where I managed the 6,500 Linux servers that I talked about earlier in the slide, was a big web analytics company called Omniture. They've since been bought out by Adobe and so a lot of my former coworkers are now Adobe employees and I happen to strike up a conversation with them. And they mentioned that one of the things that absolutely drives Adobe crazy is that only maybe four or five percent of their Flash customers are running on Linux, but that small minority of users are by far the most vocal. And when the Linux folks, and they went on to say that when the Linux folks are vocal, they tend to be very rude. They tend to be very, well, yeah. They don't communicate in a very adult fashion. Let me put it that way. And so I think the second thing that we can do is when we're asking these software companies to help support us, do it in a kind way and not in a condescending way. Obviously, we can say, this doesn't work and you're awful and you should change, but I think we would get a lot further if we took a step back and tried to present a unified front that was friendly and say yes, we have these concerns, we would love to have your software in this particular flavor or format, but we understand the constraints you're under and try to work with these companies rather than work against them, I think. I think an event like this, the community, the people that are kind of in a room like this, we're the guys who should be tying this out and living with some of the pain, making those book reports, filtering changes upstream. Personally, I've been using 64-bit Linux on my laptops now for maybe about three years and gone through that pain with Flash, with Skype, with those other tools that as much as I'd love to only use open-source alternatives, sometimes that's not possible. So, yeah, work through that, report those issues and then make a better ecosystem for everybody else. Yep. Thank you. Okay, thanks, time for one more. One on the back row, it looks like. So, most people probably have a pretty good idea what the audience, what the target of Ubuntu is and of Debian, Debian is the universal distribution and Ubuntu is more focused on the desktop and most of the other distributions have a very clear focus. What would you say as a Fedora lead, what Fedora actually is, what its audience is and then what our target actually should be? That's one of the things that the Fedora board in particular has spent the last year and a half or so working on. Paul Frields, who is the former Fedora project leader, spent about a year working on it and then when I became the Fedora project leader I've kind of done the follow-up work. But we've set both a target audience for Fedora. Our target audience for Fedora is someone who is technically capable, someone who is voluntarily moving to Linux, someone who is willing to communicate and ask questions and get help, that sort of thing. You can go to the Fedora project Wiki to get a better description of what the Fedora target audience is. Some of the other things that the Fedora board have done is set both a mission statement and a vision statement for what we want to see, the direction that we want to see Fedora headed in and again, all that's on the Fedora project Wiki. And then what we're doing right now is working on kind of the government structures inside of Fedora, starting with the Fedora board and then going out to our steering committees whether it's our engineering steering committee that we call FESCO, whether it's our ambassador steering committee, whether it's the special interest groups like documentation and translation and design and some of the other special interest groups in Fedora and sitting down and talking with them and saying, what are your top two or three or four goals that not only you'd like to see happen in Fedora over the next few releases, but that you're willing to work on and help contribute to? And that's been an interesting experience. It's taken a lot of time and it's taken a lot of effort to try to focus and say, yeah, there's 20,000 directions we could go in, but we have limited resources and so we need to focus on what's most important. You know, I'm kind of a pragmatist myself. I look at the world and I said, well, we can sit here and we can talk all day about where we want to go or we can get up and go do something. And so for me, code speaks louder than theory. At the same time, community is better than code. And so there's always a balancing act between those three, between community, between code and between trying to engineer the perfect card house in theory. So it's a matter of balance there, but I think we're doing a good job of at least communicating those things, getting consensus between the various groups and steering committees inside of Fedora and trying to focus and organize ourselves to focus on what's our mission, what's our vision and move forward in that direction. I don't think that Fedora in the short term, especially is ever going to be, you know, the mainstream, you know, PC operating system, the way Microsoft Windows is right now. In the long term, that'd be great. I don't think we're gonna get that in the next year or two years. That being said, there are certainly things we can do to improve the user experience for people who are noodle Linux and we'll be working on some of those sorts of things. We can also do things to make the experience better for the experienced Linux user as well. There's certainly lots of room for improvement. I think we're seeing incremental change rather than revolutionary change within Linux. It's getting better. I had the opportunity about three or four months ago to fire up an old hard drive. I had to pull some files off of an old hard drive and that old hard drive had Fedora Core 5 on it. So, you know, basically nine releases ago and it was, and I opened her for me to see just how far things really have changed in the past four or five years. We've made a lot of progress. Is there still a long way to go? Yes, absolutely. And we've got to be in it for the long haul and not be willing, you know. It might be easy to take some shortcuts along the way but we've got to keep our focus on the long term and make sure we're doing what's best for 10 years from now or 20 years from now and not say, oh, this'll get us three months down the road, let's take this shortcut because I think we're selling ourselves short if we do that. And on that note, I'd like to present you with a token of appreciation from Linux Australia. Thank you. These are academia husk bowls, really nice. There's a whole story that everyone's heard several times so I won't bore you with all that again. Suffice, but since you did come from the USA, we got you a special one that actually started its life as the, it was a plug in the Wyvernhoe Dam above Brisbane, which fell out, which caused the Brisbane floods in the first place. So, there you go. Well, thank you. Thank you very much, please thank Jared. Let me just add that I do have my email address up here, jsmith at fedoraproject.org. I'm very easy to find. If you're on IRC, my nickname on IRC is jsmith. It can't be any easier than that to track me down. If you do have questions, if you do have comments, if you have feedback, I really am interested in hearing from you. Feel free to get ahold of me if you have any questions. Thank you.