Google I/O 2008 - Open Source Projects and Poisonous People

okay so now we have a nice dark place for everyone to take a nap or after you know we're going to get up here and talk a little bit about poisonous people my name is Brian Fitzpatrick Fitz my name is ben collins-sussman you can call me ben collins-sussman and we've been speaking together for quite a while working at open source for at least 10 years or so and yeah I like the title of our talk poisonous people was suggested to us by another conference I think because it was way more scandalous sounding but we had a bad word to start with well it was going to be you know if we had never talked how to be nice and get along with people but probably you know wouldn't get as big a crowd but poisonous people sounds you know everyone's worried and I the poisonous person so so we're hoping we hope you get something good this is not a this is not actually a primer on how to be a poisonous person that's a different talk entirely but we hope you guys enjoy talk have you guys been enjoying the conference so far Jesus sorry can anybody still hear me after that so we're going to get started here but before we start we want us to say that these are our opinions if you hold different opinions we're perfectly glad to hear that and we invite you to get your own conference in your own talk we want to remind you that there are many ways to run open source communities this is our preferred way a and B we think that this is the way that sends the most energy and actually writing software as opposed to yelling screaming each other and disagreeing most of the time we're also not making this up we have a lot of experience working with open source and open source projects while you might be making it up by but we have seen a lot of open source projects come and go so we're tourists are trying to relate our experiences particularly with the subversion project because that was sort of our biggest experience and but which is kind of neat because the subversion project we were founders and developers of the subversion project worked on it for many years with a guy named karl fogel a good friend of ours our result of this project was to turn around and make a talk about some of the things we learned in community management karl turned around and wrote this fantastic book all about which basically the same content as our talk to us in a lot more detail so if you like what you hear today go check out this book it's actually you can buy it O'Reilly from O'Reilly and hardcopy it's also under I believe it's a Creative Commons license it's free free up on the web it's reason book right so yeah Karl's book and our experiences are both again based on what we've done with subversion as well as the Apache Software Foundation so this isn't just stuff that we made up over a weekend it's actually based on some experiences and we're hoping to relate this through a series of sort of anecdotes we're going to tell tell some basic stories about different examples of poises people we've encountered it how to deal with them but there's a few parts to this basically you come across a poisonous person first you have to understand what you're dealing with okay how do we how to fight against it or how to protect yourself against it how to identify poisonous people and lastly how to disinfect your community from a poisonous person the four sections the four so it's just an exception one understanding the threat to your project so you know open source software Ori this doesn't even have to be able to be any any software development the thing that is the most important to your project is the intention and focus of your community what we mean by that is you know if people are busy arguing or fighting you're not going to get anything done and so there's a continuous tension trying to find a balance between getting consensus and having discussion right and at the same time making progress as well well if you had or if you had some sort of group of people and you had a pile of money in the middle of them that you keep contributing to and someone came in the room and started taking money out of that pile I think it'd be a little bit annoyed in fact you might call the police or provide bodily harm to them attention and focus it are the assets of an open-source project they are the sort of common currency of an open-source project if you will and when we talk about poisonous people in this case we're talking about a people within your community but be people who may come from without your community and who want to distract you but what do these people do okay they cannot show all these bullets I like them to all the bullets at once I do like there you go so alright so it was just forms of draining attention right distracting you draining you causing infighting they're all things that you see happen before they I was a victim of them I'm here to tell my story I've been and and most importantly the thing that they can do sometimes they don't even realize that they're doing it for example I mean it sounds like we're talking about trolls but it's not always the case for example sometimes you have people who are part of your projects valued community members who are the nicest people in the world but they happen to be perfectionist or obsessive-compulsive and what they end up doing is they sort of get bog you down and discussions about what should our process be and how are we going to resolve this and you maybe you post a design question or design document and you know sure you're going to have some discussion normally you should have some discussion but these people these perfectionist though they'll actually just engage you forever it's to the point where you realize this is never going to terminate right and at that point you have to sort of disengage yourself right and move forward and since the example of this is one of those versions developers who's a really good guy contributed a lot of great design discussion but we started to get frustrated after a bit because we're just like Cuddy just weren't we ready to get coding he just wants to keep talking about this he just wants to keep going and we finally realized that he would never actually stop talking about the design for this product project or this particular feature and we just we were trying to think about ways to do it we decided let's just try saying okay we're done we're going to move on and write code we did that and he was okay with it he went on but he would if he hadn't done that he would have just kept on going for the rest well I mean a typical way to end that conversation is to say look we're going to try this and see where we are yeah exceeding the reevaluate from that point right it's a nice way of failure is an option daily your visit option don't get me no work at NASA right so uh fortifying against the threat so well how can you protect yourself from poisonous people or your community more or your project the first thing to do is is build a strong community and we recommend building a community based on four things that we're going to talk about overseas the four four cardinal virtues politeness respect trust and humility and those don't really form a nice like acronyms like so we're going to try and get something in there with an A but you know he had a little trouble with that but so if you build your community based on these things you actually are going to be much more likely to be able to successfully repel people who come and try and prevent you from doing this as well as attract these people people who are similar to that one of the things that people who are everyone you're communities following these virtues somebody comes in isn't they stick out like a sore thumb although it doesn't seem to work the other way right if you come if a really nice person comes to a an angry screaming community they tend to just get ignored they tend to leave quickly or they'll come it in the first place all right so there's a couple of best practice even there we're not big fans of the whole you know that's practices thing I don't know what else to call it the first thing is to have a mission and this is another thing that scares people corporate doublespeak mission statement everybody run away quick but there's two parts of this okay pick a direction and limit your scope this seems really obvious I'm sure everyone's saying of course but it it's amazing how people don't do this to say we're going to write this piece of soil I was saying this in another talk we gave earlier today that there's a lot of projects if you go up to star stores your Google code you'll see a lot of projects where that's just somebody says hey I'm going to the projects basically one person and there's like a design doc that's very vague since we're going to write the best video game ever and there's there's it's so vague it's just like you know it's like a list of sort of general features of things that person thinks is cool and nothing ever happens right because either even nobody cares and nobody needs any attention nobody comes like or if people do come by to participate in the discussion there's no scope limiting for the discussion so everybody just starts having these blue sky conversations about what they'd like to see it be and you never get or you play that you play the bring me a rock game with the pressure you say I want to write a Space Invaders knockoff and the person said it wasn't really what I was thinking of and they're like okay well do duke nukem the guys either yes and yeah it's just keep guessing what I want type of a thing and so it's basically communicate this save yourself a lot of time and energy well so subversion is a great example the very first thing we did when we put up a website for subversion was we said here's our mission and it's a very narrow scope we want to replace CVS that's what everybody in the world was using well at least all the open-source communities for this is that we it gives us a metric for success for success right and also instantly if people aren't interested in replacing CBS they don't come knocking on our door or if they do we point through the website and we say hey look this is our mission sorry I know you want to write something slightly different but what we're doing so you'll have to go start another project we weren't out to break profound new ground in version control we weren't out to write a make integrated thing or ant task it saved us in this discussion right being able to that one conversation and if it's on the website it's official people won't argue don't you think that's that's not really not a joke because I was there but that's a serious thing if you say something the million lives people debate it for weeks if you put it on a webpage that took you three seconds to write click Submit on a wiki suddenly they're like hey official it's a fish try it see what happens you think I'm kidding the next example is the Google web toolkit which is I'm a huge fan of the the quit team and they're a really great bunch of guys but when they started when they decided to go open-source we talked a lot about how they do it and I said you know this seems silly but it eats you guys to come up with a mission statement so that you can let people know what you're doing and what you're not doing stay focus and they spent we spend a lot of time coming up with this this statement I want you to take a second to read it I know you can read I'm not going to be too but they wanted to narrow it for start to Java because they didn't want to spend time running a Python or JavaScript interpreter ask all the JavaScript they're arguing with people about it and and to concentrate on the users here it's to enable developers but it's no compromise and they have a page called making wit better and if you're working on any kind of a project I can't recommend highly enough to just go read this page and see what they say they've got this statement and they've got a very detailed explanation of why they chose each part of it and I think it's a great way of letting people know hey these are the people we're looking for these are what we're looking to do here is what we're looking to do and this is most specifically what we're looking not to do so they just they say Oh problems of attractive people who aren't interested in jumping on your property good strategies when you a mission or statement up with you here our goals to list non goals also a very corporate thing to do but it really helps keep things focus well in our project at Google which is code.google.com/speed component so if you go to our project which is slash P slash support you'll see there's a sort of making Google Code hosting better making hosting better and we sort of ripped off of this document a mission statement as well as some information and that's sort of a way of letting people know what we don't we do and don't intend to do with the project but but enough about that look at some more tips general tips about starting a mailing list netiquette we need people to not waste each other's time make sure your public discussions are about that are happening in public but they're happening on mailing lists that the archives are the mailing lists are visible to everybody so that when somebody comes along opens up an old discussion they can you can simply say look we talked about this six months ago here's why we're doing what we're doing you don't have to have the whole debate again otherwise they're just wasting your time you can sell em to go read it right and then this is this is a thing that not everybody has come to this conclusion yet but it's I think it's a really important little tidbit and that is what we call the noisy minority effect when we mean by that is sometimes you you're trying to come to a consensus on a mailing list and if you stand back as sort of an observer it looks like you see these back-and-forth emails oh we should do it no we shouldn't yes we should no it looks like this really even-handed debate then you look a little closer and you realize oh wait a second there's like 20 people saying we should do it one person saying we shouldn't do it and that one person is basically replying to every single male response right and it creates this psychological effect that there really is a big opposition when there isn't so that's a pattern would look out for and if you see somebody doing it you just very politely say you know what please read the entire thread you know maybe every once a day instead of every five minutes and and then write one response that that addresses into 20 messages that have shown up since the last time you look and it really gives a focused focused debate and it keeps it moist minority from influencing things in a strange way it's a way to help people realize that you know there isn't actually that much discord here maybe you know inches away from consensus but the one person is actually not consensus but in sense they're making a heck of a lot of noise so again - moving on to more documentation document your projects history again more obvious stuff here there's a lot of different things here but the most important one that I want to point out here is the mistakes okay sometimes someone will come up to your project like hey we should do this and if you say you know we tried that a year ago but I didn't work out their responses gonna be what you didn't try it my way you know it's the flow be but with if you document these mistakes in your mailing list or whatever or in a design doc we tried this this is why we're not going this route that shows people that you've actually thought about it and they can sort of see some of the things you've tried and thinking they won't try to do those again but it's a nice less measurable way of learning from your failures right it's if it goes with our whole philosophy of not being afraid of failure or at least lots of small failures and then documenting those failures right that's very useful and aiko changes have a great a great way of documenting things why do we do this having commit log messages that are consistent and somewhat informative saying fixed bug is never really a good commit message because since I want us to go and look at the code to figure it out you could say fixed off by one error or fixed you know security fix or whatever not that type of thing and I think in the subversion project we've got actually this diversion project we actually we've got our policy about blog messages right where we actually format our commit messages in a very specific way it's easy to search through them so that's something you might want to consider as well we need is a good search engine anyway healthy code collaboration policies now one of the things that now Carl observe this with regard to code review oh yeah and one of the things we do at Google internally is is a process of review we require that every piece of code written is reviewed before it's submitted now open source project usually would submit something and do review after the fact I cannot stress how important this is now Carl is has been involved in Emacs before and he Emacs uses a things they still use CVS if you can believe that people you see anyone here still you CVS okay see me afterwards the one person I'm just saying they so you CBS but they this log message script that sends out a log message in one email in the separate email it sends out the actual diff of the changes that have been made hard to figure out that they go together it's kind of hard to figure out to go together but it makes it a lot harder to sort of kept a comprehension and makes it it makes that little bitty tiny step up makes it harder for people to do code review and as he went through and he found I think one thread over the past five years where people had actually reviewed a line of code that was preventing went to the subversion priority saw something like twenty percent of all male threads where code review or related to code review yeah which is great and that that's a matter of having the right tools in place right make sure you have committed emails being sent to your list because that sort of forces people to review code because it's effortless right you're just reading your inbox Oh what did so-and-so do yesterday oh cool you need to wrote a bug let me tell them right now right it's zero effort on your part to do review the other thing is I mean it's also it's a cultural thing to if you start code review in your community from the beginning that culture will pervade and I think that's also probably the Proms Emacs is having there's no history of it right and if you if you're going to be collaborating we encourage people to do do big changes on branches or at the very least do them in a public way that other people can see and review them as you're going along we talk a lot about we don't allow what we call power plants and subversion anyone here I heard heard of the bike shed theory ok the bike shed theory it's based on Parkinson's third or fourth law which is that the amount of time and effort inversely proportional to its complexity and the example uses and I'll tell the story real quick is yet many years ago a company was designing building a new nuclear power plant the engineers came in with his gigantic pile of paper they set it down they said this is our design for the power plant that we want to build and you know what I'm thinking you know look yes certainly we need a you can see our plant yeah you know that's certainly yes looks good you know someone certainly done all the diligence so give it a big rubber stamp and send them on their way with a you know it's forty five billion dollar power plant or whatever it might be six months later the guys they come in with a single sheet of paper and they say you know the power plant progress is going great the workers who ride their bikes in however would like to the little bike shed to put their bikes in and here's the plans for it and we just one to sign up it's going to be 700 hours whatever not it will spend days discussing what color to paint the bike shed because a it's easily comprehensible and B it's a way of putting your thumbprint on it of showing you know I made an effect I chose the color for that bike shed over there and and so the inverse of that is the power plant and so we certainly push people to not show up with a huge pile of code one day because it's just about impossible to review something that big absolutely it's it's really it's unfair to the rest of the community so if somebody in your project is going to start doing something long and disruptive and maybe you know work for a few weeks and something that's going to disrupt everybody else just like the branch it's not a scary thing if you subversion in fact I believe next week or so we're going to release built-in merge tracking in a subversion so branching immersions to become a whole lot easier than it has I didn't write a line of code that was awesome and if using a distributed version control system clone your repository and have a copy of a clone on the server if I'm going to do that but you don't just because you're using distributed version 4 don't use that as an excuse to work in a cave for three months and then show up and say here's my great new feature right because no one's going to review that either and if people are viewing it they review they want to previewing it for readability they ran it reviewing it for whitespace and semicolons and curly braces let this will see what you're doing there's no design going to take place you can say well you made a fundamental flaw in your design and you look as well it's written there it is so it'd be generous with branches for people and on top of the bus line is what we call bus factor is basically how many people have to be hit by a bus and your team before you're doomed so you know some people call it job security but we call it really bad for a kid and I mean it's not just a bus right I mean maybe a bustable thing is right you know we would say hit by a bus that's an exaggeration right people leave projects people get married they have kids they move away they just run out of time or maybe they really do get hit by a bus but the point is you shouldn't have you know all knowledge of one part of your software in one person right let people collaborate and share the information and that means essentially you also have to discourage people from feeling like well this is my module I wrote this you must you know get every change approved by me that that leads to a tiny tiny bus Becker very dangerous for the long-term health of your community and we strongly discourage people from using what author tags are putting names in the source code I think that's coming up is it coming up well maybe but I'm going to say it right now yeah so there don't put your name in source code please because if you do we'll open source what is the barrier to put your name in a file you wrote four lines you had a function you go to class ten lines twelve lines what if you deleted somebody else's contribution you take their name out of the file you know it's it's it's a whole big time sink is what it is we encourage people the if you really want to know who's responsible for writing what code you've got the version control system to tell you right you don't need an announcement at the top of the file and typically people have a file that says somewhere or peb page it says who works in the project and you list patch contributors so nope there it is there it is all right oh we have an example to the the example of this story we had the guys show up on subversion and subversion initially used CVS estate parser which is just a total mess and but we thought it was okay to use it for now and eventually we'd rewrite it but it'll has really cool things like next week to be parsed yeah next week sorta or whatever three days after next Tuesday but we had a guy come up and said you know I'd like to go ahead and take on this task of rewriting this it's a nice encapsulated bit he did that he wrote this whole file and it was and he submitted the patch and the very first thing we said to is to remove your name from the top as per our hacking guidelines because in our code call our code collaboration guidelines are almost beautiful back it's a document on a web page so it's official right exactly so he's he what's beg he's like no I wrote this file why should I not put my name I wrote the whole thing like really well that's great we understand that appreciate that but this is a decision we've made as a community and we're not we don't allow that and I think the temptation here for a lot of people is to say wow there's this code this guy's right things we really want this or we need this and so people will sacrifice the core like values of their team for this new person who's come in and nine ever cent of time is not worth it well just don't sacrifice the long-term health of your community for a short-term gain so we said look we're really sorry but we're not going to let accept this patch as is he says fine I'm taking my code and I'm leaving and he did and he went away we never submitted his patch six weeks later some other guy came along he said hey I can write a date Parcheesi to God and he did it and we had it so you know it was a short-term inconvenience mildly but in the long term we still like that we are well defined processes all right bad meeting well if you guys are all software developers so the same process that you would use within a corporation the same ones you should use for an open-source project right you should have released branches you should you know backward that's not back bugs back port bug fixes I back for the head bug into this slide neck actually yeah that's been in every version this type of given I know you know have have a release manager have a release process documented for your for your software right it's just like a corporation with because it resolved conflicts it saves time nobody has to argue or wonder about what do we do this time and when it comes to reviewing patches you should have a policy and pace in place as well in other words one of the common problems we've seen actually is that if a project's really busy people will post patches to the mailing list and they'll kind of fall through the cracks so nobody has time everybody's working on different things and that's bad because then you never get new contributors and then people start to feel like they're being locked out so or ignored or ignored so one of the one strategy you can do is you know appoint somebody in your community patch manager sort of like a release manager patch manager watches to see what patches are coming in if a patch comes into the mailing list and nobody's replied to it for a few days they'll file it as a ticket right as a bug or something and then reply and say sorry we'll get through this soon so that at least that way it's not falling through the cracks and then lastly have a policy have a procedure for growing your community right it can't be completely ad-hoc one thing that we've noticed it's really important is that your culture becomes self-sustaining and what I mean by that is if you know every project starts out with maybe two people and if they're really nice people and they have those four virtues of politeness and respect then they tend to attract more people who are in that same vein and if you start out with a couple of people who are angry and screaming and chest-thumping they attract more angry screaming people and it perpetuates itself so think about your culture think about what kind of a community you want to build but at the same time have a procedure for building a new community a really common thing that a lot of projects do is they'll have a separate mailing list just for the people with similar commit access right are you know are the leaders of the community and they'll actually say hey I think so and so they'll nominate somebody so it's those been contributing some great patches let's give them full commit access but that mailing list only for discussing new committers and that sort of things right no technical discussions take place that mailing list technical discussions take place in the open it's only there so that people's feelings don't get hurt and they say you know I think this person's ready to become a full committer to the project or they're not ready yet or whatever the case may be but it's important to have that process and our general rule for accepting someone new in our community is that first while they do no harm you know we look for people who are smart and who are good developers we know how to write clean patches that sort of thing but if there's somebody who still writes some good code but lives a little while might do some knowing stuff you don't want people to come it's a lot harder to revoke commit access and we actually did that early on in the subversion project we gave commits access to some guy who was like a machine language programmer that survived the meteor strike somehow well he kept writing on he kept he kept like super over optimizing you know things like he would have an array of structures that he would alphabetize into a binary search through 20 items to save a few cycles we kept giving him reviews and you wouldn't apply the he wouldn't take any of the feedback or do anything he wasn't playing with other people so we're like well sorry but that took a lot of energy under the community as he is horrible helping him to do that again yeah the last thing is uh-oh actually she told us to tell my story so a founder can be booted there's a project that items and friends who worked on and there's a guy that founded this project he worked on it he built a community around it and it was very widely used open-source project he went off and did his own thing for two years and you know meanwhile they grew they added more people they added more features they expanded the project and he shows up two years later and it's like hey you know I've been thinking I want to completely redesign and change the direction this is how we're going to do it and you know this is what it's going to be now and people were like who is this guy this is a consensus based software but they were like who is this kind of like oh my god what are we gonna do is hijack there he's stealing our project and I'm like what do you mean he's steal your party you operate on consensus right there's eight of you and there's one of him get him and they were like but we can he's the founder and I'm like does he have some sort of like you know godlike capabilities that I'm not aware of you know well you know he's part of the project and I what I told him is that you know he's gone off and he's coming back and he's not going to play by the consensus rule the rules that you guys have said it he's not a being a community member and playing basically playing ball this well this gets into a larger discussion of you know how is your community set up there are some community weakened consensus driven communities are the most effective and most sustainable over the long term there are open source communities that you know do have sort of an enlightened despot running things right and that's okay but we could also write why is it despotism used in the real world right because it it's not sustainable it isn't it's it's great if you've got an enlightened despot and it's not sustainable in the long term it's same thing with open source projects we if you can move away from it an enlightened despot model we encourage you to right right so so that sort of leads us to the next thing timeout consensus and this is sort of a thing that a lot of a lot of people new to open source Apache has an incubator a lot of companies sponsor software and Apache and goes into the incubator including Google we're working with shindig right now which is really great I'm a mentor for that project and a lot of people first come to open-source they read all this information maybe about voting like on this voting closes right yeah exactly you know and they'll start having a discussion in the mailing list and someone will be some disagreement and like three males in Senegal let's call a vote exactly and so people will start voting on something I'm like whoa whoa you know you haven't actually finished discussing what's going on you haven't come to a point where actually you could probably discuss a little further and come to a solution that's even better than what one side or the other is talking about no come on but that's that is a telltale sign if you see a community that's voting all the time something is very wrong well with a vote you have winners and losers right it hosts a couple as opposed to what I think these are were compromises people sometimes think that you're you know you're coming to something that's less than what you initially work with but it's a it's a way of working through and coming to a solution that's better than what you did come up with think the subversion project at its eight-year histories only have one vote ever called so serious we was trying to decide whether to put spaces before parentheses or not in our code format now this was a huge issue and people started you know lobbying each other and you know calling up old committers on the phone you did that you got to come vote in this thing I didn't have a written code for three years we've got to come vote and yeah you call it Jim blendy and came in and he voted against you yeah we lost but I mean that was that was just ludicrous most of the time we could actually you know work our way through these type of things but so maintain your standards this is a quote from a friend of ours another developer which I'll let you read and and this is actually something I completely agree with that has changed in the past in the past people would have some super genius show up in their community and you'd have a group of four or five normal people go on about there at work and then some super genius would come in and the rules didn't apply to this person because they were super stretchy they wrote a lot of code and we should just let them do whatever they want and they would basically poison the community because you know even if they are super smart then that doesn't mean that they should have anything any special privileges or anything but you know there's so many super smart engineers out there that are working in open-source and otherwise that it just it just doesn't make sense to do this route playing well with others is just as important as writing great code and so this list goes back into our theme of you know don't sacrifice the long-term health of your community for a short-term game because some some genius is here in front of you about to give you some great code it's not worth it all right so let's move on to the identification part to our forty minutes go yeah here we go how do you identify somebody as being poisonous if it blows up Fitz Fitz calls it the bozo bit if he sees some emails go by and you realize this person is going to be a big-time suck bait he'll say to me as I uh well I flipped the bozo bit I'm not going to reply to this person Benz meanwhile writing a seventh email to the guy yeah no but but it's a good zine so the science communication annoyance they may use silly nicknames they may use different nicknames in different media they may hit their IRC nickname maybe sir hacks a lot and then their email is served what he hacks well and then they sign their name Steve when we're talking to you here and an issue tracker something different so it's hard to know it they may yell online they may be attached to the exclamation key or other things sorry we don't speak myspace here they may exhibit a general sense of foolishness and this isn't actually unable to pick up in the mood is an engaging ish engagement issue it may be harder for some people to sort of engage with the way that you guys are doing they may not understand what your goals are they may a whole bunch of questions instead of reading up on some of these things kind of it's more like just like a social the socially stunted right they just don't know how to talk to me it's not even at their hostel since they're just unable to pick up on social cues from other people right you're three weeks away from release and they're like hey let's write new features and you're like um are you paying attention yeah we're over here and we over there but you do get hostile people sometimes right they'll come in and they'll say your software is terrible and I don't want to use it and and I think it sucks but oh by the way can you help me over here yeah well then there's a person who come in a man's helped write you and you've got to help me you know it paid nothing for the software but you've got to help me or the best is I like your software but it's missing this feature and you know what I've got ten developers we're ready to help you write this feature but you have to redo this feature we're like well that's not really how we work you know is this alright we don't have that kind of leverage over our group it's some people just show up and they just have nothing to do but control troll yeah we all know the trolls oh this is my favorite of all there's no cobalt laser right well this time this is just this is just regular social dynamics right they see a happy functioning community they're not in the center of it if an idea they propose gets even politely and respectfully rejected suddenly it's an old boys network yeah it's a conspiracy ball is there's nothing you can do about that right except except maintain your own integrity right keep your side of the street clean so to speak so you get conceited people who refuse to acknowledge other opinions because you know they know what they're doing their experience they have any ears of experience in the field they're better they have 15 degrees and they're better than you and the other ones are the sweeping claims this is a good one so justjust just looking the crystal balls and how they've decided it they're they know the future and they know exactly how things are going to play out if I don't do this it's going to be a complete failure and no one's going to use your product and then finally this just the the issue of not respecting other people's time right forcing people have conversations over and over again when they could simply reread archives I mean a lot of them will refuse to do that right you'll say please go read our archive we resolved with some one time ago and if they don't go back and reread the archive them that's just a sign of disrespect they're in a real real telltale sign so let's move on a non-cooperation some people will show up and complain and but not help fix and this isn't this isn't talking about people who are incapable of fixing something non-programmers not engineers some people will show up in their engineers and they're just going to complain about things you and then what usually comes up next is the open source way of saying go screw yourself which is patches welcome it's sort of your way of saying you know check off but you'll get people who don't want to discuss design or this is very common actually people who just can't take criticism of any flavor constructive or otherwise it's actually something it's sort of unique to open source development is that you know people need people are giving each other constructive criticism all the time and you should have learned and have a thick skin if you participate in this way and it's actually very foreign to people who've never done open-source you know or maybe coming out of a corporate environment it's a you know what was it what's that great story about yeah a friend of mine I went to work in a small company about 20 developers and he notice they didn't have commit messages set up so he said commit messages up and the first thing he did was he sent a code review to somebody and he's in another code review and one of the other his manager called in his office and said you know I'm getting a lot of feedback from people that you're really being negative you know you're getting a lot of like criticism from them he said so this code are you think I don't think it's going to work out he's like yeah I don't think this whole job things and work out oh the stig ways that you are not your code right just don't don't worry about it's not it's not about you it's about the code and how to make the code better what's your way of learning it's go really experience right if you don't ever get feedback and you're good you never get better so yeah later so let's move on and find out how to get rid of the poisonous people or how to how to get rid of the poisonous behaviors we'll talk more about that do to assess the damage there's really two important questions right something's going on something set off your spidey sense two questions to ask first of all is attention to focus being drained away and most likely yes otherwise you wouldn't be worried in the first point maybe there's some heated debate going on maybe there's a troll maybe there's somebody being a perfectionist who knows what it is but the question you have to ask yourself is you know is this all right maybe attention focus is being drained but is it likely to resolve is it likely to resolve anytime soon and as the result the final resolution going to be worth all this energy that's being spent and that's that's really hard it's a hard question to answer it sometimes maybe you'll have to have a conversation with some other people in the project look we're spending a lot of energy here I mean is this really worth it or should we just cut it short and keep going and that's that's a call you have to make it there's sort of art to doing that but I think it's something you question you need to revisit and not be afraid of visiting because you we might hurt somebody's feelings or that's just it you have to look at the health overall right it's a lot of gray area involved here I mean there's no black and white timeline so but there are a few things we recommend nothing goes don't feed the energy creature okay the we highly recommend ignoring people that show up and try to show you if you give people you know ability something something to grab on to there gonna you're going to do that one of my favorite things I live in Chicago we both live in Chicago anybody here from Chicago you guys like to people raising their kind of quiet they're afraid of the left coast right but uh I'm driving in Chicago occasionally I may do something that's not quite polite on accident right and somebody will start yelling at me and screaming at me and honking their horn and you know I could turn around on screen but what I love to do is true managers wave at them and they just go nuts I mean it's just completely nonlinear you just see their head just explode and they're trying to their car but you know I don't give them that opportunity to just like you know Gail back out because that's that gives them the chance to engage which is another thing we don't want to do well the other thing is it's really easy to get emotional when when somebody comes by I mean what actually happens the example I have here was subversion was getting pretty usable let's get to the point where people were starting just beginning to use it in the early days and somebody came to our list and was like hey you know you guys are it's cool that you're trying to write any version control system but really I'm I know how to do this better than you and I've got this other version control system over here and we're doing things better and you should all basically stop what you're doing we should merge our project together and follow my lead and we started sort of like criticizing all of our design decisions and of course you know being young and naive I started like typing furious emails defending all of our decisions and our history of Oliver I've like tip the bozo a bit main events like good cop good cop looks like three days I lost just an emotional expense when it when you know in retrospect I could have seen after a few emails that this wouldn't have gone anywhere that we weren't clearly not going to do this ridiculous thing dropping everything for them nobody wanted to do that nobody believed this guy right but I put all this emotional investment into it anyway because I was worried one person doesn't like me it's a trap it's a trap and it's easy to get sucked into that so let's like what some things you can do we talked to earlier about paying about handling patches okay a newcomer to your project especially a capable developer the their sort of knock on your door will often be in the form of a patch so it's very important not to ignore patches and it's very important to at least sort of let them know that you're watching them and they may be a little bit annoying it which I talked about this sometimes difficulties sort of engaging like transmission sort of grinding a little bit and this is where like I said I have very little patience for this sort of thing about God ignore oh go away whatever and Ben will be like no come on let's let's talk to him in sort of a cupcake yeah exactly but so that's the first thing the second thing is to look for the fact under the emotion and and if possible pull out a real bug report we have a there was a guy I'm very proud of the subversion culture for doing this there was a rather famous open-source person came to our list and was sort of screaming Iran is here software is terrible I can't believe you released I felt this bug and and what were you thinking and you are on crack and where I was just insane amount of bile and you know you know I was so happy somebody else one of our developers in the UK wrote back this like really calm email to saying okay well looks like you found a bug here and you know sort of just extracting raw data and okay I think yeah I think that got patched last week and any other guy rates backing are terrible sir you guys are all idiots blah blah one more reply okay alright yep I've Arif I'd it's all fixed it's going to be out in the next release thanks a lot like I think I respected again yourself look silly right and he did like a complete morning we got a bug fix you know but I you know the first time I read this email like my just my blood pressure with the roof and I'm like kill you know hit the smite button right a little smite button on your keyboard and and then was then Benza it was talking with souther guy who really just very logically pulled out the info just great cool thank you so there's a mother so no one to give up and ignore right and I think it's sort of a first thing she talked about there he should have just sort of given up and ignored that much earlier and and this is the the hardest I say the hardest moment we ever had in subversion community we had a developer who showed up was super enthusiastic but somewhat clueless he would hang out an IRC he'd hang on the mailing list and our mailing list turned and I like sort of his stream of consciousness and again what if we did this or what if we did that or hey could we do this someone would ask a question feeling every 15 minutes yeah so would ask a question hey can we do this with subversion he'd be like sure you can do this and he would give them the wrong answer and then and so it was just all this energy going in this and I'm like I just had this sense that you know this guy was really taking a lot of time and I'm like how can i how can I show this to the other developers because I don't want to say you know this dudes wasting our time and I'm a huge fan of data graphs pictures all that stuff and so I took my male spool for the subversion developer list the last month and I wrote a little program that analyzed it and I found the top five people posting to the list he was number two and he actually wrote no code and other four were people who were actually full-time committers and subversion three of whom were paid to work on subversion full-time so I did a little further analysis and they discovered that two-thirds of their answers were to him okay and so I took this data and I send it off privately to Ben and a couple of the guys and said look this is what we've got this is a problem I really think it's affecting our forward progress a nice guy draining all of our focus and energy and so we wound up sending it to the committers and we talked about in our little private list because we don't get in public and hurt the guy's feelings and we actually finally did is one of our guys Carl who's like nicest human in the planet called this guy up and had a long top of him and and politely asked him just cool off and not post our list for a while and and he didn't actually understand what the problem was but he did that and you know suddenly productivity kicked back to normal yeah that's a hard story I mean one of them of course the troll thing right we all hang out in IRC one day we were all some guy came in and started screaming at us and saying ah subversion is terrible it's awful violence it's not doing this for me and of course you know like like you would expect we start saying oh well did you install this package did you use the switch well when he's coming back with more bile same kind of thing and finally this goes on for maybe 10 minutes and finally at the end of all this helpful feedback he just sort of says well I came in here for an argument you guys are being nice it's ridiculous and he goes away like he actually admitted this is amazing this isn't an argument no dude and so sort of the final touch on this is that is is one of them the criticism we've had but this talk in the past is that we're just like you know getting rid of people throw people out treat them like crap but this isn't about telling people out of the talk it's about it's about throwing behaviors out of your community and one of our one of our commute vendors who actually extremely prolific committer first shut up he was very caustic he had some really good points but the way that he would say them was just offended a lot of people and was just sort of just like very like in-your-face so we didn't throw him out of the community we didn't boot him we just took him aside I said can you please be nice take him aside and not know but we were just that look look you know you're really upsetting people can you change your tone a little bit be a little more respectful yeah and he did he did he's he's like you know I don't really work that way but he did that and he would catch himself and it worked out really well so always that that's our takeaway is that if you see bad behavior don't boot people address the behavior first right booting people out is really the very very last resort and and one of the things that we would do is is in addressing the behavior is when someone would show up and do something we would reply to the actual look listen and reply to their point that they had inlet mail but also say you know look we really don't talk that way around here we try to teach you a little differently so this is inappropriate for our community and try and constrain the behavior and not attack the person because they may very well be offended or be more upset and again you're not going to be able to handle everyone in this way people are still going to be jerks or whatever not do what they want to do you can't change everybody or most people for that matter my wife will agree with that so here's our here's our final takeaway slide remember you're trying to preserve a tension of focus right that's ultimately what really matters other than beyond the code itself make sure your community stays healthy and healthier is the more fortified it's going to be against poisonous people make sure you recognize when bad behavior is happening in the first place and then finally you know don't be afraid to call out bad behavior don't be afraid to make short-term sacrifices for long term health all right that's basically yet but there is there is an important bit here right and that is all this stuff that we've been talking about really I mean we've been talking about open starts it's not really about open source it's about pretty much any community like could be your church group it could be your team at work could be your family I mean any any kind of if you have community development or any kind of community functioning in one direction this all these behaviors will show up anytime you get more than two people in a row baby yes so and that's it [Applause] we've got we've got plenty of time for Q&A here so people have any questions or answers yeah any answers are welcome hi I've been on IRC with deodorant and DJ bee and John Stevenson we all take your talk sucks some variants over here's a bit any questions up here comes another question one problem that I ran into with running any kind of project was not often but the most dangerous thing was what I call the charismatic control freak somebody who's very well liked by everybody very you know has a leadership but doesn't know but has no bad design decisions bad no can't code so what you know ever has found that the difficult you know a problem to solve and I don't know how to solve it is hoping that you guys would talk about it so the question is of talking about it if person who is a charismatic leader and sort of a control freak wit actually has no technical qualifications to make decisions right right or somebody that you know inside they do cut losses of focus I mean it's all about it's all about them not getting the project done no very often will like wreck a project but all because it roll well I mean that's but it that depends on the under group of people that are sort of you know sitting in the bus of this person's driving if someone's driving a bus off of a cliff and you're on the bus you have a choice you need to jump off and cover a few be bruised is where you can stay on the bus and right off the cliff with them and you know it really good real oh you can you can try and grab the steering wheel although I don't recommend doing that in an airplane the but it's a hard problem and what usually happens in these cases is and one of the reasons we advocate consensus based development is that if you're operating a consensus that means that if more than 50% of your developers are basically in agreement on where you're going where you're going to take this bus alright so if people decide they don't agree with you or like you or have a problem they're going to splinter off and they're going to go and you know basically swarm they're going to work they're going to go up and start a community somewhere else it's really difficult to do that with the minority of the developers but if you're running if you're running with an enlightened or unenlightened despot as you're talking about here what will frequently happen is the people will eventually get tired because you can only carry so far in charisma and they'll go off and they'll move elsewhere and restart the project but I would also say the problem isn't just with the the despot right it's also with the rest of the community why do they tolerate or put up this person maybe maybe this person is really charismatic and wonderful but I think it's a matter of you know trying to get the rest of the community to feel like they have some power beyond what this one person's opinion is and that's that social engineering problem I guess don't have any magic bullets there right yeah let's take the next question thank you yeah you guys talk a bit about good cop bad cop I I can cure you so if you'd expand a little bit on that and and specifically talking about how to give folks feedback sometimes like the well-known founder of the community isn't always the right person to give feedback I'm curious if you could talk about a couple of structures you know where where the feedback works and you know where the how the hierarchy that kind of is there and then who does the feedback and how does it communicate just a couple of examples of how it works the question is about structure of a project and good good cop bad cop and how how to do feedback well it start with a good cop bad cop part is that Ben and I don't play these roles that's sort of like kind of how we who we are I think more than anything I don't advocate manipulate empting to manipulate people in that fashion and actually I did I don't advocate playing backup I know some people that a friend of mine actually had to give a talk similar to this one sort of and his one of his sides was flame the flavor's flame me or something I don't know what it would he advocated yelling at someone who yelled at somebody else really loudly and I was like what I didn't quite get that and wrongs don't make a right exactly exactly so it is it is sort of tricky but um yeah I agree it's not about manipulation so much as it is it's about respect if somebody who's really well respected doesn't know how to give constructive feedback then maybe they should be taking aside and said hey maybe you should be a little kinder in your feedback or or maybe somebody else in the community can be encouraged to step up and be more vocal if they're particularly it's a talent right some people are good at some people aren't and something it can be literal it's probably a whole book about that right there right right well I asked I asked Adrienne hollow-body who does every block in Chicago and whatnot I mean so you guys such a great visual style to your websites how do you do that because he's admitted to me that he's not much of a visual graphic design kind of guy and he said it's very easy I know Wilson and Wilson's really really good at it and I defer all the design decisions to Wilson but that's that's an ability issue it's a humility in a respect issue right he know he knows he knows that he's not good at that so he sort of leaved that to someone else so you know you're not good at feedback or if you know someone else is a good feedback maybe giving them a little feedback that they're not good at feedback Thanks so it's like a feedback yes I had a comment of just about something it's help when you did with a lot of customers who are doing the kind of flaming and troll eternity control trolls I find really helps is - you talked about the very patient person to save emails like that so that you have their approach boiled down to a nutshell and just have notepad or something set aside where and know here's how to deal with trolls troll number one who here's perfect answer pop it in the email and send it off to them that way you've got your own scripts because you're the master of that situation you're in it all the time these people aren't reading your materials otherwise they wouldn't have asked those kinds of questions so instead of our frequently asked questions it's a frequently answered answers that you pasted in the template it's amazing it's amazing because you can answer them so politely and so pleasantly because it's the machine doing it it's not really you right and so when you look at it you're all you're performing at the mouse and you're looking at the list and you're like yeah I'll reach for that one that down tonight there it goes and then just go on to the next thing and then see what happens with that we throw up on that right correct poisonous people you have chosen silly nicknames Thanks that is a great strategy you had mentioned a project that where they made decisions by consensus and I don't know did you mean they actually use consensus process the formal process and that sort of got me thinking of like when you've got larger distributed open-source teams where you've got committers all over the world and you have to make those tough decisions are there have you seen good patterns of how to formalize this is how we make those big decisions and this is how we know we've we've made our decision and we can move ahead I think the question is how do you how do you actually do consensus-based in working mechanics of consensus based decision making and I think it's a I think it's a matter of usually it's self apparent right it's pretty obvious when it consensus existent when it doesn't and if it isn't apparent then I would argue that something's wrong or people aren't listening to each other and the last resort you can you can get down to voting right but that really is elect well there's there's a simple one of the simple rules that we have is that in many of our projects is that decisions may take place in the mailing list people from going off on IRC while we're all awake in Europe is sleeping and we've made a decision and the Earp's like whoa yo would you do what happened yeah you know I see in the background so we'd have a lot of chats in IRC or when we work together on subversion in Chicago we would have a lot of meetings sitting here in the couches and then we would take our notes and our sort of the ideas we'd come up with out that post into the mailing list and then decisions will be made there with everyone present that is fair especially if you have a distributed team lots of time zones make sure the only official discussion is discussion that happens on a mailing list and we have to allow sufficient time for people to respond wait we also have a lazy consensus if you wrote an idea and someone says that's a good idea in three days there's no one else's post anything then silence is a safe silence is assent hey when people join my project I want to make sure that a lot of problem with open source projects is that people don't really understand social interaction and consequently they act like dicks so that's okay we're here to help so I was wondering is Siri is there an easily digestible version of this somewhere that can point them to when they want to join the project so just to make sure that they kind of understand what what we've all been talking about here well this is this actual doc along with your question will be posted to our website in the next week or so but this talk is also what we give we give it we give this talk at Google in Mountain View last year or so too it's up on YouTube now so we're in the youtubes how cool and and and there's also Karl's book is online but but also it's just a matter of any your own project in addition to committing you know coding policies and how to get involved and design all that you can also if you really want you can document some kind of standard of conduct as well right and that helps to I've seen that one or two projects yeah I will take one more question I mean I call it quits for the day more of a follow-up to the previous question about consensus I was briefly involved in the atom working group which was hosted by the IETF and the the IETF has some good documents actually on many of these issues you know their their tagline is rough consensus and running code and in the atom working group we had a particular person who was appointed as the chair of the working group timbre of Sun Microsystems and he would periodically come come along and sort of post a summary as you would suggested of you know a particular issue and then say ok I think we you know we are we've achieved consensus here or I'm not sensing consensus here and people could argue with that at that point no we haven't really achieved into I don't think so you know or you know if no one posted any follow-ups to that then it was just you know so he was sort of the consensus manager you talk about having a release manager and a patch manager he was sort of you know the guy who came along you know every week or so and said yes we have consensus on this issue or no we don't that's a great it worked really well and you know that was that was a working group with a lot of people and a lot of strong opinions I was one of them and and it just it worked very well it just kept the flow going of of the group to have one person who would come along every now and then and say yes I see consensus say a lot of communities actually have external entities have done that Linux weekly news etc and I would expect that person maybe it might be even more effectively they worked part of the discussion they were basically like yes that was basically what what he was he didn't take part in many of the day-to-day discussions but he would come along sugar pop his head in and say okay I've been following this and here's what I see you know the movie is shifting towards this or that anyway and it worked very well anyway the IETF a number of documents on achieving consensus in an IETF way would be useful reading I think that we're still going to be up here if you want to talk a little bit it's all the queue and able to take formally there are feedback forms and your chairs for all the not just our talk we feed back we're always glad to hear what we can do to improve things and we're right here thanks a lot for coming

Channel: Google Developers

Views: 42,034

Rating: 4.8694363 out of 5

Keywords: Google, I/O, IO2008, Open, Source, gcvio052008, plid6D9B701069B4F2F4

Id: -F-3E8pyjFo

Length: 57min 44sec (3464 seconds)

Published: Tue Jun 10 2008

Reddit Comments

[u/SpaceboyRoss]

Why does my school block educational videos? Stupid securly.

[u/mickael-kerjean]

Good to see some videos where you hear: "Sorry we don't speak myspace here" (31min05)