Kindness and open-source projects

Brett Cannon is a longtime Python core developer and member of the open-source community. He got to check off one of his bucket-list items when he gave a keynote [YouTube video] at PyCon 2018. That keynote was a rather personal look at what he sees as some problem areas in the expectations of the users of open-source software with respect to those who produce it. While there is lots to be happy for in the open-source world, there are some sharp edges (and worse) that need filing down.

He started with his background as a way to show that he has the experience to give this talk. He is the development lead on the Python extension for Visual Studio Code, which is Microsoft's cross-platform open-source code editor. He noted that the two qualifiers for the editor are probably shocking to some. It was originally a community open-source project; Microsoft hired the developer behind it and it is now "corporate open source", Cannon said. That means there is a company backstopping the project; if the community fell away, the project would continue.

He has been a Python core developer since April 2003; he got the commit bit shortly after attending the first PyCon (and he has attended every PyCon since as well). In contrast, Python is community open source; if the community disappeared, the project "would probably collapse within a month". He has contributed to over 80 open-source projects along the way; many of those were simply typo fixes of various sorts, but it has given him exposure to a lot of different development processes. "I've been lucky enough to have a broad range of exposure to open source overall."

What and why

An open-source community comes about once there is an outside contribution to a project; one-person projects aren't really a community. Once you have that, one question is what the purpose of that community is. Collaborating on the maintenance of the project is clearly part of it, but that needs to be balanced with having some fun. If there is no fun involved, people are likely to leave; if there is too much fun, not much will actually get done and the project will suffer.

There is also a balancing act around sustaining an open-source community; the project must attract new people while still retaining (most of) the current people. Python has been around for 28 years ("thanks to Guido"), for example, but there has been a natural level of attrition over that time; people have children, get bored, burn out, die, and so on. Attracting new people can be tricky, especially in an older project, because the processes that the project has built up over the years do not fit with the new ways of doing things. On the other hand, the longtime contributors have lots of valuable knowledge and experience that the project doesn't want to lose; once again, a balance must be struck between attracting new developers and retaining the existing ones.

In his mind, the goal should be to work together to come up with reasonable expectations for participants in the open-source ecosystem so that it works for everyone. Participants in open-source projects are generally either volunteers or being paid to work on it by someone "other than you", so we need to work together to bring about a symbiotic relationship that makes open-source projects that are "sustainable and usable and workable by everybody".

But that's where things are breaking down to some extent, he said; "we are not exactly succeeding at this goal all of the time". He put up a tweet from Cory Benfield that said: "I think working in OSS has made me more bitter and short-tempered". Benfield is a major contributor to various networking pieces for Python (urllib3, HTTP/2 support, and the Requests library). Cannon said that the tweet showed that Benfield had been put into a terrible place. If Benfield's partner noticed his bitterness and its relationship to his work on open-source software, they might ask him to choose between them. Hopefully, Benfield would choose his partner, but it is truly sad that it could come to that. It is also sad that Cannon has to worry that Benfield (and others) might be put in that position.

This has actually happened to him, Cannon said. He warned at the outset that some parts of the talk would be fairly emotional for him; recounting this was clearly one of those areas. In October 2016, he had to take a month off to "detox from open source" due to three consecutive months of "bad interactions from the community". It was a tough time for him, but since then he has thought a lot about what happened. That is where the talk has come from. Basically, how do we insure that people are not put into the position where their partners have to talk to them about participating in open-source projects? While 2016 was a particularly bad year for burnout in the open-source world, this problem existed before that and still exists today. He makes sure to not work on open source for one day of every weekend so that his whole weekend cannot be ruined by one bad interaction.

These things happen, he said, because "people tend to forget two key things" when interacting with open source. The first is that open source has a cost; we like to tout that it is "free as in beer" and "libre", but there is still time, effort, and emotional output in it. When he works on a project, he is taking time away from his family, friends, wife, and cat. When someone sends him a bug report or a pull request, they are asking him to spend some of his time away from those other things. This has led him to think that open source should be "a series of unsolicited kindnesses"—like people giving you gifts you didn't ask for. If we view open-source interaction that way, it would go a long way toward making sure that people don't feel "abused or used or just misunderstood". It would lead to "much better interaction across the board".

Scenarios

He went through some typical scenarios to show who is doing a kindness, but also describing where it can go wrong. He used himself ("Brett") as a maintainer and "Stuart" as contributor to illustrate the ideas. Brett provides some project that Stuart uses, so Brett is providing a kindness to Stuart. But in some cases, releasing an open-source project can be like leaving a pamphlet espousing an offensive position in a public place. He said that he always had trouble finding an example for this point until a recent controversy about a "joke" in some documentation for a large open-source project.

The next step in open-source interaction is providing feedback, which is a kindness bestowed on Brett by Stuart—except when it isn't. The example he gave is a thread he read on Hacker News that pointed to blog post that had some complaints about Python. Those kinds of posts are actually often useful; Cannon has filed bug reports and gotten things fixed based on some of them. The one in question, though, started by saying the author liked Python, but then said things like: "this is stupid", "that is dumb", and "what the hell were they thinking?". As he read it, he could pin many of those decisions on himself and other friends of his in the Python development community. While the author may have believed they were talking strictly about the features in question, it was received as calling Cannon and the rest of the team stupid.

The internet is not written in pencil, he said, it is written in pen. That blog post will be around forever. He is not saying that you can't criticize, but that you should find another way to do so. Or perhaps come to the python-dev mailing list to ask why things were done a certain way; in many cases it is for backward compatibility reasons going back to the dawn of Python (which is older than Unicode, he noted). There's always a way to phrase criticism so that you can still have a reasonable conversation about the topic—without being mean about it.

Next up is submitting a contribution, which can sometimes be likened to someone giving you a puppy you don't want. It may seem like a cute bundle of fur to you, but to the recipient it may seem like ten or more years of feeding, walking, and cleaning up. If he accepts a pull request and merges the code, he is responsible for that code for ten years or more. He needs to consider a lot of things before accepting a patch, such as whether it will break existing code or obsolete books printed on dead trees; "it's really mind-blowing when you start thinking about the ramifications".

Another way this process can go wrong is when someone submits a patch that says "this is really broken" or "I'm fixing your mess". Those statements include negativity that isn't needed. It would be better to say something like "I think I can help improve this". Things can be phrased in a positive light, without being outwardly negative toward anyone, he said.

Feedback on a contribution is a gift as well, but one that can be mishandled or misunderstood. Instead of something like "you're doing it wrong", a simple thanks is a good place to start. He once submitted a half-dozen typo fixes for a project using the GitHub interface, which made it easy to create a pull request (PR) for each fix. That was met with: "don't you know you can send one PR?" Rather than trying to shame him for his (perceived) lack of knowledge—he did know that, but the GitHub interface makes it much easier and faster to file typos as you find them—a "thank you" and a suggestion for future PRs, or to ignore the PRs entirely, would have been better.

When a maintainer decides to turn down a contribution, that can be misunderstood as being personal, Cannon said, but it is not meant that way. Part of what caused his need for an "open-source detox" was a statement from a contributor: "I'm mad at you because you are preventing me from contributing." That person has subsequently apologized, but Cannon was not trying to block anyone; he was simply keeping his obligations to the project in mind.

In some sense, maintainers are giving a gift to Guido van Rossum (and the other maintainers) by doing what they do, but there is plenty of room for disagreements and misunderstandings there as well. Cannon said he has come close to tears arguing with another core developer in email; things can get heated because everyone cares a lot about Python and its future. But what's really needed is for everyone to take a step back before replying; assume good faith and that the poster did not mean it in the negative way you are interpreting it. It's hard to do, he knows, but it can really help. "The point is that we all need to improve."

If his talk has seemed biased toward maintainers, that's because it is, he said. Because of scale factors, maintainers get a lot more abuse than contributors do. By way of a show of hands, he demonstrated that of the 1500 (maybe even 2000 or more) attendees at the keynote, less than 10 of them were Python maintainers (i.e. core developers). So it's easy for 0.1% or even 0.01% of the community to be negative and to still have a huge impact on the maintainers. He does not know whether the saying "it takes 10 kindnesses to undo one negative action" has been tested in psychological research, but it feels about right to him.

Giving kindness

In his opinion, everyone should act like any kindness they do does not require anything in return. When someone sends him a PR, he wants them to realize that he might have to reject it; they should just view it as an attempt to do him and the community a kindness. It goes the other way as well, of course. If he asks for changes to the PR before he can accept it, he is doing that as a kindness; if the contributor does not have time or interest in making those changes, so be it. It is not a bargain that is being made; doing a kindness for someone does not obligate them to do anything in return.

The flip side is for those who receive a kindness to treat it as such. But people have different styles of communication and English may not be their first language, so they may not necessarily come across as kind in their email. Give people the benefit of the doubt, Cannon said; it is also perfectly reasonable to let people know that they aren't coming across as being kind. A gentle prod in the direction of kindness is often all that is needed to get the conversation back on the right track.

The proper way to act toward each other is to be open, considerate, and respectful; it is no coincidence that these are the attributes listed in the Python Community Code of Conduct. This makes for a "kind of three-way handshake of kindness", he said. As with the three-way handshake to establish a TCP/IP connection, the kindness handshake can break down at any of the three steps. One could not be open to someone's contribution, for example, not considerate of a maintainer or contributor when giving feedback, or not respectful of the other party's responsibilities or constraints. "I know that seems shockingly difficult sometimes, but that's all it takes for this whole endeavor of open source to function reasonably."

We all have bad days at times, but we can all step away from our email client or the GitHub issue tracker for an hour to get a clear head before responding. We can also scrutinize our messages before sending them to make them work better. He suggested three criteria to consider: assume you are asking for a favor from the recipient, assume that your boss will read what you say, and assume that your family will see your message. If you keep those things in mind, it will hopefully make you stop and think about how you are phrasing that message.

In a nutshell, he is trying to suggest that people "pay for open source with kindness". If that doesn't happen, those who participate in open source may start to regret it. That can lead to burnout. We also don't want to put people in a position where their partners have to ask them to reduce their open-source work because it is making them a worse person.

He noted that the Python community as a whole is a friendly and welcoming place. Some other communities are not that way and people that he has talked to about his presentation have made it clear that there are communities where it is "so much worse". If he can feel mistreated in "this awesome amazing community", he is really concerned for the open-source community as a whole.

He concluded by asking that the next time folks were providing feedback, writing a blog post, submitting or reviewing a PR, or composing a tweet, that they think about being kind; "we're all just trying to make this work".

The Python community tends to be somewhat more introspective than others, which makes a keynote like this possible—welcomed, actually. There are certainly communities where it is far more difficult to find kindness or sometimes even civility. There are many reasons why the Python community is more welcoming than others, but being willing to take a hard look at where it does go wrong at times, as Cannon did here, is surely part of what makes it work.

[I would like to thank LWN's travel sponsor, the Linux Foundation, for assistance in traveling to Cleveland for PyCon.]