 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. Dogs actually don't like truffles which is somewhat of an advantage which means if they dig you up a truffle they won't eat it whereas a pig will. However pigs absolutely love truffles. The reason a pig is a good truffle hunter and needs virtually no training is because they will sniff them out naturally and if given the opportunity will dig them all up and eat them. 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. If you give them what a truffle smells like they'll go and sniff it out but not because they want the truffle just because they know you want them to have the truffle. 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. So if you're going to attack the benevolent dictator model you need to attack it from something else other than non functionality. 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. Because you like people who look like you and if you can inquire into their origins you tend to subconsciously bias towards them and eventually they will look like you which is bad and wrong. 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. You usually with the thigh length way does because you have so much shit to deal with. 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. It will destroy the thing that your livelihood depends on. 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. I'll feed you three truffles a day or whatever I will keep my fingers firmly out of the way of your mouth and that way we will have a nice symbiotic relationship whereas if you escape and grub up my orchard I'm going to send you to the bacon factory. 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. Why the hell doesn't it work for Linux. 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. What we would call a benevolent dictator and Linux but somebody who can manage the community. 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. So I must have picked a few people off let's have the 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 that means I have to completely rebase my code every time this damn thing happens. 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. So to somebody who sits in that prison everything is a corporate problem. 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.