 Thanks, Jason. So as Jason said, I'm Guy Martin, and I will be your host for the top ten signs that your company doesn't get open source. And I'm not as funny as David Letterman, and I'm definitely not an open source luminary like Lines Torvalds, but hopefully you'll get something useful out of these things even if it's just as cautionary tales. So number ten, we don't use or rely on open source in my company, or I don't use or rely on it. Well, we know that that's not true. If you've sent mail on the internet, if you've used Firefox, if you've touched a web server in any way, you've probably used open source, a lot of Android phones out there, as well as folks that use enterprise Java via things like Jetty and even JBoss. So number nine, we think open source is only about risk management. Well, you obviously have to have a process, and that's represented there in the left-hand side, but if that's the only thing that you're thinking about in open source, you're missing all of the value in community. So things like Drupal, things like SC Linux, things like Hadoop, all of the things that make open source really valuable from a community perspective. Number eight, what about support? Is an open source free? Obviously, you're here at Red Hat Summit. We provide support for Enterprise Linux, but there's a lot of other ways that you can provide support for other pieces of open source software. Obviously Drupal, if you're doing content management, it can be provided support by Acquia, Enterprise DB, MongoDB, the list goes on. The other thing with open source is that you have the benefit of being able, since you have the source, to run an open source support desk in your own organization, if that makes sense. Number seven, I can't mix and match open source and proprietary software. Well, you don't have to forklift your entire enterprise to bring open source in. You can put it in a variety of different ways, shown by the architecture there, but you really have to think about it from a pragmatic perspective and really balance the idealism pieces of open source with the pragmatism of actually making it work in your enterprise. So number six, there's no value in any open source contribution. Well, I think our friend Sir Isaac Newton would disagree with that since he said that I'm standing on the shoulders of giants, and a lot of companies are starting to realize this now, OpenLogic did a survey that showed the contributions from people within companies are on the rise. You also want to expose your developers to a bunch of different best practices because it helps them in their careers and it really helps your organization as well. Number five, well, my contribution fails, my patches were rejected. Well, you really need to think about kind of the sweet spot there of what is a contributor and those are the people that power open source and that's the things that they're concerned about. And you really need to think about this also from the perspective of a quilt. If you're bringing patches into an open source project, they need to fit with the rest of what's going on in that project so that it actually makes a cohesive whole. Number four, I can't develop like open source in-house. I can't use those methodologies. Well, that's not true. I have three great examples, Forge.mil, DOD Community Source, the Genevieve Alliance for Infotainment and Automotive, and the Kuali Foundation started at Cornell for open source management for a higher education. Remember, these are also all stepping stones that you can use to help your organization get to maybe open sourcing something after they've become more comfortable with it. Number three, hey, I want to open source things because I think there's three developers out there. Well, you need to think about the perspective of what's in it for me. That's what everybody's concerned about and you need to think about how you position this message with regard to where people are in this altruistic versus intrinsic perspective and really tune your message to make the most sense for those folks. Number two, hey, my code's on GitHub. I have community, right? Well, no, you just can't dump code out on GitHub and hope that community forms spontaneously. You need to be thinking about things like bug tracking and task management so that your community has something to latch onto and you really need to think about the membership lifecycle of your community and sort of how communities grow and how you have to nurture them. And my favorite one is coming up. Number one, hey, legal just wants me to tweak this license just a bit. Before your legal team drops a whole bunch of documents on you, you need to run, not walk to the open source initiative and really look at the approved licenses there. Not only because we don't want to go through and read your own open source license, we're probably not going to use your code if we have to do that. So it's very important that you not do that. And finally, what should you do now? Use these as cautionary tales. Really in your organization, try not to accept the status quo if you can and find people who you can team with to ask the right questions of your enterprise. And then if all else fails, you can always take Bart Simpson's approach and have your executives write, open source is good for me. I'm going to embrace it multiple times. Thank you very much.