So, good morning everyone. Our next speaker is Mr. James Bodumli with his talk titled The Selfish Contributor Explained. Well, thank you very much indeed. So, if you attended the previous talk, Denise took us through a nice view of the airy, hopeful, altruistic uplands of open source and what it can do for municipalities. I'm going to take you on a journey through the deep, dark, motivational secrets to see me underbelly of open source, how people can actually get engineers to contribute efficiently to the open source project. I'm James Bodumli. I work for IBM as you can see from my email address. I'm actually a very old school open source person, so my open source experience actually goes back to 1982 with looking at the source code of what was then BSD. So that means I've spent almost 40 years in open source. And as a result, although my marketing department at IBM makes me put my Twitter account on the slides, Twitter for me is mostly a right only exercise. So if you expect to contact me that way, you're going to be sorely disappointed. So, I've been a container evangelist for a long time. In fact, nearly 10 years now. So containers are usually my thing and I have actually talked at FOSDAM about containers before. I have actually spent a lot of time in open source advocacy in the very early days. So I was one of the people who was instrumental in actually trying to capture what was then the open source development laboratory that was trying to co-op the Linux kernel into doing projects it didn't want and actually make it serve the open source community. So that's where I got my first taste of open source politics. And of course, I'm still technically a kernel developer. Of course, I'm now so old that nobody really expects me to write that much useful code. So I have sub-maintenors Martin Peterson. Ably looks after the SCSI subsystem and Helga Adela looks after the peer risk architecture. I do virtually nothing. I think the last few patches I did for SCSI were just some bug fixes. Admittedly for peer risk this year, I did actually make the bootloader work on EXT4, so I'm still coding there. The point is that Martin just doesn't really want to deal with the hassle of sending patches to Linux every merge window and all of the blowback that you can get from that, particularly if you're a SCSI developer. So he leaves it up to me to actually send the pull request even though he's done all the hard work of actually assembling the tree. I do have to give you a disclaimer. This talk is wholly based on personal observation. There will be a lot in this talk you may disagree with and I'm happy to entertain disagreements afterwards in the question and answer session. So this is my personal opinion and observation. It is definitely nothing to do with IBM who are not very keen on me coming to talk about this topic anyway. So let's begin with a fun topic since almost everybody in this room in some form would count themselves as an engineer. Most people would count themselves as a software engineer. Managing engineers is a hard problem and it's been a hard problem since long before I was in open source and long before computers existed. Engineers tend to be opinionated and not play very well with others. There's a very famous quote about managing engineers is a bit like herding cats. They are very difficult to get them all to line up and go in the same damn direction and actually work on your project. And obviously this means that getting engineers to do productive work can be incredibly difficult. And so managers who can actually get productive work out of engineers and propriety industry are in very big demand. That's why they're paid very big salaries. But one of the interesting corollaries of engineers is they do actually work best on things they like. So I've worked in a lot of proprietary companies doing a lot of proprietary stuff and I find the best way of actually managing engineers is to persuade them that they like whatever the project you're actually doing is. If from a technical point of view you can persuade every member on the team that actually this is an interesting and worthwhile exercise. The job of herding the cats managing the engineers becomes much easier. And if you don't try and motivate engineers with a technical motivation if you're just trying to do a sort of managerial motivation it becomes very difficult because if you go and ask engineers what their motivations are and a 10 engineer team you'll get 10 different answers and trying to satisfy all those expectations becomes impossible. And as I said this is something the industry has been struggling with for decades. I would almost say for centuries. I think this problem has been excellent for over 100 years now. So let's do an analogy from truffle hunting. I made up this slide because there's a wonderful restaurant just next door to the ULB called La Trouffe Noire which hopefully I will be enjoying myself at this evening. But the other point is I come from the Pacific Northwest and a lot of you may not know it but the Pacific Northwest actually has a truffle industry. The climate is almost identical to here and we actually grow very nice truffles. And you probably haven't heard that there is a massive disagreement between the truffle gatherers of the Pacific Northwest and the world famous truffle gatherers in France, Perigord region, everywhere that truffles famously come from. And it's this. Americans actually prefer dogs for hunting truffles. The French and in fact everybody in Europe think this is a load of rubbish and everybody should use pigs for hunting truffles. This is a source of a massive disagreement between American truffle hunters and European truffle hunters. So dogs have to be trained to hunt truffles but what they can they have good senses of smell.  However pigs absolutely love truffles.  This is why pigs make really good truffle hunters according to Europeans. Americans on the converse think that pigs are big, smelly, hard to control and actually very dangerous. So if you look at a lot of the truffle hunters of the Perigord region chances are most of them don't have ten or a significant number of them don't have ten fingers because if you actually get between a pig's mouth and a truffle and you happen to be holding it they will take the truffle and your finger off as well. So pigs are good truffle hunters because they have a selfish interest. Dogs make truffle hunters because they have an altruistic motivation. All they really want to do is please you the owner.  And the sad fact of this is that pigs find many more truffles. The truffle industry in America is somewhat small and it's for people like me who like truffles it's actually very difficult to cope with because I have to go and frequent farmers markets where the foragers appear and my supply of truffles is actually very uncertain. Truffle season in Seattle is sometime from November to March but I'm lucky if you know every other time I go to the farmers market somebody has a truffle just because dogs are not as good at finding truffles as pigs. And the point about this parallel or this parable is that a selfish motivation that the pig has if you can harness it right actually gets you far more productive work than you can get out of the dog. Even though the dog loves you to bits and really wants to please you just because the dog is not really interested in truffles the pig is much more motivated. So let's apply that lesson to open source the selfish motivation for doing open source. It's actually encoded in our cannons the Cathedral in the Bazaar by Eric Raymond contains the phrase scratching your own itch. This is the archetypal selfish motivation for any engineer to contribute to an open source project because there's something in that project they want to do add to or change. They're scratching their own itch and harnessing the selfish motivation in an open source project can actually make the cats move together. If all the cats want to move in the same direction you don't need to hurt them because they will actually naturally go there. What this means is that open source has a natural built in advantage because I'm not a manager who goes to you and says well our company business now is making food gadgets. And you 15 people are now going to be working on food gadgets isn't it wonderful rah rah rah open source contributors are self selected for liking the project. So they come to the project with a natural inbuilt desire to like the project and want to help it. And of course if the cats will actually all move in the same direction naturally it becomes an interesting question of is a cat herder really necessary. For those of you in the room who are community managers don't worry I'll give the answer later it will be yes so your job is still not in doubt. So let's look at the lessons from Linux because my history of Linux goes all the way back to 1992. So I'll do some of the early history that I wasn't actually present for in 1991. For those of you who are most of you in the room will probably recognize this. This is the original. It's not an email it's actually a news group. It was sent to the Componse Linux news group by Lina's tour vials announcing Linux the 0.01 release of Linux. Interesting things about this email you don't need to read it all I will extract the interesting bits is there is no mention of open source anywhere in this email. He actually just says it's a free operating system. He's just putting it out there doesn't mention open source licensing anything and there's no request for contributions. In fact if you read lower down what he says is he's welcome suggestions so people are going to tell him what to do and he expects to write the code but he doesn't promise to write code for all of the suggestions. So Linus at this point 1991 actually thinks believes he will be writing all of the code for Linux. You know this is his fundamental view. And of course really he's treating everybody else's users. I'm going to write the code you're just going to use my wonderful new operating system that looks quite like minutes. And obviously contributions in the shape of patches eventually did come flooding in. I actually for this talk tried to trace the first contribution to Linux. Unfortunately in the time between 1991 and us setting up the kernel mailing list a lot of the actual archives of the news groups are missing. So I have a suspicion that the first ever patch for Linux was Ted chose extended file system which dropped in the zero point one two kernel. But I have no proof that it actually is. But the point is that even though Linus did not want contributions people forced them on him anyway. And what he's discovered is the operating system grew faster because of it. And what this meant for Linus is that an open source cat heard it was actually organically born. This was something he was not expecting to do. He was expecting to be writing all the code remember. But what he ended up doing was actually herding the cats and integrating the patches. And of course now we call him a benevolent dictator. This is the standard model in open source. Let me in some of the time I have give you a little aside about why the benevolent dictator model works so well in open source because it's become very trendy nowadays to attack the benevolent dictator model because it tends to concentrate power. In people whom you might not like that much. But the reason it works so well. And the reason it's extremely common in open source is because it actually mirrors the technical leadership set up an industry almost exactly barring all of the management stuff. If you look at the technical leadership the people trying to persuade engineers to work on code that they actually would like to work on the code. The structure of an open source project under a benevolent dictator is almost exact mirror. The benevolent dictator is very similar to the CTO in what's called a weak CTO model for the industry. The CTO has no power so their job is to persuade the engineers to work. Bad CTOs can't persuade end up getting fired. Good CTOs who can persuade end up actually satisfying the goals of the company and getting big fat bonuses at the end of the year. CTOs don't do this alone. They usually have a panel of architects or an office of the CTO. So a group of people who help them which actually in the benevolent dictator model tends to correspond to either the maintainers in Linux or the cabal or whatever you want to call it. But effectively it's a head model and a group that follows them in trying to get contributions. And the reason it's so successful is because industry has been playing with this for decades. And this is the best model they've come up with for actually getting productive work out of engineers. So it's no accident that an open source it actually works very well also for running an open source project. That doesn't mean it's the only only way you can run an open source project. And there have been many interesting experiments to try that. But it does mean the model is tried and trusted and actually works.  Like I said it's well understood and well tested. And one interesting thing is that Python itself actually follows this model and Greta van Rossum recently stepped down. So Python will actually show us whether we can actually run this model with only a cabal and a benevolent dictator. The jury is still out on that one but since the model is so similar it looks like it might actually work. Like I said other models are possible but none is so widely adopted. So let's get into the quid pro quo trap. I will not be mentioning impeachment or anything going on in America here. But I did choose the title because of that. I'm sorry. I just wanted to get a cheap laugh. All projects that become popular in open source run into scaling issues. There are no ifs and buts. You go from Linus Torvalds. This is my hobby project 0.01. It's you know about 10,000 lines of code. Isn't it wonderful through oh my God I've got a load of contributions. My wonderful project is now a million lines of code and half the people on the planet are using it. And I have a huge problem accepting patches because so many people want to contribute. So all projects go through or successful projects go through a sort of please please contribute to my project. Please like me to a oh my God what do I do with everybody liking me so much. This is a scaling problem in open source. And in Linux the crisis point was actually reached in 2002 which is pretty good. This is 11 years after the initial project started up till 2002 every patch that went into Linux. And I believe you've seen Greg Crow Hartman statistics telling you today about how many tens to we're approaching hundreds of thousands of patches emerged by each release cycle. Every patch was emailed personally to Linus and personally integrated by him. This gives you an idea given the patch volume we accept today of why this model just wouldn't scale. And like I said the scaling point was reached in 2002. Linus just was starting to burn out and couldn't cope. It was called the Linus doesn't scale problem. You can actually Google for it. And obviously we blame Linus because it was him not scaling it was his fault and he fixed it with tooling. Initially we have the somewhat interesting proprietary bitkeeper episode in 2002 but ultimately in 2005 the git tool was born. And I remember those days very well because every kernel developer who was also a maintainer spent three months writing git. It was somewhat of an interesting education for us. So I think if you look deep in the bowels of git history somewhere in the git merge logic I've actually got several commits even as a kernel developer. Fixing the problem in the acceptance layer actually avoids the quid pro quo trap. So Linus didn't know it but the fact that we blamed him from the problem and he fixed it with tooling allowed Linux itself to sidestep the quid pro quo trap. So the trap is that once you run into the scaling problem the temptation is to flow control. I mean you're all engineers everybody knows that if you've got a congestion problem you flow control it. So the flow the natural flow control you would think of is you know tap the source push back on the contributors try and slow down the contributions make the pipeline flow much more evenly. And effectively the temptation therefore is to try and push the problem onto the contributors to raise barriers to contribution. So I've seen people do say things like OK but my project has this huge problem with reviewing. I'm not going to accept your patch unless I see two reviews from you. This is a quid pro quo. I am conditioning acceptance of your patch bribery on you doing two reviews. Open stack did this also for feature contributors. One of the things that opens that was very keen on with sustainability and they believe that in order for a feature to have sustainability the actual contributor of the feature would have to demonstrate they would stick around and help maintain it. In Linus in Linux we don't regard this as actually a truism as long as a feature is well written we're happy for anybody else to maintain it. So we accept well written features. We don't inquire into whether the person contributing the feature will stick around except for going through all of the code review process and having a nicely polished thing at the end of it. But conditioning contributions on mandatory unrelated actions the quid pro quo makes contributors feel used. You know it feels like the project is stealing your free time. You're not giving it voluntarily because you want to get this patch upstream perhaps your employer has charged you to get this patch upstream. So you have to satisfy this quid pro quo to get this to happen and it makes you feel very used and unhappy scaling problems must be solved in the acceptance layer. They must be solved by tooling. They must be solved by the maintainers. If you push the scaling problem down onto the contributors you're setting your project up for failure eventually. If you chanter on for a long time perhaps it will be a popular project for a long time. But the moment your popularity starts to wane as it did in the kernel a long time ago is the moment that your contributors will start to remember all of the wrongs you've done to them and start to move off onto the trendier projects. If you want to keep a committed contributor base you need to treat them well. So another problem in open source is something called the origin problem. Open source is a purely pragmatic exercise. So in some ways I would argue the differentiator between open source and free software is the motivation for contribution. In free software in theory to make a contribution you're supposed to subscribe to the say the four freedoms or the principles of software. Open source makes no such requirement. One of the interesting things about open source is that the four freedoms tend to appear naturally even though we don't require them. So there is no real daylight between the open source position and the free software position as Bruce parents will often tell you. But the pragmatism in open source means that all contributions should be considered on their merit. There are no real ways around this. This I realize is contrary to the post meritocracy movement nowadays that wants you to consider the origin of the contribution. But the problem you're setting yourselves up for is origin consideration is a very slippery slope. So fine you may suddenly prefer code from underrepresented minorities as a way of sort of it's like affirmative action. You may prefer code from underrepresented minorities. But once you start inquiring into the origins there are a whole load of senior origins that you might not like as much. And if that starts to weigh into your judgment of the code you've started to tie the project to your own personal attitudes. People will notice and eventually blame you for it. This is the origin trap. Not falling into that trap means being ruthless about considering contributions solely on merit. And regardless of where they came from. Inquiring why someone wants to submit a patch what their motivation is leads this problem and it leads to a very slippery slope. And eventually your project can stand a good chance of dying because of it. Eventually all of the contributors if you inquire too deeply into the origins will end up looking like you.  Not considering motivation actually allows us to have a much diverse base of contributors and it allows differently motivated people to collaborate. That doesn't mean that it works perfectly it obviously doesn't. The Linux kernel is still 95% white and male and there are several reasons for that. The boy culture that we had going on in the sort of early part of this millennium was a significant factor of that. But the point here is that we have deployed other means for controlling this problem besides inquiring into the origin. And these other means seem to be working reasonably well. We get no credit for it we're always held up as the poster child for the most horrible open source ecosystem. But in fact things have become much more civil and much politer on the Linux kernel list since we started to take this project problem seriously. And we've done it without really inquiring into the origin of the patches. We've done it with the help of a lot of dedicated people who sit around the project doing things like outreach and Google summer of code and kernel newbies and contribution projects that are actually designed to pull a widened diverse body of people into a project. Diversity by the way is key to a project surviving in order to explore the true problem space of what you're trying to do in something as complex as an operating system. You need people who will look at problems from very different angles. That means you need a diversity of viewpoints. Once you get a monoculture you won't explore the problem properly. Your solution will be wrong and eventually everybody will move away from your project. So diversity is actually key to sustainability and open source. It's just that you can't fix diversity by inquiring into origins. Obviously not inquiring into origins and having a load of mechanisms around it to pull lots of people in helps to keep a broad contributor base. So dealing with corporations corporations nowadays are coming to dominate open source. What I'm going to do is go back to through the Linux a small amount of the Linux history of dealing with corporations because it was very messy. And I was involved very deeply in doing that. But sad fact nowadays is that a significant amount of open source code originates in companies and not all companies have the best interest of the community at heart. And indeed if you actually consider it no company has the interest of the community at heart. Unless there is as I think Denise said a sort of greed alignment between what the company is doing and what the open source project is going to achieve. Corporations only act in their best interests. This is a truism that object is to make money. It doesn't matter how many you know codes of conduct they have how many sort of altruistic statements they make to their board. If a corporation is not making money it's not going to survive and eventually the stock market will ensure it's killed making money is key above all other things. And this is why corporations always act with a selfish motivation. All of their engagements are transactional. I presume since we're in the age of Trump I don't have to explain transactionalism. It's basically having short term goals instead of long term goals. And if the business goal changes the corporation can easily move away from the project. If the priorities change they will drop you like a hot brick and move on to whatever it is the priority is just moved for. And you won't be able to avoid this. So you just have to prepare for it. It will happen. So corporations are the archetypal selfish contributor. And this selfish contribution problem generated in sort of the 2005 for time frame some of the biggest scaling problems we actually had in Linux when Linux became interesting to corporations. We had really really huge problems. The sad fact is that selfishness does not always produce the best solution for the problem. In theory a selfish selfishly motivated person should be doing the best thing for them. But the sad fact is that most of the time they're not what they think is the best thing for them is really not the best thing for them. So part of the job of actually doing greed alignment between corporations individuals and projects is actually trying to work out what a better selfish motivation for a company would be and persuading them of it. This is why open source people who can actually make the transition to the corporate world.  It's not true. If you can explain to the CEO the marketing department and the business development people why the corporate attitude to open source needs to change. Why the greed needs to be realigned and how this will actually help all of the short term goals. They'll love you for it and they will actually change the business model of the company in order to take advantage of it. The key is persuading them that what you're doing now maybe what you think is in your own best interest. But if you just did X Y and Z it will produce a much better result for the business and therefore is much more within the corporate interest. Understanding selfish motivations and so this is the key being somebody who is capable of seeing a better selfish motivation when the people who are supposed to be the ones who understand it. I mean you don't get to be a CEO and a VP by not understanding how to align your company correctly. You have to explain to them why the alignment is wrong and how it could actually work better. And to do this you need to be a virtuoso and understanding selfish motivations. Like I said you have to work out what is in the best interest of the contributor the company whatever simply because some of the actions they're taking are often not in their best interest. I could go into lots of the tragedy of the commons details but I'll just leave you with the truffle hunting one. I've already explained that pigs make far better truffle hunters than dogs and if Americans could learn to love pigs. I would actually have a much steadier supply of truffles in the Pacific Northwest but Americans are firmly of the opinion that pigs are wrong and dogs are right. But the problem is if you let a pig into a truffle orchard uncontrolled it will first of all dig up all the truffles then it will eat them all and then it will grub up your orchard as it tries to find more and more truffles.  Controlling the greedy interest of the pig is a necessity if you want to be a professional truffle hunter. Harnessing the greedy motivation is one side of it but controlling the excesses and persuading the pig that actually if you just find me a load of truffles I'll take you to a new truffle hunting ground.  This is the way that we actually teach the pigs and obviously you have to work out what is really in the best interest of this contributor this company whatever and persuade them that it is actually in the best interest. This is a hugely tall order. I can remember back in 2005 as sort of a fairly I wasn't such a junior developer but I had no real experience of a corporation. I just become vice president of a startup company which as any large corporation will tell you is no experience at all and I had to go and explain to sort of people high up in IBM and HP and all of these sort of open source luminaries who started SDL why what they were doing was wrong and I got to say it was a very daunting prospect but learning how to do this is an essential feature of somebody who wants to actually get deeply into open source politics and motivations. The big problem was with the corporations they wanted to treat Linux exactly as Unix so they had this model of how Unix operators they just wanted Linux to operate in exactly the same way because then that model of how they build stuff would just transfer over and nobody needs to be retrained the most expensive thing in industry is retraining and they really didn't want to do this. So obviously they demanded a stable ABI and they worked with the distributions not the upstream to get their code in. The result of this was that by the end of the two four kernel cycle all every distribution this is red hat. I think Ubuntu was a bit fledgling by then so it didn't really exist but at least Red Hat and Sousa had a patch to Linux that was actually bigger than Linux itself at the end of the two four cycle just because of all the perversions that corporations had forced upon them. This is where upstream first came from because it turned out that in those days we were actually doing a twin track development model of two four was the stable branch and two five was going to be the new branch and it actually took us two years to produce two five. When time two five came out the distributions just could not adopt it with all the back ports they had to do. It became an impossible problem and it's where persuading the corporations that actually working with the upstream would mean they didn't face this cliff edge every couple of years because that was going to be our release cycle. And actually having a stable mechanism for contributing to Linux ongoing a sustainable mechanism would actually be much better for their customers rather than them having to scramble and their customers demanding to know why with all these security bugs. Are we not on the two five kernel or the two six kernel which was a stable successor that came out a year ago why are we still on two four answer because we can't up port. The point is that in order to give all these talks that I did in sort of the early 2000s I had to understand all of the motivations of the corporations and try and persuade them why what they were doing was wrong. And remember what they were doing is what they'd always done for Unix. I mean they've done this for 20 years.  This is the question they kept on asking over and over again. I mean the answer is obvious. It's because Linux is different. It's open source and the development model is radically different from the proprietary Unix one. And oh by the way the reason you want to contribute to Linux is because it offers the hope of a much more stable operating system base for your customers than all of the proprietary unices that are currently at war with each other over what they should be doing to actually capture more market share. And eventually corporations listened. The Linux Foundation was born and we actually managed to enforce the upstream first policy on the distributions. We actually formed a coalition of corporations interested maintainers distributions and the like to actually force every company that came to Linux to work with upstream first. If your patch wasn't upstream the distribution would not take it. So we get on to the biggest problem in Linux managing communities. Effectively how would you become a cat herder if you wanted to. A key goal of any community manager is to ensure that selfish contribution is enabled. And you can do this by avoiding the origin trap not asking for a quid pro quo and actually generally just assessing the code on its merits. I mean if there's a mismatch between what the code does and what the project would like it to do you can still discuss it. You can explain the engineering reasons why it would look better this way. The contributor may or may not listen but if they listen you get something better and if they don't listen perhaps they'll go away and develop another project. So there is still the RG bar G over technical vision for the project and we'll always have discussions about this but enabling selfish contributors is a key job of any community manager. And you have to make selfish contributors feel welcome. Even if you know because you've examined the business goals of this company that once they've dropped this embedded product that they need to get patches upstream in the Linux kernel for. They're just going to drop it and disappear off and do some other IoT thing that's going to be totally different possibly based on VX works. So you know there is a finite timeline to their contribution that's still not a good reason for not accepting the code. If the code works and is good and can be made to work for other people it should be accepted. Even if the contribution is selfish and time limited the code should still be accepted and the contributor should be made welcome doing it. You don't make them feel they're working for the shitty company who's just going to drop Linux and move on. You make them feel that while they are actually contributing patches and going through the process of trying to get it upstream they are valued members of our community. They choose to leave it later that will be their own choice but while they're contributing they're valued. And obviously like I said the contribution has to be made acceptable to the company. There are no ifs and made acceptable to the project. There are no ifs and buts about this. The contribution can't be maintained your project will just become an unmaintainable mess. As Linus often says it's all about taste. Finding maintainers who actually have taste and who will actually deploy that taste when accepting contributions is the key to ensuring the kernel itself does not become unmaintainable. And as I think I've said about 15 times now understanding selfish motivations is vital for all of these tasks. If you don't understand the selfish motivation for why this person is doing what they're doing. You're at a disadvantage in trying to persuade them when persuasion is necessary that if they just modified the patch slightly it would be much more acceptable to the project. So one of the jobs that all of you should look at is can you actually understand selfish motivations of people and actually the virtuoso job is can you harness them. People who can harness selfish motivations a few or far between but if you can you have a career mapped out either as a community manager or possibly as a open source CTO open source program office leader. You're the very person that industry wants you will be able to bridge the divide between the business goals and the community goals. And thanks to your understanding of selfish motivations you will understand how the alignment of those goals works how greed alignment works. And you will be able to persuade both the community and the company to do better work in the interests of the project. And obviously with the example of the pig controlling the selfish motivations can also be vital. One of the problems with the two four kernel cycle is that we did try to control the selfish motivations of the corporation by telling them that unless they worked properly with us upstream and we were not giving them stable ABI their patches wouldn't go in. So that prompt solution was just to go straight round us and talk to the distributions instead. The only way we brought them back was by blocking the distribution channel by getting the agreement that everything would be upstream first among the distributions. If we hadn't caused that to happen probably corporations would still be rooting around the Linux kernel today. Although I suspect we've found a different method of persuading them but controlling incorrect selfish instincts is almost as vital as understanding why people are doing what they're doing what the selfish motivation actually is. And obviously another key is finding better motivations for kernel for companies. If you can do this you become a very valuable strategic planner for any company you choose to join because you have cracked the nut of understanding how to do correct community business planning for business goals. Right then this is not to everybody's taste not everybody will do it but if you want to earn massive salaries and industry this is certainly one way of doing it. And one thing I have learned in the kernel is that having clear documentation about what a contribution is how to make it what it consists of how to write a change log is very helpful. Because if somebody makes a contribution that is wrong having a document point to that says OK there's a problem here because you haven't done this this and this. It's really helpful in convincing the person on the other end of that email that we have truly thought about this problem. Having documentation means that we have thought about it and we have something to point to that says we've thought about it. And we're not just beating up on you because we don't like you it's written in the document here and we'll enforce it for everybody. It actually contributes the sense of fairness in the project. And clear documentation should detail both getting better patches and setting expectations right. So your expectations about how the patch will be accepted how much pain you're going to go through and how long it will be before the patch appears in the kernel is vital to actually setting the expectations of people. So they if their contribution takes longer than they expected to get upstream they can actually become bored and disillusioned and drift away having a document that explains how long this might take helps combat that. And obviously in almost all contributions especially if you're a first time contributor contributions always need modifications. However one of the things you can use these modifications as is a learning exercise for the contributor. So instead of just pushing back and saying read the documentation and do it better you explain why it's done wrong. For me the standard bug bear is writing commit logs apparently nobody in the universe can actually write decent commit logs everybody wants to document how the code works. I am a programmer I can read the code reading the code tells me how it works. What I want to know is why is it doing what it's doing. That is what the commit log should tell me it should tell me the why not the what. And eventually with a lot of contributions. Thank you. With a lot of contributions to the system I simply end up giving up and rewriting the commit log and saying this is how you should have done it. It's my job as a maintainer to do that so it's not bad. And explaining to the contributor why this is in both their interests and the community in the code basis interest is really important. Aligning interests is key to harnessing selfish motivation. With that I think I got a few minutes left conclusions are. Harnessing selfishness is an absolute essential for getting maximum engineering profitability. Open source is about 70 percent of the way there because of the interest alignment but getting it the other 30 percent of the way there requires a cat herder.  Understanding the selfish motivations is vital for helping contributors be successful especially if those contributors are coming out of corporations. Primarily because just because they're acting selfishly doesn't mean they're acting in their own best interest and it might be your job to explain to them what their best interests are. And it's obviously this is a vital skill for managing corporate contributions. So with that I will say thank you if you enjoyed this this is impress.js my own personal modification of it patches should be going upstream probably never but I will try and do better. Obviously it's written in HTML which makes me a web developer. The entire talk is actually available on my own personal website under impress slides. And with that I will just say thank you and call for questions.  Hi James thank you for the presentation. I have a question about how company can plan for the big changes in upstream kernel for example. So what is more more welcoming way to do that is to prepare the changes and push everything. Send send a lot of patches or to when you know that you have a problem to arrange some kind of I don't know discussion about the possible way how to solve the problem to get all the I don't know opinions. So what way is more efficient for a selfish contributor. OK so first of all you have to appreciate that every open source project is driven by contributions. And so the contributors of the ones that actually in a correctly run project drive the direction of the project is going in sudden changes in direction because of this drive are not unusual. And those sudden changes can stomp all over patch sets you have if you are a large company the way you avoid this is to be one of the people actually driving the changes. If you have a lot of if you deploy a lot of contributors to the ecosystem and you're actually in charge of driving the project it can actually help keep it stable for whatever contribution you're doing. If you're a much smaller company you're at the mercy of what's going on inside the project it's still not an impossible position to be in but eventually you just have to become good at rebasing. I've got a few patches for the TPM subsystem that have been languishing for about five releases and over those five releases they keep on changing the locations of all the code.  So being good at rebasing if you can't afford to deploy a massive army of contributors is really the only way that you will actually cope with this. You're not going to stop the runaway train of a project that's changing direction and changing APIs constantly. You just have to cope with it. Sorry I just want to say to everyone in the room can you please be as quiet as possible. Please I know everyone's very busy but everyone would like to hear the speaker on stage. Thank you. Well okay I suppose we started late so we get some chance of finishing late. Thank you for the amazing presentation. There are definitely some parts that I disagree with but what I do want to focus on is the selfish motivation. It seems like it was very much of a binary either or it was the dog or the pig. And I'm wondering what are your thoughts about innovations in selfishness because it seems like you talked a lot about corporations. But I think a lot of times developers do not capture as much value as they can for their work in corporations. And is there another future model of selfishness. Okay so thank you for the question. It's actually a great question. The reason I presented it as binary is because it makes for a much more interesting talk. But the truth is that it's not either or. What actually happens if you align selfish interests correctly is that a form of altruism does appear out of this. Because suddenly it becomes in your interest to actually help the project. Once you've got the agreed alignment done and everything's working correctly and you've got the best business plan you can get out of all of this. You actually find that your interest and the project's interests match each other for a long step of the way. And you might be doing this for a selfish reason but you're doing it helps the project. And as far as the project is concerned helping it is an altruistic reason. So this is where once you get the alignment correct selfish motivations and altruistic motivations somewhat merge. So there's always an ideal mix between the two instead of waiting for it to sort of appear like some renormalization transformation. If you can persuade your company to start from that position chances are they'll reach the plateau much faster. But the plateau can be reached whether you start from pure selfishness or whether you try and incorporate altruism into what you're doing. So this is really a question about open source sustainability. So just to go back to the bit of the question where you asked why I concentrate on corporations. And the reason is because I'm problem driven most of my problems are caused by corporations.  But I agree absolutely with you that harnessing selfish motivations for individuals as well is also important. I did touch on that. It was I think only the latter part of my talk that really became all about corporations. But remember that in Linux we got our baptism fire of how to cope with this from the corporations. And that that means it's a feature product of my upbringing. So it's in my DNA so to speak which is why unfortunately I phrased everything like this. You're welcome. And I think with that another question I promise it's interesting. And so I found your talk specifically on talking about diversity in teams and in open source projects being really important. Understanding both the problem space better but also having experiences that people can draw in to fix problems in that space. Given that I was interested that you spoke out against things like positive action. And I wondered what your thoughts are on maybe not considering that in the origin of contributions. But actually when considering when bringing new maintainers on I suppose you could call it positive action. The other way you could look at it is valuing the diversity of your team in and as of itself somewhat like maybe you were putting together a football team. You wouldn't want the 11 best players. You want players that work together to maximize that space. OK so I did say that you should never examine the origin of the patch. So in that sense I was against examining origins. But I also said that the way we solve this problem in Linux is to put lots of structures in place around the ecosystem that actually try and encourage a diversity of contributions. So I'm not completely against positive action. I just think that in terms of patch consideration the positive action has no place. The positive action should occur in the encouragement of contributions outside of the sort of laser like focus we have on making sure the contribution is technically correct. So what I was trying to do was separate the motivations. I didn't mean to imply that all forms of affirmative action are wrong because that would have me shutting down the outreach project and Colonel newbies and everything else that we do to help the ecosystem. We need as I said a diverse ecosystem encouraging diversity in the ecosystem through external means is absolutely vital to maintaining the sustainability of the project without a diverse contributor basis. We don't have enough diverse thought to explore all the problems in the operating system problem space and without the ability to explore the problems completely and correctly will come up with the wrong solution. Diversity is vital for preventing us falling into that trap. Okay with that I will say thank you very much.


One is going certainly to be discussed is the whole issue of carbon market and what is called the Paris rules book, which is in fact the set of regulation or rule or framework that have to be used to implement the Paris Agreement. And then in the Paris Agreement there is something also that is called the ratchet mechanism that asks the countries to revise their nationally determined contribution every five years. And we are now five years after the Paris Agreement. And this is where we expect to have the countries raising their ambition in terms of climate goals, in terms of mitigation and adaptation. But this is another topic. So we have the carbon markets and the rule book for the Paris Agreement. We have the climate ambition. So as it is now, we are not going to fulfill the 1.5 degree targets. So we need to increase our ambition. The developed countries have promised to the world that they will deliver 100 billion a year in climate finance. And this was in 2009. And as of today, we are still missing something like 20 billion. I think in 2020 it was 80 billion that were mobilized. So we are still missing. So there is still this whole issue of climate finance that is a bit of a sore point in the discussion. Two other very important issues, but probably going to be very difficult also is the whole issue of loss and damage. And we have seen in the last few months with the various catastrophic events, mega-fire flooding in Europe and other places, landslides, everything. Climate change is already upon us and generates a huge amount of damage. And the question is who is to pay for this damage? And then of course, developed countries say, or don't say, but say that everybody is on its own. I mean, if something happened in the US, the US is paying for it. If something happened in India, India is paying for it. But the developed countries say that, well, that's not fair because some countries are more responsible historically than others in terms of climate change. It's also very important is the whole issue of equity, climate justice. And let's start by understanding that a ton of CO2 emitted by an indigenous people in the Pacific Island or a ton of CO2 emitted by a stockbroker in New York is still a ton of CO2. So in terms of climate change, they have the same impact. On the other side, I mean, I thought the indigenous people in Pacific Island are emitting much, much less CO2 on a capital basis than someone in the US or in Europe. And they are not the same and they are not the same impact on climate change. So the question is, what is the fair share of things that should be done by globally the developed country and the global south of what is called in the negotiation the developing country. And that's a bit of a sore point. And then ultimately, I think that's the main point. And I don't know if it's going to be a discussion is the whole issue of the ambition are serious. We are everybody recognize that natural best solution are very important planting trees or growing trees is very important. But it's not going to solve the whole climate problem unless we solve the first issue consumption issue. And here you can make a quick comparison. The developed world has promised 100 billion per year in terms of money to fight against climate change. At the same time, the same developed world is subsidizing the fossil fuel industry at the rate of $1 million per minute, which is about the $100 billion that I think is rich about in a week. So we spend in a week as much money in subsidizing fossil fuel that we are supposed to spend in a year in terms of fighting climate change. So unless we change and we put these priorities in the right order, so we should spend more money to fight against climate change and help developing countries and support whoever wants to rather than subsidizing for this issue. We may talk a lot at the COP, but ultimately end up with very little on the ground. The sort of the five I think important topics and there are many others that we probably will discuss, but these are critical and these are topics that will be very difficult to get probably an agreement. What we can do is certainly a contributing and by providing evidence, people need evidence to take decisions and otherwise decisions are taken on the whim or political agenda or short-term interest. So and that's what C4Ecraft is doing is that we provide evidence in terms of who is emitting and what is the justice and how can we involve, I could be more inclusive and involve all the stakeholders and I say that it goes from the indigenous people to the industrial sector because if we don't manage to involve everybody quote-unquote the good and the bad or the ugly, we are not going to sort out our problem and manage to reach a solution that is agreeable. If we succeed in keeping the global warming in this 1.5 to 2 degree, I mean everybody will win. The question is how do you pass the vested interest, how do you remove the incentive and that is all things that we are working in terms of doing research at various scale, at the local scale, at the regional scale and at the global scale and developing tools, developing monitoring tools, developing assessment tools, contributing to assessment like the assessment of the New York Declaration of Forest and so on. This is our main contribution and I think that if people are willing to use and consider what we are telling them, what we are producing, what we are showing, then that may help in the negotiation because it's much more difficult to refute our fact and to argue with people based on dogmatism and perceptions.


For a lot of you guys that were here before I got here and any of these coaches got here. This is the 200th win in Tennessee Titans history. Let's be grateful for the ownership that we have. They let us do our job. They're gonna support us. It's Joe Blitz. Here they come. Sack! Simeon under pressure. Sack! We are into the first down. Keep swinging and do it together. Do it together. That's the way to fight away the win. Right, took everybody. Wasn't pretty, but we found a way to win. Let's go. Titans on three. One, two, three, Titans. I'm Mike Diep and this is the Mike Gravel Show. The Tennessee Titans are 8-2 after a two-point victory over the New Orleans Saints on Sunday. The team gave you everything they had in a battle that you knew you were gonna get. Sure, absolutely.  And you get these stretches here after the halfway mark and they're beat up and we're beat up and they're playing different guys. And, you know, that's the time of season we're out here in the national football league. All right, so we've got two six-packs. We're gonna run the first one here and these are some of the biggest plays of the game, starting with a 50-yard pass to Marcus Johnson. Yep, it's great to get these catch and runs. And right here, right, we're an empty, we get an attacker, man coverage. Marcus is able to get inside and Ryan's able to catch him on stride. You know, Nick Westbrook's there is trying to get an extra block, not really sure where he's gonna go. Just get on him, Nick. Don't worry about directing traffic. Just get on him. Let Marcus or let the guy with the ball to side. But, you know, you could see a throwing lane, clean pocket, you know, they bring five and they're in post-safety, man. So we're able to gain a huge player in that situation. Ryan does such a good job throwing it where the guy can catch it and then run with it. Well, that is, that's key, you know. And then we have to do a better job of that. There were some throws that, you know, we'd like to be in better placement and, you know, receivers gotta make the quarterback right and the quarterback's gotta make the receivers right. Okay, this throw was pretty good on a trick play. Let's take a look at Adrian Peterson in the Wildcat and then a handoff. Yeah, just a little trickeration here, trying to hit a shot down the field, but, you know, at worst, it's still a, still an explosive gain there to find an AJ. You know, this is a good front.   They're longer, athletic and, you know, hopefully we get a little better ball and we give Ryan a little bit more time. But, you know, it was something that we felt like there. We could take advantage of the situation and try to get one over the top of them, but, you know, it didn't work like that. So we just, you know, took what we had and took a huge gain there down to the fringe. 16 yard gain. Titans were leading 13 to six at the end of the half when the Saints moved to the Titans 35 with exactly a minute to go and then the defense come through first, Jeff Simmons. Yeah, well, this is a, you know, a good call. I thought this was a good call here. We pressured and Elijah's in there battling and then again, that's, you know, Jeff does a lot of creating his own stuff. And this was other guys creating. There's Elijah making a move and the good coverage. And, you know, there's a lot of guys doing their job for a quarterback to hang on to it that long. So the clock keeps running because the Saints are out of time outs. And so they've got to get back on the ball. They snap it with 38 seconds to go and yet more pressure and another set. Yep. You know, Harold tries the edge.   And that was the case there. And it felt like we handled that situation really well, you know, really well made them get them out of field goal range. And then five seconds left, they ran out of time there to try to get into field goal range. Stays 13 to six as we move to the second half, the Titans get a takeaway that we'll see later and they cash in with this pretty touchdown pass. Yeah.  And, you know, Ryan was able to give him a perfect ball there for a touchdown. Third touchdown catch of the year for Michael Pruitt, tied for the team lead, continues to make things happen when called on down around the goal line. The Titans defense had to be counted on down around the goal line at 23-21, a minute 16 to go. The Saints go for two. Here it is. Well, we backed them up, you know what I mean? We had a nice play there to get them to a false start. And then, you know, this is a matchup they had been taking most of the game. And so the quarterback felt good about it. You know, but Jayon was there. He was ready to go and did a fantastic job of covering his man there when we call that gotta have it situation. Jackrabbit Jenkins also coming over in coverage. Titans win 23-21. Those are some of the key plays when we come back a six-pack of guys whose names you need to know from the victory. That's next when the Mike Grappler show continues. This season, due to all the injuries, the Tennessee Titans have currently played 82 players. That's tops in the lead. I didn't know that that was a stat. Okay. I guess it's okay to be number one on that stat. As long as you're eight and two, it's really good as a matter of fact. Okay, so here are some of those kind of guys who came through in the Titans victory over the Saints. Names that maybe last spring or even during the summer, early part of the fall you didn't know. Let's start with Nikwan Jones in the defensive line. Yep, that's the player that started on the practice squad. You know, it improved and we brought him up and it's a really nice pass for us move when he's into the pocket quickly. And, you know, that's just, it's the guy that's transitioned into the pocket. You know, right there, that's the easiest way and the quickest way to get to the quarterback. You can see a really nice move and being able to bring Trevor down. Jeff Simmons said he was very proud of Nikwan for that move. Oh good, I'm glad Jeff's so proud of him. That's okay. Now, speaking of Jeff, Jeff Swame is a name. Maybe you knew it tight end, but gosh, he's caught four passes in each of the last three games. Here's a 16 yarder. Yeah, I thought this was a well-designed play. We just need some extra blocks down the field here. You know, AJ's got to be able to block better when he doesn't get the ball. We always talk about that, but I thought this was a well-designed play. I thought Taylor did a nice job of coming back here, sealing the edge right there. Ryan, one of the edge, you could have taken it. A lot of guys open right there. Prue's open and, you know, just catch the ones they throw to you as a tight end. All right, so two guys on this play, whose names you need to know, Dylan Cole and then Tori Carter. Cole with the hit, Carter with the recovery. This is the second half kickoff. Yeah, we're looking for speed here and nothing changes the game like a kickoff fumble on special teams. Fumble recovery. Dylan's double team, that's him getting up off of it, makes an excellent hit. You know, a good hard legal hit and Tori's running to the football and good things happen when you're around the football. But, you know, they double team. Dylan Cole, he was on the ground, gets up and you can see it put his face mask and his helmet right there, great tackle and guys running to the football and a huge recovery. Tori's in there. He has to fight for it. There's a skill to getting a fumble. Sure, there's some stuff going on down there at the bottom of the pile that it's probably not safe for work. All right, so how about another Marcus Johnson shot? Marcus Johnson, a guy that was cut by the Colts early part of 2003, signed by the Titans right before the Baltimore playoff game, played well in the preseason, hurt and a big game on Sunday.  Ryan does what he always does, standing in there, getting hit. We got to protect better. But this was, I thought this was a great job by Marcus, by creating separation. I mean, this is man coverage. You know, he straightens the guy up, his physical comes over there and, you know, he wanted to score. You can see that he wanted to score and he's starting to build some confidence. So, you know, that's a great thing to see. We're going to need to see more of that on Sunday.  You know, again, I thought this was a well-designed play. You know, Ryan being able to pump over there to AJ, great blocking down the field. And there's Deontay, there's guys getting extra efforts, stays in bounds, come back, get us a couple extra yards and, you know, that was a huge ex-play there, well executed, well blocked. You can see Ben out there getting the linebacker and let us get the play started. Crew on a second level. Here comes Big Rodge cleaning up whatever's left and Deontay running with it. Rodger Saffold is always hustling. I would say most of the time. We all need to hustle a little bit more. All right, so let's take a look at one more hustle play. Who else but Nick Westbrook Akita, who makes the play on the onside kick, never any drama with NWI. Nope, he just does his job most of the time and that's always great to see. We put the guys out there that we trust and, you know, Nick's got a block. If the ball's passed him, if he feels like he can recover it, we trust him to right there. High point it. Mathias Farley coming over there and cleaning up and protecting him is something that's going to go unnoticed but that's a huge team play right there. Him hustling over there to take some steam off the guy that's trying to hit Nick. Smart player. Absolutely. All right, speaking of players, how about naming a Titans player? That's right, ladies and gentlemen. It is Delta dentals. Can you guess this Titan? Let's take a look at the picture.  No, it's not. Don't say that. Well, the people in Delta dental. No, no, no, I love Delta dental. I know you do. The pressure of this game. But it hurts their feelings. They think you love this. All right, we need to go to break. When we come back, Mike Grable will attempt to guess this Titan. Oh, I know this one. Okay, all right. Wait till after the break, it's a show. Mike Grable show, continuing next. Mike Grable show continues with Delta dentals. Can you guess this Titan? He was happy during both of the six packs, especially the second one, because you get to recognize a lot of players. Now we're to Delta dental. We're to the segment. If he gets it right, he's generally happy. Mike Grable, are you gonna be happy? Yeah, of course I'm gonna be happy. This is the best part of the show. Six packs are great, Delta dental better. That's rookie Monnie Rice. Monnie Rice from Huntsville, Alabama. Is that right? It is.  That picture of Brett Kern is with him and Kern. Him and a Titan of Jersey and Kern kicking in that game that he was at, it was precious. How special would that be to play for the team that you followed that with? Well, you were a Steeler fan. No, I was a Browns fan. You're Browns fan. I was a Browns fan. You don't live in Akron, Ohio. Okay, but your grandfather was a Steeler fan? Well, from Pittsburgh, so more of a Pirates fan. And then obviously when I played for the Steelers, that made his day. Still, to get to do that when you've grown up a fan, so special. Right, especially in that area. And then, you know, I'm sure Monnie's family is excited. And being a few hours away, they'd come up here and watch him play home games. And, you know, he's really starting to develop, made his mark on special teams, started to build some confidence, got an opportunity at Limebacker, played and was productive against the Colts, helped us win. Got another opportunity to hear this past week. And so hopefully we can start stringing some weeks together. And Dave McGinnis on Titans Radio loves Limebackers. You know that because he coached him for years. He says this guy's got a GPS and he's got some juice. He does. He can run. He sees the ball and he goes and gets it. And there's some, you know, obviously always some things that we, you know, there's a lot of adjustments that go on during the game. But, you know, felt like Monnie, when he sees the ball, he goes and gets it. He plays with great speed. And I think he's only going to get better. Good player, Monnie Rice, rookie out of Georgia. Two of the last three games he started this past game, he made 10 tackles against the Saints. When we come back, two of the biggest names in Titans history to be honored this Sunday, they're part of Amy Wells Titans Files. Sunday at Nissan Stadium, it's not just a big AFC South matchup between the Titans and the Texans. It's a day where the Tennessee Titans will put into their ring of honor two of the men who helped establish Titans football in the Mid-South. I'm talking about Floyd Rice and Jeff Fisher. As Amy Wells delves into the Titans Files, she goes and gets an assist from our in-house expert on both Fisher and Rice and what they meant. In 1994, Floyd Rice was a rookie general manager with the Houston Oilers, and he inherited a mess. The NFL had installed a salary cap that year and the Oilers had not prepared for it. Most of the team's best players departed and Rice basically had to start over with the club's personnel. He made a lot of decisions in his first season as a general manager, but the best one might have been choosing Jeff Fisher to be the team's interim head coach and then making him the permanent leader. The Rice-Fisher combination would face challenges, especially a move to Tennessee that took four years to fully complete. Let's get up! We got a little up here. But the duo persevered, and by the time the Oilers became the Tennessee Titans in 1999, the two men had the franchise ready to go to new heights. Over the next five years, the Titans would win 61 games and made NFL fans of people all over the mid-south. TennesseeTitans.com senior writer-editor Jim Wyatt covered it all, and he is quick to credit Rice for the talent that he assembled. I think Floyd Rice did a really good job of finding the right players at that time for this organization, and God bless him. He did his best to keep that group together as long as he possibly could. Pre-struction deals, knowing that at some point things were gonna have to change, but just look at the long list of players that he brought in here and his impact and keeping those teams together for so long. I mean, Floyd was a football guy and loved it and loved the scouting part of it, loved building teams, loved working with Jeff Fisher together. And yes, Jeff Fisher deserves a lot of credit for the successful run, but Floyd Rice helped build those teams. I'm very happy he's getting recognized for that. Jeff Fisher has been recognized for the 147 wins that he totaled in his 16 plus years as the franchise's head coach, but Fisher was more than the Titans head coach. He didn't just win games. Fisher dove into middle Tennessee in a way that no one could have imagined. He became the face of the NFL in the mid-south. He was out there in the community. He was trying to generate some buzz with the football team, building a program at the same time. Ended up getting this team to four playoff appearances in five years, two AFC championship games, a Super Bowl, and at the same time, built a fan base that is strong and large part because of the work he did back then. It was a stick-on details and had people in place that helped him do it, had players in place that had his back at all times. And there was a culture when he was a head coach, certainly during the successful run that wanted to fight for him. We lost Floyd Reese to cancer on August 21st, and everyone is crushed that he won't be there on Sunday to go into the ring of honor with Jeff Fisher. They didn't always agree, but with years of hindsight to draw on, it's apparent that this was a great duo. Floyd Reese and Jeff Fisher made the other better and in the process made the Titans special. I mean, they had different personalities. And yeah, maybe they did butt heads on some draft picks and some personnel moves, but you always got the sense that they were in it together and in it to win together and had each other's back at a time when everybody was trying to pull the weight the same way. So I have such good memories of both of those guys, what they did for this organization, what they did for this community, and what they did for the NFL. I'm happy to see them recognized. We can't wait to see them put in the ring of honor on Sunday, and we can't wait to see the Titans try to go to nine and two. The Nissan Keys with Mike Vrable when the Mike Vrable show continues. Time to dive into the Nissan Keys to this week's game, the opponent from the AFC South at Houston Texans. Their record, not stellar, but they've certainly done some good things, particularly on defense. And that's why key number one is about cleaning up the offense. Yeah, just the operation. We have to be better operationally. We have to get out of the huddle, see what's going on, make our checks, make our calls, and play with better fundamentals. This is the time of year where guys are beat up, guys are banged up, and we have to play with better fundamentals. We have to catch the ball better, block better, try to take care of the football better, ball security, this team has caused fumbles, it's gotten turnover. So if we're sloppy, it's not gonna be easy. And you want red zone offense to execute better as well. Well, we always do. We took a step back against the number two red zone defense in the league. And so, we knew that it wasn't gonna be easy, and we didn't make it easy on ourselves because just too many self-inflicted wounds last week. Okay, I'm guessing that key number two in the Nissan Keys has got to be something about defense, right? Well, yeah, it's about force and negative plays. Sacks, tackles for loss, turnovers. We've got to cause more fumbles. We're playing okay defensively, but we're not knocking the ball away from anybody. We got to start hitting people in a manner in which the ball comes away from the body. And like Dylan colded on a kickoff. All right, so let's talk special teams. Titan special teams have been very good overall this year, Nissan key number three, dominate field position battle on special teams. Anytime that you can go shorter rather than logger on offense, that's a good thing. And when you make them drive the football, that's more opportunities for your defense to make some plays. So I would love for us to build on this special teams performance that you and I have talked about from last week, get these returns going, get these kickoffs outside the 30 and really start to compliment the offense and the defense with our special teams and tied all together. Brett Kern, Penzem, Chester Rogers comes up catches, punts, return punts. Marcus Johnson, a nice job on kickoff. He did, we covered everybody up and he hit it. And you know, I didn't think we did much on the first one, we were out to the 31 yard line. So just by not having penetration on a kickoff return is gonna help us get these things started and get the ball outside the 30. So good to be at home again. Yeah, it is good. No travel. Two weeks in a row. No travel, no long travel. Go get them. Thank you, Mike. Titans and the Texans this Sunday at Nissan Stadium, you'll be able to hear it on 104.5 the zone beginning. The Titans countdown at 11 a.m. That's Amy Wells and Rhett Bryant. For Mike Vrabel, I'm Mike Keith thanking you for joining us for the Mike Vrabel show.