Jessica and Charles talk about community building with ZeroMQ’s Pieter Hintjens.
PIETER: Well, it’s just flatbread and then covered in cheese and other stuff. And it smells of garlic and onion here. So, this is really quite good.
[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on Ruby developers, providing them with salary and equity upfront. The average Ruby developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations. It’s totally free for users. And when you’re hired, they also give you a $2,000 signing bonus as a thank you for using them. But if you use the Ruby Rogues link, you’ll get a $4,000 bonus instead. Finally, if you’re not looking for a job and know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept a job. Go sign up at Hired.com/RubyRogues.]
[This episode is sponsored by Codeship.com. Don’t you wish you could simply deploy your code every time your tests pass? Wouldn’t it be nice if it were tied into a nice continuous integration system? That’s Codeship. They run your code. If all your tests pass, they deploy your code automatically. For fuss-free continuous delivery, check them out at Codeship.com, continuous delivery made simple.]
[This episode is sponsored by Rackspace. Are you looking for a place to host your latest creation? Want terrific support, high performance all backed by the largest open source cloud? What if you could try it for free? Try out Rackspace at RubyRogues.com/Rackspace and get a $300 credit over six months. That’s $50 per month at RubyRogues.com/Rackspace.]
[Snap is a hosted CI and continuous delivery that is simple and intuitive. Snap’s deployment pipelines deliver fast feedback and can push healthy builds to multiple environments automatically or on demand. Snap integrates deeply with GitHub and has great support for different languages, data stores, and testing frameworks. Snap deploys your application to cloud services like Heroku, Digital Ocean, AWS, and many more. Try Snap for free. Sign up at SnapCI.com/RubyRogues.]
CHUCK: Hey everybody and welcome to the Ruby Rogues Podcast. This week on our panel, we have Jessica Kerr.
JESSICA: Good morning.
CHUCK: I’m Charles Max Wood from DevChat.TV. I just want to remind you to go check out JSRemoteConf.com. It’s an online JavaScript conference. Jessica will be speaking at it. It’s going to be a lot of fun. And I should have the schedule up by the time this episode goes out, so go check it out.
We also have a special guest this week and that is Pieter, okay, Hintjens?
PIETER: [Chuckles] Hintjens is good.
CHUCK: Do you want to introduce yourself really quickly?
PIETER: Sure, Chuck. Pieter Hintjens. So, I am the CEO of iMatix and the founder of the ZeroMQ community. And my specialty is community building. I’m an author and a programmer and a father of three lovely children.
CHUCK: Very cool, sounds like fun.
JESSICA: And a maker of pizza.
PIETER: Oh, we’re making pizza right now, yeah.
CHUCK: We’re not talking about food. I’m hungry.
[Chuckles]
CHUCK: Cool. So, we brought you on to talk about community building. In particular, are you more about organizing people at say, conferences or events, or online communities?
PIETER: Well, I’ve done a lot of events and conferences as well, but mostly it’s online communities. I guess it started in the area of, actually political activism. We were fighting software patents in Europe around 2005. And we had to do a lot of campaigns and a lot of volunteer organization, which is very difficult. From that we learned really how to build communities. And we’re using that in open source projects starting in 2007 in [inaudible] for ZeroMQ.
JESSICA: Pieter, what is ZeroMQ?
CHUCK: It’s really cool. Oh, sorry.
[Laughter]
PIETER: Well, it’s a community. That’s how I describe it now. It’s also software and technology and protocols to do with building distributed systems. But what it really is, is a community of people who like and who know how to build distributed systems in all kinds of languages, all kinds of platforms. So, it’s everything from large clouds to embedded devices. And really about the protocols and standards for that, yeah.
CHUCK: Yeah, I’m much more familiar with the technology. You said it was a community and I was like, “Oh, I didn’t know about that.”
PIETER: Yeah.
CHUCK: But it’s cool software.
PIETER: It’s cool software.
JESSICA: It’s very interesting that you say it’s a community first and software second. Oh, go ahead.
PIETER: When we started the project in 2007 there actually were two parallel projects. One was building a software library which was done by my friends Martin Sustrik and his team in Slovakia. And then my work was building the community around the software or to build the software, really. And that was a separate project with its own structure and a whole bunch of tactics and strategies, the licensing, the contribution policy, how we would see it. It took several years for that to really develop properly. But I think that’s successful. It was really a formula. Build this community using these approaches, things like making it very easy to contribute, having very clear contribution policies, which still took some years to develop into real working tools.
JESSICA: Wow. So, the community is like a parallel process to the software development.
PIETER: Mmhmm.
JESSICA: Parallel but intertwined?
PIETER: Well, I think to summarize it, we built the first version just ourselves, just brute force if you like. And it makes interesting software. It’s very fast but it’s very strange and rather complex. And this attracts enough people to build a community who can then together build the real thing, years and years of work later.
JESSICA: Wow. What did you bring from your political online organizing into the software community? How is it the same? How is it different?
PIETER: So, it’s interesting that the political organization was also like any NGO, you’ll see lots and lots of struggles over control and power, and who has the right to start a campaign. Who owns the collective intellectual property, the good will and so on? And the NGOs that I was involved in and I was actually in charge of for a couple of years were completely riven by conflict over ownership and power, very toxic in fact. And it was very clear that if you could resolve the problems of power and money then you would enable the majority of good-willed people simply to work together on stuff they wanted to work on, they were able to work on.
And so, you had the same in open source software where you have dominant individuals who can be very toxic to the quiet good-willed masses, if you like. And so, it took a long time to actually prove that. That was this theory in the beginning. And in ZeroMQ we saw that very clearly. At a certain point we had to fork where the dominant individuals left the project and made their own stuff, which then died and then carried on in different shapes. And ZeroMQ became a very quiet consensus-driven, much more organic project, and much more successful. That was about three years ago.
CHUCK: I’m really curious. And I think there are some positive things about community building, but those negative elements really can affect things. How do you identify them? How do you pick them out? And then how do you handle things to make sure that they’re continuing along the way that…
PIETER: Right.
CHUCK: Encourages the kind of collaboration you want?
PIETER: So, there’s a lot of this in my book, in fact in my two books. One on ZeroMQ has a big chapter on community building, chapter six. And there’s also a lot of background in my ‘Culture & Empire’ book on how online communities work and why you need collective thinking rather than individual thinking.
But basically, there are two kinds of problems. One is conflict between well-intentioned people who have different opinions about where to go. So, you have two groups who have simple different experience, or different views on a problem. And they’re trying to fit these two views into one box. And that creates conflict. And the answer is very simple, is you let them both create their own boxes. That’s all. Just fork and make space for creation. You don’t have to have a single security mechanism. You can have many concurrent and competing security mechanisms. So, you turn that kind of conflict into competition. You do that by having good contracts between layers and that solves that. That’s finished.
And then the second area of conflict is where you have individuals who really don’t like sharing their space with other people or their success. They’re very self-centered and they want to dominate the group. They want to create chaos and then profit from the chaos. I see them as cheats in a kind of intellectual fashion. And the thing there is to remove their ability to confuse and pollute by having very clear rules. And allowing people to fork the project if they want to escape that, and removing the ability to make silent agreements and backdoor deals, and so on, like, “Let’s all make this stuff in this direction and not give people the chance to contribute and push it.” And if you do this right, then what emerges is a very organic contract-driven careful and slow and very accurate, it seems, process, thinking process.
JESSICA: Wow.
CHUCK: So, are these rules or guidelines posted somewhere? Or is it just understood by the community?
PIETER: Yes. Well, we found that we had to post them, because as long as they were just basically a wiki page or assumed, then people would cheat. They would come and say, “Yeah, but according to the rules we can do this and that.” You’d be like, “Yes, but… okay, okay.” So, we eventually wrote the rules down as a protocol, as an RFC. I called it Collective Code Construction Contract, I think, C4. And it’s one of our ZeroMQ RFCs.
It’s RFC 22 in fact. And it has all the rules, like ‘you must’, ‘you may’. Basically things like anybody may propose a patch. You cannot refuse a patch because you don’t like it. There’s no roadmap that can exclude someone’s contribution, period. We see every patch as an answer to a well-defined problem. The problem must be expressed explicitly. If it’s just, “I want to make this feature,” that’s not a sufficient patch, and so on. And a whole bunch of these rules that we’ve learned are useful. It’s possibly a little bit formalistic but it has worked very well in ZeroMQ and it’s worked in other projects as well, very well, to take away the kind of dominant maintainer syndrome and allow the crowd to edit and make their changes. And we look at Wikipedia and Minecraft as being very good inspirations for how we like to make software and organize, very free, very fun.
CHUCK: Are those posted somewhere that we can see them online?
PIETER: Yes. If you just do a search for ZeroMQ RFC 22 you should find it.
JESSICA: You said that we need collective thinking instead of individual thinking. Why is that?
PIETER: Well, not instead of but as part of. And individual can only really think clearly as part of a group. And the group can work concurrently over a wide space, can see large problems from many angles, can divide and conquer. And it’s proven I think that a group of people will have better decision-making than individuals, especially experts who are often very distorted in their thinking. Experts come with…
JESSICA: So, the more expert…
PIETER: Yes, yeah.
JESSICA: The more expert you are, the more you need to be part of a group?
PIETER: I think so, yes. I think the more expert you are, the less you know about the general world and the general usefulness of your knowledge. And that comes from the group that can tell you what’s worth doing, what’s worth not doing, also. That’s very important.
JESSICA: Oh yeah, that’s a good point. So, you may be an expert and know how to do everything, but that actually makes it harder to understand what you should do.
PIETER: And what you shouldn’t do. And the really elegant things that we make are often very, very simple and come out of very slow and careful and wide thinking rather than intense effort by a few people.
JESSICA: Your community is built around distributed computing and it’s also about distributed thinking.
PIETER: Yes, yes. And we come to Conway’s Law where if you want to build a successful distributed system, you build a successful distributed community first of all or organization first of all.
JESSICA: Wow.
CHUCK: So, is there some form of reaching consensus here. I’m browsing through the spec. And it says that you should seek consensus. But I don’t see…
PIETER: Yes.
CHUCK: Do you have some system for doing that?
PIETER: Take Wikipedia as an analogy. I think it’s a very similar process. You can create new areas anywhere you like. So, there’s no limit on where you can go and create stuff. And you have people who use what you make. And the users will get contracts from you, API contracts or protocol contracts. And the more you document and the more you put test cases around your contracts, the more people will invest in them. And then they can come with this RFC to stop other people or stop you from breaking those contracts over time.
So, you’ve published an API and the API has a certain weight and a certain use in the market. Then breaking changes are now forbidden by this RFC. So, if someone makes a breaking change, someone else can simply revert that. So, it’s not just about individuals making always the right changes, but the group also coming back to fix mistakes and to stop people making stupid changes. And consensus appears, and this is our experience now in actually lots of projects, emerges from this quite nicely. It’s still work of course. You still have to go through and write code. It’s still work, writing code. But it’s a lot less experimental and a lot less, a lot fewer failures in what we make than before, I’d say.
JESSICA: As a negative, is one of the negatives of this that if someone comes in and they want to use the software, when you’ve got multiple people building their solutions, is it confusing to people who need to pick one?
PIETER: It doesn’t seem to be. It doesn’t seem to be an excessive choice. It seems to be that we have old things which go through a cycle of maturity. And then they basically stop developing. And then we have new versions or new re-imaginings of the solution which are simpler and have a better level of abstraction, which replace the old over time, which is what you’d expect and what you like. In fact, that’s what we want. We want new APIs to emerge while old APIs remain supported. And new APIs with better levels of abstraction to come out and take over and become dominant.
We see a lot of diversity in language choice, so people do have their languages. They have their Erlang and their Go and their C++. And they will build theirs in those languages, which is fine as well. But there’s [not] a lot of confusion about what to use, even though there are often three or four or five versions of something, five instances of some layer. It seems to work.
CHUCK: So, I want to go back to the consensus thing really quickly because I’m not completely sure I understand. Basically, somebody can submit a patch and it can be put in. And then eventually it will be pulled out if it doesn’t meet these other criteria or if the community reacts to it in a way that makes it come out?
PIETER: I think it’s turned out to be a valid rule that 80% of patches are good and 20% are bad in some way, either by mistake or they’re just, the person who’s making it does not understand. And in a very small number of cases, contributors are actually, I would say pathological. They do stuff which is really traumatizing to other people. So, the very bad stuff is relatively easy to catch and take out. You see way too large changes. They’re obviously not following the process or obviously not reading the RFC. They’re not taking care. So, if the person insists on doing that, we ban them after a while. We say, “Okay, this is too much change. You’re not following the process. You’re not using the rules. You’re actually accusing us of being bad at maintaining because we’re merging your patches. You’re off.” And the rest, the thing is to get, sorry.
JESSICA: You said they accuse you of being bad at maintaining for merging their patches?
PIETER: Yeah, this happens.
JESSICA: Do you merge their bad patches?
PIETER: So then, well if you take the other 95% or the 99% then the trick is to merge as fast as possible. You merge to master without doing code reviews and without, as long as it passed tests and as long as it doesn’t look actually insane, you merge it. And by merging it you forced it into the front. Everybody will look at it. It will be tested on many systems and it will fail. People will be engaged to come and fix it and improve it. And so, people who are good-willed contributors will learn very rapidly if they’ve made mistakes. And the 80% of good patches just go straight into master correctly.
JESSICA: Then the 20% become urgent because you just put them in master.
PIETER: You force people to look at them and you’ve given, I would say both sides an incentive to go and look at this code now rather than leave it for six months.
JESSICA: How many people are part of the ZeroMQ community?
PIETER: Well, on the core library it’s maybe 150 contributors, 170 contributors. But there are hundreds of projects around ZeroMQ now. So it’s, I don’t know, several thousand people I would say overall. It’s very distributed. It’s hard to keep track of it all. You don’t try.
JESSICA: Wow. What’s the diversity of the community like?
PIETER: In terms of technological diversity, it’s very diverse. Every single possible language you can imagine is there and platforms. In terms of geographic, it’s very diverse. A lot from, I would say every continent except from Africa, not very much from Africa. But that’s because the internet hasn’t gone very far yet there. And in terms of gender, it’s almost all guys. I have no idea why that is. But it’s very diverse otherwise, but not gender.
JESSICA: That’s all of open source, right? It seems like it.
PIETER: All of technology, to a large extent. When it comes to [inaudible] technology it seems to be very, almost distasteful. And I think, I wrote a blog about that and I think I figured out why eventually it’s distasteful to women in such a scale.
JESSICA: Really?
PIETER: Yeah.
JESSICA: Why?
PIETER: And it’s not because, well, because most technology is bullshit.
[Laughter]
PIETER: And women are just not so stupid as to spend years of their life buying into utter rubbish. And they’re like, “Come on. We have better things to do than this.” But young guys have no taste and they’re willing to spend 20 years learning the most arcane nonsense just to be able to one-up each other. “Hey, I know this new stuff.” And I think that’s it. I think the problem with technology is the magical thinking that’s gone, you know.
CHUCK: Wow. All I have to say is that my wife’s bullshit meter works way better than mine. So, you’re probably right. [Laughs]
PIETER: Yeah, yeah.
JESSICA: Yeah. There is that sort of suspension of disbelief.
PIETER: Yes, yes, exactly.
JESSICA: Which, that’s the essence of being a geek, isn’t it? An irrational level of interest in something. And it [inaudible]
PIETER: Yes, yes, yes, and the willingness to spend years and years and years learning the most arcane nonsense just to be able to spout keywords at someone else and beat them. It’s magic. It’s wizard-ish.
JESSICA: [Chuckles]
PIETER: And this magic wizard-ish technology thing I think has put women off. And I think justly. I think it’s a very wise decision not to go and invest that much effort in rubbish.
JESSICA: That makes sense. And it goes back to, at the beginning you said that there are some people who just are in the community in order to play the political game, in order to steal other people’s intellectual property and call it theirs.
PIETER: Yes, yes. That’s very, that happens in any successful project, I would say. Some people try that.
JESSICA: What do you do when those people, when people who are trying to jockey for a position and be ahead of other people, what do you do when they’re also contributors and actually put some good code in?
PIETER: Oh, you ban them.
JESSICA: Their patches aren’t important to you?
PIETER: No, no, no, not at all. If they’re actually hurting people, if I get a distress call from someone saying, “Pieter I’m not enjoying myself on this project anymore.”
JESSICA: Ah.
PIETER: I take that very, very seriously. I take that very seriously. This process is supposed to be fun. It’s supposed to be very much this learn, play, work, teach cycle where it’s fun. It’s like Minecraft. It should be addictive and it should be fun. And when someone is doing harm to other people, giving them stress and anxiety and hurting them even in the low doses, then I get very perky and I get very defensive. Mama bear comes out and starts looking around and, “Who is doing this?” And I don’t care how good their code is. Often, their code is very well-argued and very interesting. But it’s hurting somebody. And if one person says, “I am feeling pain,” and ten people aren’t saying anything but they’re just going away.
JESSICA: That’s true, that’s true, because there’s that small contribution of their interesting code that you can see. But what you don’t see is all the contributions that you’re missing out on because that person is there.
PIETER: Exactly, exactly. So, I call this pain-driven development and it’s very important to be sensitive to pain and to pick up on your own pain and other people’s pain, and to ask people all the time, “Are you having fun? Is this pleasant for you? How pleasant is this on a scale from 1 to 10? And if it’s not, let’s talk about it and let’s make this more enjoyable.” And I think that pain is always a sign of friction, whether it’s confusion or bad assumptions or people being unpleasant. And community building is largely about identifying friction and removing friction.
CHUCK: I think it’s interesting. I was going to ask you if it was in this contract, the collaboration contract. And yeah, it is. And I just want to read this because this is probably one of the best explanations of really what a bad actor is that I’ve seen.
PIETER: [Chuckles]
CHUCK: And it says administrator should block “bad actors” who cause stress or pain to others in the project. That’s pretty clear. And then you clarify it further. This should be done after a public discussion with a chance for all parties to speak. A bad actor is someone who repeatedly ignores the rules and culture of the project, who is needlessly argumentative or hostile, or who is offensive and who is unable to self-correct their behavior when asked to do so by others.
And it is pretty broad or general but there are specific behaviors that are called out. And I really just like the fact that the community, again there’s the public discussion. Everybody gets to weigh in. And then if somebody won’t fix it, then they’re gone.
PIETER: Right.
JESSICA: I like the focus on the others.
CHUCK: Yeah.
JESSICA: It’s not about whether the actor intended to cause pain. It’s about whether others felt the pain.
PIETER: Yes, that’s right.
CHUCK: Well, the other thing here is that I’ve also seen some open source projects that devolve because there are the core folks who are actually correct, and by correct I mean the points that they’re making are actually right. But the way that they do it causes pain to other people because they’re argumentative.
PIETER: Right.
CHUCK: Or hostile or they use offensive language or they’re just mean to people and treat them like they’re less or stupid or something. And yeah, it hurts the project more than it helps it, even if they have their bright idea conceptually for the project.
JESSICA: Yeah. You can be right and also be not worth having around.
CHUCK: Yes.
PIETER: That’s right.
CHUCK: And we’ve all worked with that person.
JESSICA: Yes.
CHUCK: I can pretty much guarantee it. If you’ve been in software for more than a year, you’ve worked with that person.
JESSICA: Yeah.
PIETER: And the reason…
JESSICA: And Pieter is right. They symptom is I’m not excited about going to work.
PIETER: That’s right.
CHUCK: Yeah.
PIETER: And it should be fun. I think that’s it. I think it should be enjoyable. And I think that we should be much more, I think we’re so desensitized to pain and we’re almost taught to endure pain through school and university and work. The pain is part of it and that’s why we’re paid and we get a holiday, to escape pain and so on. I think that’s bullshit. And I think that we have to be much more aware of the joy of working with other people and how most people are great to work with. And then we’re able to pick up on the bad actors and say, “Look, you stop it. We know what you’re doing. And you can make as many excuses as you like. And you’re still basically hurting other people.”
JESSICA: What about…
CHUCK: Can we apply this to government?
PIETER: Oh, definitely.
CHUCK: [Laughs]
JESSICA: Yeah.
PIETER: You know, I write a lot about this kind of stuff.
JESSICA: What about the people? It mentions unable to self-correct their behavior when asked to do so by others. What do you do with people who really do want to be nice and contribute but just, when they mess up?
PIETER: To be honest, we don’t see that. And what we see are people very quickly finding the right place to contribute. If they’re able to go anywhere, they’ll find the right place to contribute. They will naturally look for guidance and mentoring to do things the right way. They’ll be highly sensitive of their reputation and the way they are seen by other people. So, it’s this clear rulebook.
CHUCK: [Chuckles]
PIETER: People will ask for it and they’ll follow it. And if you tell them on time, “Look, your code was ugly or your patch was confusing, or your commit messages were wrong,” they’ll be like, “Oh, how can I fix that?” And they’ll be really, really upset that they did something wrong and they’ll try to make it better. That’s the 95% case.
JESSICA: So, these people, the good contributors, are worried about their reputation but they’re not worried about their power level?
PIETER: They couldn’t care less about the power level. They want this to work and they want to be part of a happy, they’re playing Minecraft, right?
JESSICA: And well, we’re doing it for free, the contributions, so it had better be fun.
PIETER: Well, they’re using ZeroMQ in their work most of the time. ZeroMQ is three quarters built during working hours. But even so, people do care about their work. And I think that’s the common thing. I think we want people to like working with us or else we end up being alone. It’s no fun.
CHUCK: I want to ask a question as a community organizer, I guess, or maintainer or administrator. We have a community for this show. I have a few other communities that I’m either involved in or help administer. And it’s really hard to be the guy that comes in and says, “Look. We’ve had the discussion. You’re not changing. You’re not fixing it. And so, you have to go.” How do you handle that? How do you handle asking somebody to leave? Eventually you just wind up banning them.
PIETER: Yeah.
CHUCK: But is there a good way to do it?
PIETER: So, this is why I do it publicly. This is why I do it publicly.
CHUCK: Okay.
PIETER: So, I’ve done this a few times now. And basically, I realize the guy’s going to be banned anyway, right? He’s obviously not adapted his behavior and he starts to blame other people and try to say, “This is your fault. Your rules are rubbish,” and so on. And we let this happen until it’s really, really visible. And then I hold a trial basically by email list. And I make my accusations with some references. And then I ask for comments and I say, “Okay, let the person who’s being accused come forward.” And he will and he will not apologize and he will not say, “I’m sorry.” He will start blaming other people. Then I will ban him. And [inaudible]
CHUCK: Wow. It’s like you’ve seen this movie before.
[Laughter]
PIETER: Yes.
CHUCK: Because that’s almost exactly how it goes down every time.
PIETER: That’s right, every time.
JESSICA: Have you ever had the situation where the person who’s feeling hurt, who’s not having fun would be further harmed or embarrassed or traumatized by making it public by the public discussion?
PIETER: I think it’s good for people to express their pain. And I think, I do this very easily, almost to teach people to be open about this kind of thing. We don’t have to accept bad behavior. I literally don’t have to accept. We can say, “Look, this is causing us pain and grief and we don’t like it. We’re not enjoying it. And actually, we’re unhappy and this has to stop.” And I think that is absolutely okay to say that, when it’s shared by a few people. I think one’s own feelings are often distorted so I always ask other people what they’re thinking and I base on that, never my own personal opinion.
JESSICA: So, the scenario I’m actually trying to get at is what if it was sexual harassment and the victim didn’t want to make it public and is hesitant to report it at all for fear of having to talk about this in public when that just makes it worse, makes the pain prolong?
PIETER: Okay, so if there is some kind of personal targeting going on, that’s different. And I think that falls outside the scope of a community discussion. I think there, you have to invoke authority and execute authority pretty much outside the community discussion, because you can’t teach people how to, I don’t know if you can people how to not sexually harass. I think that’s either obvious or not obvious. You either respect your colleagues or people on the community, or you don’t. I don’t think that’s a thing that you can suddenly learn by watching other people being punished. I don’t know. I’ve never faced that, to be honest. So, I’m just blabbing here.
JESSICA: Right, right.
CHUCK: Oh, I’ve been a manager a couple of times and had to deal with this a couple of times. And it’s really tricky because a lot of times it’s hard to do anything without any real evidence, so if nobody else saw anything.
PIETER: Right.
CHUCK: Or witnessed anything, then it’s this person’s word against the other person’s word.
PIETER: Right.
CHUCK: And that makes it hard. And then the other thing is that some things are clearly over the line. And so, when somebody steps that far over the line, it’s like, “Look. This is very clearly not okay. And so, we have to remove you from the community.”
PIETER: Right.
CHUCK: But then there are other things where maybe somebody got comfortable with somebody else who liked to flirt with the line. And so, when they behaved in that way with somebody else who didn’t like to flirt with that line, they crossed it without necessarily realizing that what they said or did could have been construed that way. And so, in those cases, a lot of times, you can’t say, “Look, this is very not cool.” And, “If you get any more close to the line again, we’re going to have to remove you.” But those are situational and 99% of the time in my experience it’s usually the former, that they know where the line is, they stepped over it.
PIETER: Yes.
CHUCK: But those other cases, you sit down and you talk to everybody. You make sure that everybody feels safe. You make sure that everything is handled properly and then you react accordingly. But it’s hard, because you want members of your community to feel safe. You want them to feel like they can contribute. You want them to be involved. And that goes both for acting in a sociable manner without being accused of anything as well as a place where you can actually come be yourself and not be harassed or attacked for being different.
PIETER: And the thing, any situation with two people, basically it’s impossible to solve that. You can never tell who’s telling the truth and who’s lying if it’s word against word. And in fact, the problem is it’s very often, when you have an actually abusive situation, the person who is complaining the worse is the abuser. And I don’t mean sexual harassment. I mean in general. When you have a situation with an abused and an abusive person, and these are fairly common, then it’s the abuser who’s the most vocal and who is often claiming being the victim the loudest. And the abused person will often just be depressed and quiet and just numb. That’s the way it often goes.
CHUCK: Yeah.
PIETER: And it’s very hard [inaudible] to intervene in that situation. So, the first thing is with abusers, what you need is the word of many people.
CHUCK: Yeah.
PIETER: You need to have at least two, and hopefully three or four reports which point to one person being a bad actor with that kind of abuse. And then you can act. That’s the first thing. And if it’s word against word, then you have to teach people to define borders and to record evidence if there are abusive emails or chats being sent. They have to be recorded and that counts as evidence. And it’s what you do if you go to the police and say, “Look, my wife, my husband is beating me.” “Well, okay. Let’s go to a doctor. Let’s get a video of this.” The word is not enough. It’s simply not enough because that can be itself abuse by abusive people.
CHUCK: Yeah. One other thing I want to talk about with sexual harassment really quickly and that is that in a lot of cases the victim is, when you’re asking them what happened you’re basically putting them in the position where they have to go back through all of the feelings and embarrassment and helplessness and things that they went through when the harassment occurred. And so, it’s often very difficult for them to talk to because it is so emotionally heavy. It just weighs on them.
JESSICA: Right. There’s a cost to reporting.
CHUCK: Yes. And so, that’s exactly it. I don’t know if I could have said it better. So, it takes a certain level of being sensitive and it’s often uncomfortable for the people, person who it’s being reported to as well. And so, it’s often very hard to know what to do about it, because you don’t want to put somebody in a position where they feel unsafe again so that you can solve the problem.
PIETER: Well, I believe there’s a cost in not reporting which is much higher, in fact.
CHUCK: Yes.
PIETER: And I think that you can teach people to define boundaries. And this is what we do. With our rules we’re basically doing this by proxy. You teach people to define the boundaries very clearly and to signal violations very clearly. And it’s a thing you can teach people, even to stop this kind of slow erosion of borders, which becomes harassment. There’s a boundary.
JESSICA: When you can talk about it, when you can have a discussion about feelings.
PIETER: Yes, yes.
JESSICA: That helps a lot.
CHUCK: Yeah.
PIETER: Yes.
CHUCK: I’m afraid I might have cut you off, Jessica. Was there something else you were going to say?
JESSICA: Oh, I’ve got a bunch of things to say, but I don’t remember if it was anything in particular.
PIETER: [Chuckles]
CHUCK: Okay.
JESSICA: I actually have a whole list of questions.
PIETER: I think in any group, there is a thing about bad actors and finding bad actors. And there’s a lot of ways that bad actors can express themselves. And often it takes research to find them. But you do see pain. You do see pain and you see people being stressed. And you do need to be very careful about not jumping to conclusions and not allowing it to become a witch hunt, because you will often pick on the wrong people by that, doing that. But I think this is a common, a consistent thing with authority in a group, is to consistently monitor for bad actors and keep them away from the good contributors and good participants.
CHUCK: So, I want to change the topic a little bit, unless there’s something else that we need to talk about with bad actors.
JESSICA: I do have one question. A Ruby Rogues Parley participant asked this question. When we don’t tolerate people who struggle to be sensitive to the feelings of others, there are autistic people and there are just people who aren’t very good at that social situations and empathy. When we don’t tolerate them, are we being intolerant? Are we excluding?
PIETER: [Chuckles]
JESSICA: Can we say, we want an inclusive community and yet ban people?
PIETER: Well, yes.
CHUCK: Trick question, sorry. [Chuckles]
JESSICA: Oh, well [inaudible] what I think the answer is. But it’s a real question that people have, of is it hypocritical to exclude people for cursing or something?
PIETER: So, I have a blog post where I wrote something like the economics of evil where I’m claiming, and I do believe this, that you need bad actors in a community.
JESSICA: You need them to be in the community? Or you need them to show up and be kicked out?
PIETER: Both. So, it’s not just, I mean I think I love all people equally. [Chuckles] And that includes bad actors who are innocent at heart. Even the worst psychopaths are innocent at heart. And what they do, although they do harm and hurt individuals, is they actually do drive the community to be more organized and more social and more caring for each other. And so, actually this is why I say in our contribution policy is that everyone has a right to contribute. Everyone has the right to contribute. And it may turn out that eventually you’re bad. But everyone has the right to come in and make a mess and show themselves. And I believe that bad actors are essential. They’re the vitamin that keeps the rest of human culture going ahead happily.
JESSICA: Keep us on our toes?
PIETER: Keep us on our toes, yes.
CHUCK: Oh, and force us to think about these issues because we’re faced with them.
PIETER: Yes. And forces us to be more social and more open to good actors and more collaborative, and that’s our superpower as a species. So, I think bad actors have been our driving force in humanity, as in any social species.
JESSICA: So, they drive evolution?
PIETER: Yeah. I have a lot of [chuckles] blogging about this, Jessica.
JESSICA: Yeah. I love, I picked your post about this on Ruby Rogues some weeks ago. So, some listeners have probably read it.
CHUCK: Yeah. We’re getting close to a question that I do have, and that is we’ve talked about bad actors and getting rid of bad actors. But I’m really curious. How do you encourage or promote the effort of your good actors or your best actors? The people who are involved, that are contributing the most, or doing good things. Do they naturally rise to the top because the community rallies behind them? Or are there things that as administrators of a community you or I could do to promote what they’re doing because we like it.
PIETER: Right. So, what we found that works is allowing people to create the structure that they like best. And that means, within the ZeroMQ community which is I guess it’s a GitHub organization, start their own projects in there. And you’ll see that there’s a small section of people who are very good at leading new projects who are able to think of the whole thing, think of their users, think of the architecture, think of technical structure, understand the licensing, understand the whole space, and kickoff projects. And giving them space to do this inside the ZeroMQ community is very powerful, making that very fast and very smooth and letting the market then decide. And you get this basic economic model of division into specialties and then competition and collaboration between specialists.
JESSICA: And the competition is not political competition. It’s both of you, go create.
PIETER: That’s right. And in fact, if you look at the ZeroMQ mailing list which is a very interesting mailing list over the last years, you will see in the last three years almost no arguments at all. None.
JESSICA: Wow.
PIETER: It’s active but no arguments, no fighting, nobody with any strong difference of opinion. And the last time that we had a difference in opinion was when we had our old gang of core maintainers who disappeared and did something else. When they left, all the fighting left with them.
CHUCK: Oh, that’s interesting.
PIETER: So, yes. And I measured…
JESSICA: And then you’ve maintained that lack of fighting carefully.
PIETER: Not by any conscious effort except whenever there’s an argument I say, “Aha, there’s friction. That’s a problem to solve. Let’s go and find it.”
JESSICA: So, the argument becomes a clue to something that could be improved in the system.
PIETER: Yes. It’s either somebody with a mistaken assumption or hasn’t read it properly or there is a problem in the rules that we have to improve. So, this banning of bad actors I added the last time we had somebody who’s clearly causing pain. But for the most part, there’s…
CHUCK: Let me appear to be shocked. You mean it’s a communication problem?
[Chuckles]
JESSICA: Communication and you mentioned changing the rules, which changes the system without being anything wrong with any person.
CHUCK: How do you go about changing the rules?
PIETER: Sometimes people have assumptions. I edit the wiki page. [Laughs]
CHUCK: Well, I guess what it means is that…
PIETER: I just publish [inaudible]
CHUCK: Yeah, there you go.
JESSICA: Can anyone make a pull request against the rules?
PIETER: Yes, of course.
JESSICA: One of the questions that I saw go across Twitter the other day, there was a discussion about Codes of Conduct. I was going to ask you why you don’t have a Code of Conduct on ZeroMQ. But I see that it’s part of the C4, Collective Code Construction Contract, which is probably a level up from a Code of Conduct combined with collaboration procedures or contribution procedures.
PIETER: It’s also a development process, in fact.
CHUCK: Yeah. The thing is though is that most of the Codes of Conduct I see for say conferences or other organizations, they usually call out specific behaviors towards specific groups, or at least mentioned marginalized groups or things like that. And yours doesn’t. It’s just, if you cause stress or pain to others, you violate the rule.
PIETER: Yeah, if you cause stress and pain and you refuse to change, it’s not about making mistakes. Anyone can say something offensive by mistake. People do sometimes have stressful times in their lives and they can be rude to people. And that’s actually fine. That’s just humanity. But being persistent about it is trolling. And there the group has to look at this person and say, “You leave,” and defend each other from that.
JESSICA: There was a big controversy recently in the Scalaz community about this, about Code of Conduct. Part of the problem was the Code of Conduct was unilaterally put up, or some people feel that it was, whereas yours is community-built. That’s part of the help. But it’s a lot about how do you value contributions against rudeness, what is rudeness? What concern I have about yours, you mentioned that the way you know someone is a bad actor is there’s pain from multiple people. And I’m totally playing devil’s advocate and trying to poke holes in this right now. If as a woman I was on the mailing list and received comments that were hurtful to me but there aren’t any other women on that project, what if I’m the only one speaking up? Or as a minority?
PIETER: I think this is where the notion that it’s you as a woman being faced by one bad actor and that’s a problem that someone else has to solve for you or that [inaudible] I think is wrong. I think that the group should be empathic to your situation and should be sharing your pain and be very, very angry when someone comes in and annoys you.
JESSICA: Are they?
PIETER: Well yes, they would be, absolutely. I think this is also my problem with the Code of Conduct as a kind of, if it’s, well of course policy is good and of course rules are very important. But I think that what I would expect to see and what I would like to see is that the group itself takes care of bad actors and does that as part of its work, rather than having the authority…
JESSICA: And there’s nothing as effective as social pressure.
PIETER: Yes. And if someone in my community is hurt by an outsider I will defend that person like mama bear. I will come down as a ton of bricks on this person that’s hurting them and say, “Who do you think you are?” And I could be very, very, very brutal if someone does that. And I would be then seen by the people as being very rude possibly, although I don’t use swear words generally. But I think that protectiveness of people that we value is very, very important. It’s not just about the rules. It’s about our appreciation of people that we work with and that we know and that we care for.
JESSICA: I agree with you. And I want to make a plug for, if you’re wondering as a listener, you’re wondering what you can do to make our communities and conferences more inclusive, the biggest answer is when you see something mildly offensive towards women or minorities just say, “That’s not cool.”
PIETER: Mmhmm, exactly. And it doesn’t require a formal complaint. It requires raising your hand and saying, “This isn’t cool.”
JESSICA: Many people saying that consistently, that’s what changes the culture.
PIETER: Mmhmm, absolutely.
CHUCK: So, I want to go back to running the community in the sense that it looks like you have a chatroom, you have an email list. You have your wiki here. What are the most effective ways that you’ve found to open up communication within your organization?
PIETER: Well, because we are making software the very best is GitHub as it turns out. And in fact, it’s just pull request and discussion on pull requests which happen sometimes.
JESSICA: You mentioned earlier that one thing you wanted to get rid of was backchannel communication?
PIETER: Mmhmm, absolutely.
JESSICA: How do you do that? How do you remove that kind of communication?
PIETER: So, you force people to be explicit about why they’re making a change. And that’s of the process, is the change must be based on a clear problem description. You cannot simply say, “I made this bunch of changes,” and now and then argue the changes. If you can’t make a simple problem description and a minimal answer to that, then you’re creating a mess. And usually when you have backchannel agreements it’s about making a mess.
[Laughter]
PIETER: Because it’s like, “I want to make all these changes but I’m afraid people will be annoyed. So, let’s agree that you won’t complain and I’ll do this in something or other. And then we back each other up and then we go and make this stuff.” And everyone’s very offended. And in fact, you’ll see really, really offensive projects that work like this exclusively. There’s one famous one in the Linux kernel right now which is based on nothing else than massive disruptive change. It’s clear where the problem comes from. It’s having too few people are making too many changes too quickly. And so, if you force change into the form of pull requests on GitHub which are clear and which are small and which are clearly logged and tracked, then you’ve removed the scope for backchannel communication there. It’s like trying to make…
JESSICA: So, you insist on [inaudible] in public.
PIETER: Yeah.
JESSICA: That makes sense.
PIETER: You insist on transparency, clarity.
JESSICA: Transparency. So, it’s not that you can’t go offline and collaborate with your friend on something. But that you need to fully explain that to the public in the pull request.
CHUCK: Yeah, you have to give a clear value proposition to the community as to why it makes sense to them.
JESSICA: And keep it small enough to be comprehended by the community.
PIETER: Yes. And every…
CHUCK: And then the community culture doesn’t back change just for the sake of change. So, there has to be a reason.
PIETER: That’s banned, the idea that you just come and change stuff because you like changing stuff is considered to be vandalism.
JESSICA: On the other hand, if you want to create stuff because you like creating stuff…
PIETER: Even in the very simplest projects that we make, and this is for everything that we do now, every commit message with a few exceptions, is problem: something, solution: some minimal solution. That’s it.
JESSICA: It’s like writing a failing test.
PIETER: It’s writing a failing test. And every single change is a failing test and you’ve identified the problem. If someone doesn’t like the solution, they can post a different solution but they’ll agree with your problem. If they think your problem is a false problem, they can criticize a problem. And then your solution is taken off the table. The community can act very quickly.
CHUCK: I really like the focus on solutions, though. It’s so easy to focus on the problems. And when you start talking about the solutions, it’s really when you get stuff done anyway.
PIETER: Exactly.
JESSICA: Pieter, there’s a line from the introduction to you ZeroMQ book that I just love in relation to community building. It was, “The real physics of software is the physics of people.”
CHUCK: Oh, that’s so true.
JESSICA: And I agree. We can have all the theories we want, or all the hypotheses we want. But if we want some sort of theory of how things work underneath to back them up, it comes down to people.
PIETER: Always, that’s right. I was in a panel conference on software, open source conference in Athens almost ten years ago. And there was this question to the panel of, why do most software projects fail? I think it’s a famous quote that if people built software like they built bridges then they wouldn’t fail all the time.
CHUCK: [Laughs]
PIETER: And the panel was struggling and saying like, “Yes, well software doesn’t really obey physics like bridges do.” And I’m like, “Objection.” And then I [inaudible]
JESSICA: [Chuckles]
PIETER: But of course it obeys physics, but it’s physics of people. And we’re just not that clever. And we can’t handle that much complexity or depth of nesting or levels of abstraction. We’re not that smart, although we think we are.
JESSICA: I have noticed a lot of people, programmers like me are interested in cognitive science these days, in how do we think. But what is the physics of people? Is that psychology?
PIETER: Psychology, anthropology, yes. It’s economics.
CHUCK: Sociology.
PIETER: Sociology, politics, biology even to a large extent.
JESSICA: Mm. Yeah, I would love to have a team full of people with those kinds of undergraduate degrees.
PIETER: Yeah.
JESSICA: And programming experience.
PIETER: It’s funny how to become successful software developer on the large scale you have to do all of this stuff, really. Otherwise you’re working half-blind.
JESSICA: What can a member of a community do to make their communities better as an individual?
PIETER: So, it’s very hard to change existing communities. It’s really very, very difficult. And I’ve seen a couple of people doing this where they have an open source project which is clearly valuable and interesting and yet is really badly managed. And it’s typified by pain, different kinds of pain. It’s painful to use, it’s painful to contribute. There are pull requests waiting for six months and not getting merged, and so on. And you will see that the power structure cannot be changed. It’s basically, it’s grown and it’s hardwood. It’s dark wood and it stays the way it is.
So, if you are in a young project which can be changed, then you can lobby and ask for clear rules. And I would say, take our RFC 22 and adapt it if you want to. Modify it or use it. But rules like that, which give the right kind of balance between freedom and regulation. Good rules are very, very important. If you don’t have that freedom to make good rules then you can fork the project and you can redefine the rules. And I’ve seen this done.
JESSICA: As ZeroMQ got better when it’s forked.
PIETER: Yes, yes. And a contributor is, that’s why we have open source. It’s not just about seeing the source code. It’s about making forks and fixing authority problems. Bad authority is toxic.
CHUCK: I’m wondering a lot of these things that we’re talking about with bad actors and good actors and communication and all of these different things. It seems like the break down a little bit when we focus just on the technology. Do you think that’s the core problem with a lot of these projects that fail, is that the focus is on the technology rather than on the interaction and moving forward? Or is it something else?
PIETER: I think they fail because they are not applying science. They’re applying magic. Most failing projects apply magic. They say, “We believe in this and therefore we will invest in this based on belief.” And it becomes more and more just not even wrong, but incorrect. Whereas a scientific process is always wrong. It’s always an approximation of truth and accuracy. But you can always get better and better by investing in a different part. And almost by definition, science is always good and it’s always wrong and always gets better little by little. And magic is always completely, completely incorrect and gets worse and worse the more you invest in it.
JESSICA: Or completely right, if you were to assume that because you believe in it.
PIETER: Yes, if you want to just say, “Well, this is the way it is. And pi has the value 3 and that’s it.”
JESSICA: And that’s the expert mind that is mitigated by a group?
PIETER: The expert mind without the group is a very dangerous thing, because without the group to tell the expert where to stop being expert and where to come back to being generalists, the expert goes off into, makes C++. That’s as bad as it gets.
[Laughter]
JESSICA: What are some other great communities that you’ve found in open source or software or programming?
PIETER: I have to be honest and say that I’m only a contributor to my own communities. I’m very, very egotistical like that.
JESSICA: [Chuckles] Well, I imagine you spend a lot of time on this one.
PIETER: It’s a big one, a big community. And the projects I work on, I use. Open source as a thing has become beautiful in its vastness. And the amount of software that we have, I think all of it’s wonderful. I think Linux is, the whole ecosystem is fantastic. I think we’ve come so far from where we were when I began programming that I can’t even criticize anything that we have. Even the worst cases are still amazingly good. I would hate to say that any one of them is particularly amazing. Sorry.
JESSICA: Other than yours. Yours is clearly particularly amazing.
PIETER: No, I just think that we’ve gotten better at reducing the friction. I don’t even think it’s about the quality of the software. I think it’s about making software with less pain and less effort and making it slightly more accurate and allowing it to grow more scientifically. I don’t think it’s about…
JESSICA: I guess that makes sense.
PIETER: Yeah.
JESSICA: When you focused on the underlying causes of friction and of difficulty and of obstacles which are all people and the system in which the people are working, then beautiful software can emerge.
PIETER: Yes, precisely.
JESSICA: You’ve also focused on value, on solving problems so that it won’t just be beautiful software. It’ll be valuable software.
PIETER: For me that is how you define quality software, is by solving the right problems in an economical fashion.
JESSICA: I’ve been looking for a good definition of quality.
PIETER: It’s my conference question.
CHUCK: [Chuckles] My brain is totally blown away.
PIETER: [Chuckles] I’m sorry.
CHUCK: No, it’s a good thing.
PIETER: It’s my conference question to the audience, is how do you define quality in software? And it’s accuracy, it’s accuracy, solving the right problems and doing it without wasting too much time and money and pain.
CHUCK: Alright. Well, I have to actually start winding this show down so that I can do the next one. So…
JESSICA: You always ruin the fun.
CHUCK: I know. That’s my job. So anyway, I’m going to go ahead and take us into picks. Jessica, do you have some picks for us?
JESSICA: I have some picks. I had two but right now I can only remember one. So, let’s go with that. It’s a food pick. My pick is goat yogurt. And goat yogurt is amazing and delicious. And I use it in place of sour cream.
CHUCK: And it tastes like goat, right?
JESSICA: Yes.
CHUCK: It’s made with goat’s milk? Does that solve problems with lactose intolerance and stuff?
JESSICA: I have no idea. But it tastes delicious. It’s got that little bit of tang, like sour cream has. But it’s just yogurt. And yeah, good stuff. You can eat it plain. It’s probably healthier than sour cream because it doesn’t have the word cream in it. It’s got to be good for you.
My second pick is an article that I’m going to find and link to, about the broken stair. One of the tweets in response to Code of Conduct discussions recently was if the rest of the community tacitly accepts the behavior of the few, then there is no few. It’s everyone. And the broken stair post makes this even more explicit and is also about how tolerating rape jokes and rape culture. And everyone should read it. So, I’m going to pick it. And that’s all.
CHUCK: Awesome. Alright. I went and looked up goat’s milk and I have a dairy allergy. So, I was like, “I wonder if that would,” because I can’t have sour cream and things. This looks [inaudible].
PIETER: How about normal plain yogurt?
CHUCK: I haven’t tried it. I haven’t been that brave. I don’t want to be sick for a day because I ate yogurt.
PIETER: I give that to my cats and they absolutely love it.
CHUCK: [Chuckles] Awesome.
JESSICA: That sounds fun. Chuck, what are your picks?
CHUCK: My picks. My first pick is a book. I’m about halfway through it but I can’t put it down. It’s amazing. It’s called becoming a ‘Key Person of Influence’. And it talks about becoming a person of influence in your field. And I feel like I do some of the things there. But I want to take my career, my… I hate the word career. But just take my professional life and my life in general to another level.
And so, I was listening to, and this would be another pick, there’s a series of videos done by Nick Unsworth called ‘Life on Fire’. And he was talking to Neil Harrington who was on Shark Tank. He’s a big investor guy. He was one of the first people to do infomercials back in the 80s and 90s. And he was talking about this concept of being a key person of influence. And there are a couple of communities that I’m involved in that I don’t necessarily want to be a person of influence just for the sake of having influence. But I feel like there are conversations that should be happening that I feel like I can nudge a little bit to see if I can get people to talk about them.
And the other thing is that I feel like if I’m going to be part of a community, then I really ought to get involved to the point where I can make a difference. So anyway, so I’ve been reading a book and it is absolutely awesome. So, if you’re looking for that idea of where you want to go next and you want to be a person of influence even in a small sphere like a specific open source project or all the way up to Ruby or something, I have to tell you that the larger, more established communities are harder to break into that way. Go check out this book. It’s just awesome.
JESSICA: I don’t know. Key person of influence, is that just another way to say thought leader?
CHUCK: Kind of.
JESSICA: That’s a little [scary]. But there’s a big difference between…
PIETER: [Chuckles]
JESSICA: Influence and control.
CHUCK: Yes.
JESSICA: And you even made a problem statement there about discussions that you would like communities to have.
CHUCK: Yeah. The thing is, for me I feel like if have influence then I can open doors for other people. And if I have influence, then I’m empowered to build solutions either with software or other things, build solutions for communities that make them better. So, one example is there are certain areas that I feel like I could build software that would help the podcasting community. And it’s still young enough and small enough to where I feel like I can gain influence there. And then I can go in and solve these problems. And I can get enough feedback from the community because I have influence to actually make their lives better.
So anyway, there are a lot of things going through my head right now with this because I’m still in the middle of the book and figuring out what it means for me. But I have to say that I’ve taken some tests and I’ve done, I’ve talked to a lot of people and done a lot of introspection. And I have a lot of indicators that tell me that one of the main things that give me satisfaction I guess in my life, in my career, is social interaction and being able to help people. And so, being that person of influence solves both of those for me. And so, if you’re one of those people that like to go quietly work in the background then I admire you. But that’s not the way I’m wired. And I think those people are important, too. So, I’m not trying to say that anybody who is different is wrong. But for me, this is very much along the lines with the way that I think and the way that I want to make a difference.
JESSICA: Nice.
CHUCK: Anyway, so yes. So, they’re pushing all my buttons in this book. [Chuckles] So anyway, Pieter what are your picks?
PIETER: Well, I’m just starting a book by Karl Popper called ‘The Logic of Scientific Discovery’, English title, 1935. And Popper is a philosopher who basically defined modern science, the scientific method. He wrote about it a lot, interesting stuff. That’s one pick.
And my other pick apart from plain yogurt for cats because the cats love full fat in yogurt, this has changed my life recently. This is Bluetooth. It’s absolutely awesome.
[Laughter]
PIETER: Like seriously, Bluetooth stereo headsets. They’re like $15 on Amazon and I have little Bluetooth adaptors, my dongles. My living room is all quiet. I have three computers and a TV. All the kids are on different stuff. And I hear nothing.
CHUCK: Oh, yeah.
PIETER: So, yes, it’s really awesome. No cables to break, yeah.
CHUCK: I wonder if I could plug my kids into the TV with headsets.
JESSICA: Can I ask one more question? Because Chuck, your pick made me wonder. Pieter, why do you lead this community?
PIETER: Oh, world domination, Jessica.
[Laughter]
JESSICA: So, it’s really [inaudible]
CHUCK: ZeroMQ is only one step away from ZombieMQ.
JESSICA: [Laughs]
PIETER: There are all kinds of software and ZeroMQ funnily enough is what we call revenge-ware.
JESSICA: What does that mean?
PIETER: Revenge-ware is when you make a project with some people and they screw you utterly, completely, and totally. And you realize afterwards, and I’m not mentioning any names because this is a podcast, but they’re total and utter psychopaths. And so, you then dedicate years of your life to making stuff that actually works the way it should just to prove them wrong.
JESSICA: [Laughs]
PIETER: And it turns out to be a useful business and it turns out to make money and keep people happy.
CHUCK: [Inaudible] for that.
JESSICA: It solves problems.
PIETER: Yeah, it’s revenge-ware.
JESSICA: Everybody’s got to be motivated by something.
PIETER: [Laughs]
CHUCK: Yeah. Honestly though, what do you get out of administrating these communities?
PIETER: It’s really no work. It’s really just fun, first of all to make these large systems work and to keep people happy. And it’s not a lot of effort. It can’t be, by definition. It’s got to be cheap and low-friction. And I really like programming. I really like having these tools in my toolbox to use them as a programmer. They’re really, really fun to work with. And I value them very highly. And I’m protective of them for that reason. And it has just turned out [randomly] that these communities need people who can write RFCs and who can enforce them. So, that’s been my job. And I like doing it. And it pays my bills. And it’s fun.
JESSICA: [Chuckles] Thank you.
CHUCK: Cool.
PIETER: And it gets me to meet lovely people like you two, [even if this be] a podcast.
JESSICA: That’s right.
PIETER: I like this.
CHUCK: Yeah, next time I’m in Belgium. I’d love to go to Belgium. Anyway…
PIETER: Belgium can be quite fun, Chuck.
CHUCK: Well, someday.
PIETER: It’s not Las Vegas, though.
JESSICA: [Chuckles]
CHUCK: My grandmother grew up in León and I’d love to go back there and go see some of the other countries around there.
PIETER: León’s nice.
CHUCK: Alright, well I need to wrap this up. I feel bad doing it but I have to. So, thanks you guys. It was a terrific discussion, really a lot of things for me to think about here.
JESSICA: Yeah, yeah. I’m going to have to tweet a lot of things from the transcript.
CHUCK: Yeah.
PIETER: [Chuckles] Nice talking to you both. I really enjoyed this.
JESSICA: [Thank you] [inaudible].
CHUCK: Alright. We’ll wrap up and we’ll catch you all next week.
[This episode is sponsored by WatchMeCode. Ruby and JavaScript go together like peanut butter and jelly. Have you been looking for regular high-quality video screencasts on building JavaScript done by someone who really understands JavaScript? Derick Bailey’s videos cover many of the topics we talk about on JavaScript Jabber and Ruby Rogues and are up on the latest tools and tricks you’ll need to write great JavaScript. He covers language fundamentals so there’s plenty for everyone. Looking over the catalogue, I got really excited and can’t wait to watch them all. Go check them out at RubyRogues.com/WatchMeCode.]
[This episode is sponsored by MadGlory. You’ve been building software for a long time and sometimes it’s get a little overwhelming. Work piles up, hiring sucks, and it’s hard to get projects out the door. Check out MadGlory. They’re a small shop with experience shipping big products. They’re smart, dedicated, will augment your team and work as hard as you do. Find them online at MadGlory.com or on Twitter at MadGlory.]
[Hosting and bandwidth provided by the Blue Box Group. Check them out at Blubox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]
[Would you like to join a conversation with the Rogues and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at RubyRogues.com/Parley.]
