 Okay, welcome everybody to Sunday here at Scale 14x. And for our first speaker today in this track, we're going to have Brian Profit. Brian will be telling us about finding the value here in open source projects. Brian is a Currently Principal Community Analyst for Red Hat's open source and standards team. He's a long time member of the open source software community and he's authored several books on Linux, iOS and other odd operating systems. He's also a former technology journalist for ReadWrite, IP World, Linux Planet and Linux Today. Let's all welcome Brian. Thank you. Okay, so the topic of this talk is going to be talking about something that's probably near and dear to a lot of people in the open source community. This idea that community and business do not necessarily always get along. This is a common thread throughout a lot of companies. We see this in new startup entrepreneurial situations. We also see this in even established open source companies like Red Hat and Sousa and Canonical. This is a common thread where there seems to be this little push pull pseudo adversarial, sometimes not pseudo adversarial relationship between the idea of community and business. And the nature of this talk is to sort of dispel this notion that they have to be at odds with each other at all. And this kind of has come up in my tenure at Red Hat because surprisingly, even though Red Hat is regarded as one of the purest, for lack of a better term, open source companies out there, there's still a lot of this internal struggle on a daily basis within our different teams. A lot of this is because community can be generally fairly confusing to a lot of people. The approach that people can take with community can vary as wildly between like, okay, this is a group of users that we're going to respect and we're going to take care of and we're going to give them lots of nice things and make them feel good to an actual participatory community, whereas we need these people to help us with our project. But even then, that becomes a little bit of a nuanced relationship because sometimes you can do that and say, well, we're using this community as a resource, but that's all we're doing. We're not really going to give them anything back. We're not going to give them the same what's going on to whatever regard is better forms of community, which are participatory and on all levels. It's a two-way street. So kind of nailing this down is something that's very important when we all look at community and try to figure out what it is we want and what it is we should be doing. And I think that even if companies have different goals with community, there's still some basic rules of the road that they should follow and make life better for everybody, even if it does seem like it's a drain on resources or we're giving something away and not getting anything back. Because this confusion can create a divide. This divide shows up in any open source company out there. I named a few earlier, but I could probably universally say that if you could think of a commercial company that is working with open source in any way, shape, or form, there is going to be at some point, and probably more often than you think, a divide between what is regarded as the traditional business side versus the community side. And how that divide is bridged is an interesting case, because sometimes what we see is that the divide will actually be bridged by, let's say, okay, well, let's make community part of marketing. Okay, and if it's part of marketing, we understand marketing. Marketing is a business function. We will make it part of that and we will treat it like that as a marketing line item, basically. Okay, that's a way to go, but it might not necessarily be the best way to go because at that point you're really, you're getting into the point where you're treating that community as a resource to be mined, and that is probably not your best approach to handling community. When you think about how businesses think of community, you know, businesses traditionally are very much lined up along the bottom line. That's what a business does. In the public company in most countries, you're required by law to make as much money as you can. And if you're a private company, you know, you're pretty much going to feel the same way. You're trying to try to get as much revenue that you can squeeze out of your product and your company and your team as you can. Okay, it's crass, but money is a very big driver here. Okay, and I'm not really saying anything that's, like, hugely new. But, you know, when you think about it from a project point of view, and I've kind of been digging business a little bit and putting this all on them and saying, well, they don't understand community. Well, there's the opposite problem too. Let's be fair. A lot of community projects that work with corporate entities often feel like we're not about the money man. You know, we don't want to be, you know, dealing with that. That's not our problem. We're here to create something good and pure and solid. So they sort of, they can almost be, from the opposite side, adversarial and stiff-arming, you know, commercial entities and trying to keep them away. So it's, you know, it takes to the tango. So it's not just the businesses maltreating the communities. The communities can kind of be the same way about the businesses as well. This can be an adversarial relationship at times. Okay. And it doesn't have to be. Okay. Community can be regarded as a resource. But it doesn't have to be the kind of resource that is, like, set up in its own little area and self-contained and it doesn't do anything else beyond that. People don't always get community, but people know that they want it. So many companies want to be, to have a community. Obviously Red Hat, we want to have a community going, and we do with a lot of, many of our open source projects. In fact, well, all of them that we actually directly support. But it's not just pure companies like, pure open source companies like Red Hat. McAfee, they have a community infrastructure. Google does. ENC, Canonical, just going down. Charles Schwab, Charles Schwab, when I was researching this, I'm like, okay, they want to have a community manager, but their community is around their users. And that's okay. That's a viable community. But, you know, what does that look like as far as participation? What does that look like for growth? What does that look like for people? You know, what did their users get out of this? And what does Charles Schwab get out of this? You know, how many people here remember when Saturn came out, the cars? Do you remember that they had, they used to have the cool picnics and everything like that? And they would have the commercials on the TV and everything. And you would literally, I was too poor to buy a new car at that point in my life, but I was like literally sitting there thinking, I want to get a Saturn so I can go to these picnics, you know, and show up. That was actually, I got to give GM props for that. That was a cool idea for community and it was a brilliant strategy for getting people invested and inclusive in this community of Saturn owners. And I, you know, I have a soft spot in my heart for Saturn because of that. Then I actually drove one and maybe not so much, but you know, whatever. So Tom's, the huge company, you know, buy one, give one, they have a community infrastructure as well. But where did they get the value? Each one of those companies that I mentioned has a different form of community. Red Hat's communities are about developing code. They're about building projects. They're about, you know, contributory free and open source software projects. That's vastly different goals than Tom's and Charles Schwab, who are both very much in the user community point of view. So how are they going to get value out of their communities? Why are they bothering with this? And the cynical part of us can sit here and say, you know what, they're not really in the community. They're just doing this as a marketing strategy. They're just doing this to try to get people to feel good and feel nice when basically what they're setting up is a bunch of targeted users that they can get online on and monitor and track and get their habits and whatnot and figure out how to sell things better. Yeah, that may be true. Okay, the problem is this. When software companies do this with free and open source software projects, that becomes a problem. There's very little chance for me, if I, you know, my daughters buy Tom's all the time. They love the shoes, they love the idea of the buy one, give one, and, you know, they're good shoes. So they love them, but they're never going to, like, contribute a design for a new shoe to Tom's. That's not what that community is about. You know, they're going to vote with a pocketbook. So if a shoe line is successful, it's not because people participated in the creation of that shoe line. It's because they, you know, people were buying and voting with their cash. So we have to be very careful here, because there's been a trend lately, and that's sort of the origin of this talk, where a lot of companies in software land who are distributing open source code are taking that idea of, you know, community as a marketing arm, and they're running a little bit far with that. I want to be very careful when I continue with this talk. As you go, you might be hearing threads of things that, like, hmm, he doesn't like the Apache license. He doesn't like permissive licenses, because that means you, you know, companies are trying to steal things. That is actually not what this is about. I have no problems with restrictive licenses. I have no problems with permissive licenses. How you act with a license is what we're going to be kind of judging you by. You can still have full participation with permissive license, or not. Okay. But you still have to deliver value to your community, and the way, and when you do that, you're going to get full value for your company as well. So let's look at one side of this. Let's look at the business value and where they get. What does a business need when they talk about value? Well, okay, so the business value, or as far as community, sorry. So, again, and I've said this several times already, the business value for community, it's obviously, okay, one, it's good marketing. And even at Red Hat, we do this. The fact that we're, you know, over at the next building, we've got a booth over there. We've got stickers. We've got t-shirts. We've got swag. We've got brochures. You know, all these things, and all of our companies that are here are doing this. We are advocating our communities. Okay. We are, we are holding them up to the world, and we are saying, these are the communities that we work with, and we are happy to work with them, and we want you to be a part of them. Okay. You will never be able to separate marketing from community in a commercial infrastructure. Okay. It can't be done, nor should it be done. So I'm not here saying, let's just kill off this idea that community is marketing is a bad thing. It's always going to be there. That's part of my job as a community analyst. That's part of any community manager's job. If they do any form of advocacy, that is marketing. And to do that, when they do that, they're building loyalty. I'm building brand loyalty with stickers. I'm building project loyalty with, you know, hopefully a low barrier to entry for participation, and getting people good documentation so they can jump into their project more easily. And awareness, mentioned that already. Support. And I'm sorry, my slides here are very tiny, so I'm having trouble reading ahead of time. You know, that's another value for community. And a lot of software companies are actually, this is a big part of what they do with community as well. It's easier to support your software when your community is there helping. You know, if I could, you know, save a little money, and if I have an active and vibrant user community, and, you know, somebody comes along and says, hey, I'm having a problem with feature X, Y, or Z, and it's great if there's a user mailing list or a forum somewhere where I can point them and I can say, hey, you know, go here first, see if somebody's asked that same question. And it's wonderful that that question's already been answered. Your community has done your support work for you. So you've reduced your support costs. So that's a great business value for community. On the product side, you're going to get a higher adoption rate. And this is actually something, I'll be honest, this is something we do at Red Hat all the time, and this is something that Susan does, and you know, Canonical is doing as well. The more people that use Overt, which is a virtual data center management platform, and I kind of pick on it because that was my last community manager role, the more people that use that by mere attrition alone, we're going to pick up some commercial users of Rev, which is the commercial downstream. The more people that use Fedora or CentOS, the more people that we're going to see pick up Rel, which is where we sell the support for and this is where we generate revenue. I could say the same thing about the relationship between OpenSUSA and SUSA, and there's nothing wrong with that. We're all open about this, this is the thing. If you want to run OpenSUSA in the enterprise and you can do it and make that work, SUSA is all for that, you know. And if you need some help along the way, they've got the infrastructure and the ecosystem that they'd like to invite you in and be a part of their commercial product. Same thing with Canonical, same thing with Red Hat and so forth and so on. Providing a strong and vibrant community brings a definite bottom line value add as far as higher adoption rate of your commercial product, just by mere attrition alone. And you're going to see more spending on product as you go. So you're going to adopt the product later and long term, if a community is strong, we've seen evidence that you're going to end up spending a lot more spending on the product long term. Now these are actually not my ideas, Erica Cole from Salesforce, and I've got this URL, it probably won't be very visible in the video, but I do invite you to go back and look at the slides that were with this presentation and pull that URL up because she does a very good, detailed explanation of the value of community from the Salesforce side, and this is coming from a company that is not necessarily regarded as an open source company, really. But a lot of what she is saying is true for software in particular and pretty much any business, whether it's open source or not. Now the community reaction to a lot of this, and I hinted at this before, that the community is not always friendly about this, is not the most positive thing in the world. It's gotten a lot better, but in the past, I remember when 2001, when IBM started making the rounds and investing a billion dollars in Linux software development, and Red Hat was becoming prominent and Oracle was coming in and being a big player, people were very wary of business people. They wanted to stay pure. I'm going to stay with Debian because I do not want to sell my soul to you. We still see that, and I'm not making fun of that attitude at all. That is a totally valid, if you don't want to have any dealings with commercial entities, fine. Because commercial entities, I work for one, but we're not perfect. And because of our size, we can do unintentional damage sometimes, and I can respect that people do not want to be involved in that. So the community reaction to a business approach to community is usually one that is regarded with suspicion and definitely wearing us, if not outright suspicion. So we talked about the value of community as far as products are concerned. Okay. What does a project get out of community? Well, obviously growth. When you are a community manager, one of the first things you're going to try to do, if you haven't done it already, is measure the growth of your community. And that can be measured in a whole bunch of different ways. Because the idea is basically, the more your project is growing, the stronger it is. If you have people leaving your project in droves, there's a problem. And it might not even be your problem. It could be that there's better technology down the road. I don't want to really contribute to this project anymore. I want to go and contribute to project Y because I think their stuff is cooler. And then that leads to itself. Or you have people who leave where they're saying I want to leave because I don't like the way this project is run. Or I'm having a personality problem with the people at the top. These are all valid reasons why people leave. So obviously then growth indicates that your project is going to be stronger. Okay. I count on that because that can turn on you in a second. So you've got to look at trends more than day-to-day things. You've got to make sure that things are still growing at the rates that they need to be and keeping that growth rate up and running. The more you grow, the more resources you have. The more talent you have in your community, the more diversity you have in your community as far as talent and backgrounds and everything, gender, race, everything like that, the more resources you have. Cultural differences make a difference. People from different cultures and different backgrounds and different education will bring something new to the table all the time. Okay. You don't want to be like the little gated community of all one ethnic group or income level. That's boring. All the houses are the same. What's the value there? Those people seem to be happy because they're living in their little gated community. But other than you want to be a part of that, what's the value of that community really? How does that community grow? How does that community maintain loyalty? These are problems. I'm a big believer in the more you grow, the more resources you have, and you really need to have that for you. Advocacy. Okay. That's another value that community brings to a project. The more people who are using it, the more people aren't going to just be advocates for it. You know, we all, well, not all of us, I know people who don't, but a lot of us, and hold this up as a visual here, I'm kind of taped down. You know, we've got stickers. You know, I love pulling this thing out on an airplane because people, like, normal people, and I don't mean to disparage, but sometimes I call them muggles, they don't have that going, and they look at it and they're like, what are you? Because I'm kind of an older gentleman and everything like that. I'm pretty like, leave it to beaver kind of guy looking, and they're like, what, are you a hippie? What is this going on here? But this is what we do in community all the time. This goes back to ancient tribal, you know, I'm not a sociologist, but I'm sure it's just some sort of tribe. I'm part of this tribe. I've got a sticker. You know, we've got people in redhead to get the fedora tattoos. I'm like, no, that's not happening. But they do that because it's part of advocacy, and that's a very powerful reason to have a strong community and a project that helps people understand the project. Okay. So if somebody comes up to you and says, I don't understand what this does, the better, you know, the stronger, more vibrant in your community, the easier it is, it's going to be to explain it to people. They're going to have this sense of community and they're hopefully going to help people understand the project better. The other thing that you want to do with advocacy is communicate how useful it is to participants. It's not just enough for me to say that Overt is a virtual data center management platform. I need to be able to, as a community member, communicate that how useful it is to use someone outside of my community who hasn't used it. Okay. How is this going to be useful to you? Okay. And build that up and use community resources to help get that message across. And then this is really nuanced because it seems like it's the same thing. So now I've explained to you how useful Overt is. I really haven't, but we're short on time. But hypothetically, I've explained it to you. Okay. And what it will do for you, now I actually have to tell you how to use it. How do you install it? How do you get these virtual machines from one host to another? It's documentation. Okay. And that's something community also needs to bring too. So these are the three areas of advocacy that a community can do for you and should do for you if you're a project, a software project. And then the benefits of this, and this may seem a little bit familiar, just like on the business side, for the project will have a higher adoption rate if the community is strong. Oh, you know, so and so. My friend over here, he's using Debian. He likes that. He really, really likes that. It's gotten really strong. It's not as hard to install anymore because does anybody remember how hard it was to install Debian? Yeah, I almost shot my computer the first time I did it back in the early 2000s. It was very painful. But that is no longer a thing. Debian is like easy, except maybe gentoo, because I still don't understand that. And that's my fault, not theirs. More project recognition. These parts tie in very, very well. The value of community is much closer to an alignment with business side here. Okay? You get the higher adoption rate. You get more brand project recognition. Project recognition. Sorry. So community versus commercial. The age-old problem that we have. Because they do tend to be at loggerheads sometimes. And we see this a lot. It's the upstream-downstream model. And different companies are going to deal with this in different ways. It is very important, and I'll deliver this lesson from a red hat point of view. And take that as the grain of salt. Because not everybody does it the way we do. But one of the things that we have found that is very, very very important to differentiate between the work that is done in the upstream project versus the work that is done in the downstream project. And how that work is done. Okay? So, give you an example. One of the things I got to peek at my phone here for a second because I just had a brain okay, Slack. Sorry. I was trying to get the name of the app. So everybody heard of Slack as a chatting app and things like this. So actually, this is something that we're actually talking about a little bit at Red Hat. Because a lot of people, especially on the business side to sales side and everything like that, they don't really like IRC. Well, I kind of don't blame them because if you look at IRC from somebody who hasn't been using it forever, it's a really simplified arcane system. Even if you're using something pretty like XChat or something like that, you know, I'm running, I'm hardcore, I'm in IRSSI. So I'm doing command line IRC. But I get that. XChat is very limited. It's just sort of like, hey, how are you? Hey, how are you? And things like that. Slack is more interesting to people at Red Hat. And there's been a movement lately of saying, hey, we really should think about adopting Slack as an internal communication tool. It's like, yeah. And I got Slack on my phone. I use it to talk to some team members usually when we're here, when we're out at conferences, because I can't really get IRC very well like persistently. So it's nice to have Slack as a side channel where I can say, hey, we need to go to In-N-Out Burgers now. Right? Yeah, because we're so sophisticated. You know. But that's what we need it for. So we're using it, it's fine. But the problem that we're having and this fits to the upstream-downstream thing is that if Red Hat were to adopt and start using Slack almost exclusively for chat, then we would see an adoption fall-off very quickly of IRC. And the problem there is if we're running Red Hat, a domain Red Hat Slack.com, right? What happens to the communities? Okay. Because we have, we use IRC predominantly to talk to our community members who do not work for Red Hat. They are not behind our firewall. You know. They're communicating with us on public channels. If we use, if we move to a private channel that's inside our firewall, that's great for us. That's terrible for our communities. So that is a current kind of real-time example of one way you have to make sure that you keep resources dedicated focus, dedicated on the upstream and do it on the upstream first. Okay. One of the, one of the challenges we had again, Overt because I'm familiar with it, one of the challenges that we had over, we still do, is our documentation was terrible. Okay. And what was happening was we have a team at Red Hat that works on the documentation as part of our support structure. So part of the value add that you get if you buy a commercial support for any of our products is you get training, you get support, and you get documentation. Okay. But what was happening was the upstream documentation in Overt was, uh, terrible. Okay. It still kind of is. We're working on it. I swear to God. Okay. But it's bad and then what would happen was the commercial people would basically be writing the documentation product only from scratch. Okay. And it was better and they were delivering it and they're delivering it to their customers. That's not the, our customer. Sorry. That's not the right way to do that. And they know that. Okay. They know that. But then there's a couple of things. One is they say, well, they turn to the upstream and they say, well, you kind of really need to get something better because we're using Overt.org is based on MediaWiki. They were, they're using, you know, DocBook based documentation. So, um, through Publican. MediaWiki does not deal well. Because MediaWiki is a wiki and this is a semantic text language down here in the downstream. These two things do not talk to each other at all. It's, it's, it's really awful and ugly and evil. So they're, first off, they're turning to us and they, you guys need a better website. And we're like, okay. But then we're, but then we're like to them, we're like, we need you guys to actually stop writing for the downstream and start writing for Overt. And do that in the upstream. Work on that first. And then you should, if we've got the right platform for you. Because admittedly we don't now, but we're moving to it. Then hypothetically you should be writing documentation in Overt. And then when it's time to release a commercial version, you just push a button, rebrand everything and say, boom, there's your commercial version. You know. So even companies like Red Hat are not perfect here. So the important thing is two things. Know where the boundaries are between upstream and downstream. Make sure you are dedicating resources to the upstream. Make sure they're separate from the downstream. And really this is personal bias, but I think this is the right way to go. Dedicate those resources more to the upstream, less to the downstream. Let the downstream take care of itself. I think personally for me 75 to 80% of the work should be done in the upstream project. The rest should be done in the downstream as an afterthought where you rebrand everything and you secure everything and you walk orders down and do what you need to do. Another thing that we see in community versus commercial as a way of bridging this gap is the notion of open core. Open core basically says our software is open and you can have the free version, but it's not going to be as full featured as the version that will sell you. We don't do this at Red Hat at all. There are differences between Fedora and Rel, obviously. Those differences are related to the fact that we're trying to stabilize things. We got to use more stable code that is enterprise ready. Fedora is great, it's not enterprise ready. When we give you Rel, we're not handing you Crippleware. We're not saying it's something less than Fedora. We're saying this is more stable than Fedora. Open core these companies will be handing you things that are not as, they're deliberately not as feature rich. If you want these features, you're going to have to pay us money for them. A lot of people look at that and say if I know that going in I'm fine. That's cool. At least they're up front about it. They're not really trying to trick me or anything like that. But the classic problem there is this. Say I'm offering in my software the ability to have, you know, talk to a mobile app. You know. And that's part of the full featured sellable version of the program. And then along comes this really hot young developer real hot shot and she said something along the lines of hey, I know a way we can make this work. I figured this out and we can upload the code. Guarantee you what's going to happen is that the company that runs that project is going to reject that code. Because even though somebody has come along and said I can do this and I can do this much more quickly and we can talk to the mobile app and everything like that, they don't want that to happen because they don't want that in the free software version. Because then what would they sell? You know. That's the classic problem. So what's that developer going to do? She's going to feel devalued. You know. Not going to feel like her work was taken seriously. And worse for the company involved, ironically, she'll modify the code for a competitor who has a more open project. You know. And suddenly now they have that feature. Whoops! Community diversity. And I want to be very, very, very clear here. I support diversity in all forms. Race, gender, religion, whatever. But at this point, the context of diversity is how many people work on your project that work for the company and and then don't work for the company. Okay. And we have stats on this. We have dashboards on all of our the projects that are open source and standards group and Red Hat support. Okay. And I will tell you with absolutely no pride whatsoever that for Overt, again the one that I'm the most familiar with, the last time I looked at the stat, which I think was in November, 80% of the contributors on Overt work for Red Hat. That's not good. That is not diverse. Because that's a problem because that basically means if you don't work for Red Hat and you want to contribute to the project like Overt, you're going to feel like, well why would I even do this because if they don't want to see this feature they're not going to accept it because they have a plan for Overt and they have a plan for Rev and they're going to go with that plan. I will tell you that it's not true, but that's just one guy you don't know me from Adam. You're going to look at 88% of participants for Red Hat and you're going to be like, he had no he's blown smoke. So you need to try to make your community as diverse as you can and get outside people in as much as you can. And that is a very, very, very hard thing for commercial entities to accept because they feel like that is a loss of control. I was talking to somebody from Chef about this last night and he actually brought up an example where because there was because of their governance structure and some things that had happened and I don't remember exactly how this worked, but basically there was a period of time where Chef was in their governance structure was being managed by people who are not employees of Chef. You know? I don't think that lasted very long and I don't think that was like alarming. It just sort of happened and everybody was cool with it and everything was fine and then they had another round of elections later and it kind of shifted back. But think about that for a minute. The level of trust that Chef had and I wish I had more details and make the story more real but just even hearing at a cursive level the level of trust that Chef had for their community to let that happen was amazing. That would be great. I'm sure it was probably scary but wow the fact that the community was that diverse and let them happen is really, really good stuff. So the conflict, we go back and forth with this a lot. Another example I wanted to kind of give you was the age-old argument that we have inside Red Hat which is talking about, you know, our salespeople look at open source as an obstacle. And they don't really have anything against open source. It's just that if I'm going to be selling you rel and we now have direct support of CentOS which is a free version of Rel. Okay. And our salespeople go out and potential customers and the potential customer says I don't really need Rel because I have CentOS and that's the same thing and I know how to use it. Drives our salespeople crazy. Especially in the old days it really drove them crazy because it was like they had no influence over CentOS at all. It was just purely adversarial. Well, now CentOS is part of our company. You know, we have hired some of the key maintainers of that project. How does that work? Why can't we make this thing go away? You know, why can't we stop what they're doing? Well, we don't really want to because that's not how we do this. It's a nuanced approach. Salespeople, and this is where my physics background comes in, so be prepared to go to sleep at any point in this presentation from now on. Salespeople think of this as a sale as they're hitting the basket. Actually, the original metaphor I have was shooting a gun, but I thought, nah, I'll stick with sports. It's still projectile motion. It's pretty simple. You hit a basket, yes, there's skill involved. I'm not an NBA player and I will never be confused for an NBA player. But, you know, intuitively it's pretty clear that after a little bit of practice, most of us can hit some baskets, maybe not consistently well, but there's no real skill, I mean, there's no real deep skill there. You're going to need practice to do it consistently and do it better, but we intuitively, because of the way our brains work and because of spatial relationships, it's not hard to figure out if I throw the ball in a certain way, it's going to get inside the basket. The physics are relatively simple. Okay. And that is a game that commercial entities, not just sales, but commercial entities in general are trying to do. They're trying to hit that basket. In a proprietary software world, that's fairly straightforward. I have software, it has features X, Y, and Z, it costs this much. You want it or not. You know, I'm not a salesperson, so that's really not how it goes, but basically that's it. And, you know, if they make it, boom, they hit the basket. If they don't make it, they try it again or they go off and try to sell it to another customer. In open source land, when you have an open source project that is out there in the world with you that you're trying to sell into, so I'm trying to sell cloud forms in a world where there's managed IQ, or I'm trying to sell open... I'm trying to sell SUSA Linux or open SUSA. This is true for everything. Not just Red Hat. Then it becomes much harder. It becomes more nuanced, actually. More challenging. This is pool. This is billiards. This is district of billiards, and this is not even all of the diagrams that I could pull up. This is just how velocities and transfer of energy works when you hit... a cue ball hits a ball and you're trying to hit the side pocket. I don't have the reduction in friction things that you get from rolling it across the felt or making a bangshot, or I don't have the sweet spot physics in there. There's a whole bunch more physics in there. I was like, no, I'm not going to throw that all in. This is one. Because billiards is a more nuanced approach. It's not shooting a basket straight. Now you've got to think about bang shots. Now you've got to think about putting English on the ball. Now you've got to think about all these different things that you have to do to get the objective achieved. Okay. So you have to think about it in a more open and sort of a smarter way. You can't think linear anymore. Think about the value. So for us, and again to fall on back on us, the value of CentOS is not immediately clear to our salespeople. It's an obstacle. Except, yeah, but now you've got people who are using CentOS. They're contributing, they're doing bug fixes for CentOS. Okay. And they're and even if they are saying now I'm never going to buy that could change because they're using and again, I'm not trying to disparage Canonical or Ubuntu or OpenSUSA or any of those others. But let's face it, if they're using CentOS, they're one step closer to using the enterprise system that we're in. You know, and they're not going to jump ship and go over to SUSA. You know, so let's that sounds terrible and pragmatic, but it's true and they're there. You know, but those users are contributing something. The CentOS community because they're involved in bug fixes, because they're involved in feature requests and things like that, that will eventually trickle back all the way upstream to Fedora. Okay. Which is the real upstream for all of these projects. So now you've got a circle going. It's not just upstream to downstream. Now you've got actually a way back up to the upstream. You know, it's nuanced. Okay. So this is sort of where we have to kind of take our commercial companies. This is where we have to lead them. We have to say to them it's not a straightforward linear progression from build a product, sell the product. Now it's like we have to get these communities engaged and we have to make sure they're engaged. Very few of us built a town. Okay. But hypothetically let's say we built a town. We built roads. We built water pipes. We built electricity. We built, you know, we get everything. We got schools. We got the post office. We got town hall. We got town jail. You know, whatever. We built all this infrastructure and say that if you look at your community right now and I'm sure all of us, wherever we're from and whatever nationality would be able to say this is true. That you would be able to say in your community there are a whole bunch of people that just want to live there. Don't bother me. I want to live in my house or my apartment. I'm going to pay my taxes. I expect the police to show up. When I call them I expect the fire department to show up. I expect the water company to fix my waters, etc. Okay. That's how most communities are. I'm just going to be a user of this community. But I guarantee you you all know people in your community who are much more civic minded and they see something and they say, you know what, I really want a dog park here. Or I don't want that factory here. I'm going to sign a petition. I'm going to get people going. They're more civic minded. Okay. They want to change the community. They want to be a part of leading that community and not be politicians necessarily, although that is a way to do it too. But they want to be involved. They want to be active. And we as commercial entities have got to provide an outlet for being involved in that way. Yes, most people will just say I want to just be here, hang out, and be cool. Right? But some people are always going to be wanting to change it. And improve it. And you may not like the direction of those improvements, but it's sort of how it has to go. You don't want to manage a community like this. Okay. You cannot have hierarchical, top-down, you know, rigid management structures and governance. You can do that on the technical side for, you know, maintaining and approving patches. Okay. Yeah, because sometimes some, it's always going to be somebody who decides. I'm not talking about patch maintenance and technical stuff. I'm talking about governance. You can do that. Even in the Linux community, which is regarded as a benevolent dictatorship, people have voices. People can be heard. You can change Linus Torvald's mind. I ain't saying it's easy, but he's open to it because he's smart. He, you know, he knows, he knows a lot about Linux and he has very set ideas about some things, but I also understand that he's... I'm seeing changes in mind. You can do it. Okay. So commercial entities get really over-controlling sometimes. Don't be this person. You want to inspire. Although, please don't do this. Because this is... I saw this and I was like, no, this is just too happy, you know, whatever. You know, if I... this is team-building and it scares me, but it's still true. It's still true to your community because the difference is you build a community with inspiration and you're going to inspire people to build a community like this. This is not uniform. This is not necessarily pretty, but this is a community that works. Okay? If you build a community through management and strict controls, this is what you get. You get Disneyland. Disneyland is the most managed community of people on the planet. Epcot Center, very few people know this. Epcot Center was originally designed to actually be a town. It was the most planned community in the world. And it would have all these cool future features. And yeah, it would have an amusement park in the middle of it to sort of kind of showcase these things and generate some revenue. You know, Disney is all about building the strongest, you know, the most overly managed community as possible. And those who are familiar with Disney know that there's not a lot of freedom there. Yeah, there's a cool mouth, but that's all you got. So governance is key. The key to the best value and delivering value for your business and making sure that your community growth is not a grain on your bottom line just to let it go. You know, it's the line from the song. If you love something, set it free. Okay, and that will work. And that sounds cliche and corny, but that is definitely the most true thing you will have about community in the business world. And with that, I believe I've rambled on quite long enough and I have a few minutes for questions. So if everybody's awake, ask Mr. Wally. I'll repeat your question. Right. Okay. And that is value. And I'm not trying to argue that point. How is that different from loyalty that I was talking about before? Or I'm not sure I understand the nuance. Okay. I believe and so just to repeat it for the camera in case it didn't come through, I'm just talking about how inertia is part of community too and stickiness and people are not the unwillingness to change is a factor. And actually, yeah, now I get that because I live in South Indiana where it's ridiculously cold in the winter and I'm on the wrong side of Lake Michigan and I get dumped with beets of snow. Beat, not inches, beat of snow usually every winter. And yet, a same person will move. I would live here. This is really nice here by the way. Those of you who are local but Southern California so I'm rocking it out. Why do I not move? Because if I understand Stephen's point correctly, I have inertia. It's home. And I'm familiar with it. I'm going to stay there until I win the Powerball and then I'm out of here. So we're out of there. Any other questions or comments? And comments are very welcome because this is sort of a we're building this presentation. Okay. Okay, that's a great question. And repeating the question a lot of what I've said has applied to businesses that are directly involved with open source projects like this in building communities. The question was can that also apply to other businesses who might be part of such communities and how they relate and what's the value to them to interact with communities? I think that people on the outside businesses on the outside will get the same kind of value if not more being a part of a community even if they're not directly involved in it. Okay. Because you as a user you get a lot of value being part of community. You get the brand that being part of a tribe and everything like that. Whatever you want to do and I think outside businesses will get the same value if not more. If I'm a small business and I'm running MySQL as a database database server or something like that or if I'm running an email server or whatever like that it's awesome if I can be a part of a community and just ask for help and not pay anybody for it. It might not be the best help it might not be timely if I pay somebody to help me I want an answer in an hour because I got to go but if I've been part of this community as a business entity and they know I'm part of it and they're going to be more willing to help me because I'm just not coming in and saying hey I need help if I've been part of that then they're going to answer me faster because yeah this small business they've hosted our meetings or something like that. There's a lot of give and take with that kind of thing and yeah you can call it being favorite or whatever but there's a lot of you scratch my back I'll scratch yours so that's one benefit I can think of off the top of my head if you are a business participating in a community like that and you use that software you know if you're active and people know you're active they're going to help you a lot faster that's human nature kind of out of time one more question real quick right exactly and it gets back into that argument and that's a very straightforward Machiavellian argument and I'm sure there's a more nuanced way of saying it but I think yeah I think that in for penny in for a pound is a valid way of doing this well thank you all for your comments and questions and your attendance today I appreciate it go eat