Stepping Down
Updated Nov 9, 2017: When I originally posted this, nearly two years ago, things were different. As folks may know, I returned back to leadership of nanomsg, and have since released several significant updates including version 1.0.0 and follow ups. I'm also in the process of a complete architectural redesign and rewrite (nng), which is fast nearing completion. This post is left here for posterity, but if you've wandered here via search-engine, be certain that the nanomsg community is alive and well.
(Quick reminder that this blog represents my own opinion, and not necessarily that of any open source project or employer.)
For nearly a year, I've been primary maintainer of nanomsg, a library of common lightweight messaging patterns written in C.
I was given this mantle when I asked for the nanomsg community to take some action to get forward progress on some changes I had to fix some core bugs, one of which was a protocol bug. (I am also the creator of mangos, a wire-compatible library supporting the same patterns written in Go, which is why I came to care about fixing nanomsg.)
Today, I am stepping down as maintainer.
There are several reasons for this, but the most relevant right now is my frustration with this community, and its response to what I believed to be a benign proposal, that to adopt a Code of Conduct, in an attempt to make the project more inviting to a broader audience.
I was unprepared for the backlash.
And frankly, I haven't got enough love of the project to want to continue to lead it, when its clearly unwilling to codify what are frankly some sound and reasonable communication practices.
As maintainer, I could have just enforced my will upon the project, but since the project existed before I came to it, that doesn't feel right. So instead, I'm just stepping down.
I'm not sure who will succeed me. I can nominate a party, but at this point there are several other parties with git commit privileges to the project; I think they should nominate one. Martin (the founder) still has administrative privileges as well.
To be clear, I think both sides of the Code of Conduct are wrong -- a bunch of whinny kids really.
On the one side, we have people who seem to feel that the existence of a document means something.
I think that's a stupid view; it may have meaning when you have larger democratic projects and you need therefore written rules to justify actions -- and in that case a Code of Conduct is really a way to justify punishing someone, rather than prevention or education. To those of you who think you need such a document in order to participate in a project -- I think you're acting like a bunch of spineless wimps.
This isn't to say you should have to put up with abuse or toxic conduct. But if you think a document creates a "safe space", you're smoking something funny. Instead, look at the actual conduct of the project, and the actions of leadership. A paper Code of Conduct isn't going to fix brokenness, and I have my doubts that it can prevent brokenness from occurring in the first place.
If the leadership needs a CoC to correct toxic behavior, then the leadership of the project is busted. Strong leadership leads by example, and takes the appropriate action to ensure that the communities that they lead are pleasant places to be. (That's not necessarily the same as being conflict-free; much technical goodness comes about as a consequence of heartfelt debate, and developers can be just as passionate about the things they care about as anyone else. Keeping the tone of such debate on topic and non-personal and professional is one of the signs of good leadership.)
On the other side, are those who rail against such a document. Are you so afraid of your own speech that you don't think you can agree to a document that basically says we are to treat each other respectfully? The word I use for such people is "chickenshit". If you can't or won't agree to be respectful towards others in the open source projects I lead, then I don't want your involvement.
There's no doubt that there exists real abuse and intolerance in open source communities, and those who would cast aspersions on someone because of race, religion, physical attribute, or gender (or preference), are themselves slime, who really only underscore for everyone else their own ignorance and stupidity. I have no tolerance for such bigotry, and I don't think anyone else should either.
Don't misunderstand me; I'm not advocating for CoCs. I think they are nearly worthless, and I resent the movement that demands that every project adopt one. But I equally resent the strenuous opposition to their existence. If a CoC does no good, it seems to me that it does no harm either. So even if it is just a placebo effect, if it can avoid conflict and make a project more widely acceptable, then its worth having one, precisely because the cost of doing so is so low.
Yes, this is "slacktivism".
I've been taught that actions speak louder than words though.
So today I'm stepping down.
I'm retaining my BDFL of mangos, of course, so I'll still be around the nanomsg community, but I will be giving it far less of my energy.
Comments
To defend at least part of the "those against" community, they may good reason to object. CoC's are typically neither comprehensive or concise, tend to be written by authors with their own agendas, and are often leveraged (via "local interpretation") to justify maladroit sanctions by project management or mob justice by a community.
Example: I once left a project because my use of "see man page" was described as being offensive to a certain demographic of which I'm a member. The fully-sighted person suggesting the revision took offense to my pointing out his brutish ignorance and autocratic mores. (Ok, so not in those words.)
When such d*ckh**ds are allowed to exist within a community, it often causes valuable contributors to leave (they're usually not allowed to criticise bad code). The end result is often a stagnant project, with project leadership complaining that they cannot attract/retain good volunteers.
To go back to my "those against" point... If "those against" like working on the current project enough, it might be (to paraphrase a 1960's television commercial) that they'd rather fight than quit. Their admitting that codified governance is needed/justified may be just a bit too unattractive, or that they've lived through poor implementations of such in past projects.
I hope that things might cool enough that it's possible for you to change your mind. Thing is that if you intended to introduce political tones into the project that weren't there in the beginning, perhaps you should have made that clear when you took it over.
It's such a pity to see such energy diverted from just doing good work.
Laeeth.
Given this, a lot of long and hard thinking is necessary before establishing a CoC. At the very least, they should be written to explicitly not apply to non-project areas, to specify political viewpoints as one of the non-discriminatory classes, and to establish bringing in off-site disagreements as a violation of the CoC. That would be helpful in showing whether the CoC advocates are really interested in ending harassment or are more interested in using the code as a political weapon.
Protecting political opinions is tricky too, because a lot can be covered there. The KKK is a political organization after all.
What people do in their political beliefs *outside* the project, who cares. Inside the project, politics have no business, except the specific politics that are either internal to the project or somehow directly relate to the project's mission.
My own political opinions are unpopular -- I've got some fairly strong libertarian leanings, and someone spat that I'd start spouting Ayn Rand as an epithet. (In fact, I considered it a *compliment*, if an unintentional one.)
Still, that position has no business getting involved in my open source project work, and we've seen other projects such as illumos where members have tried to drag in their controversial political opinions. Hijacking the project for one's political platform is unacceptable, no matter the platform. (Except in the rare case of a project that exists for a political platform -- such EFF advocating against laws that restrict strong crypto.)
All of this comes down to leadership.
Bad leadership can do bad things. With or without a CoC. A bad CoC may make bad leadership *worse*. But I don't think a badly written CoC can turn good leadership bad. It also can't turn bad leadership good.
At the end of the day, I view their existence as a statement of intent. One should review the public actions of the project's leadership to determine whether this is consistent with what one desires when choosing a project.
Put another way, CoCs are meaningless, except as a bad excuse. (Which can be used whether they exist or not, for various purposes.)
Mostly, a quiet gentle word works much better than initiating some kind of bureaucratic process that has the appearance of objectivity but never really can be so.
Rand has her deficiencies as a thinker and must be understood in the context she was writing, but she really wouldn't be sympathetic to what a code of conduct represents.
I read a little of the mailing list - people responded inappropriately to your suggestion, and I can understand your feelings - really who needs this for a project that is primarily a labour of love. But one needs to develop a thick skin when operating in this domain, because people say things electronically that they never would face to face. And there are very real cultural differences in what is considered appropriate, which one must accommodate and tolerate to a certain extent.
You spoke about leadership. Really you have done a good job up till now. You recognized that someone needed to take charge and stepped up. Is it really good leadership having stepped up to abandon things without putting in place a plan for succession?
When you introduced the idea of a code of conduct, you didn't say this is really important to me, and I don't think I can be involved without it. Since it evidently was, perhaps you could have been clearer in your communication, and recognize that not having done so shaped the responses you received.
A leader needs to recognize that sometimes they make mistakes and take responsibility for them. None of us are perfect, and it's easy for things to get overheated when people aren't looking each other in the eye face to face. Objectively speaking it's something like a storm in a teacup.
Why jeopardize the whole project over such a thing? Surely, at least better to stick around as caretaker whilst actively cultivating somebody to hand this over to. That's what I would understand the role of a leader to be.
But I hate just as much the sentiment that we can't have a CoC because "1984". Or whatever. And more to the point, I hate that folks would rather keep the project "exclusive" without the CoC, than try this simple measure to reach out. They've artificially limited the reach of the project, IMO, and I don't want to waste time on a project that doesn't consider increased participation and diversity something worthwhile -- especially when the only thing it might cost is the creation of a document that says some fairly basic things about unacceptable behavior.
It's not the CoC that is important to me. It's the effort to reach out and be inclusive that is.
I didn't step "up" to maintain nanomsg, so much as it was thrust upon me. I had my own project, that was a fork, and Martin basically just decided to "name me" the new project maintainer without consulting me first. I cared about the technology (I still do), so I went ahead and tried to do my best to fill the role.
This cost me countless hours.
So yes, when I tried to do something to make the project more appealing to a wider audience, some of whom might actually have helped with the work I was doing, I was pretty upset when that effort got rejected.
If I reenter this space, it will be with a project where I choose the governance (BDFL) from the outset, and I won't ask permission to do things like adding a CoC document. I couldn't do that here, since I felt the project wasn't really "mine", but rather I was just filling Martin's shoes.
Martin or someone else can nominate new leadership. I may go ahead and revive my own fork, but more likely would be that I'd start from scratch with a new implementation of the wire protocols. Whether anybody cares about that or not is an open question. At least I won't have to deal with the state machines from hell, and I won't have to fell obligated to fix bugs in software I hate, or accept decisions from the peanut gallery that I don't agree with.