Abstract: The author is a core Python developer who has volunteered to contribute to the Python language in his spare time for fourteen years since 2002. But this kind of living Lei Feng behavior did not get the developers’ understanding, a lot of people even with the command of the tone of the living Lei Feng again hard again tired also have to work for their own free.

Many people will order open source project maintainers to fix this or that bug, force maintainers to fulfill their unreasonable feature requests, and physically attack open source project maintainers when things go wrong. Asking others to work for free deprives others of their time and kills them. The author takes a month-long break to consider issues such as collaboration and basic courtesy in the open source community.

Why have I suspended my volunteer work to maintain the Python community

On October 1, 2016, I decided to stop doing maintenance work on the Python community, which has been a month now. Since I joined Python-Dev in June 2002, I have devoted almost all of my energy to maintaining the Python open source project. Even during holidays, we work via Email. It’s been 14 years so far, and it was a big break for me.

Why did I take a break from maintaining the community?

The reason I made such a difficult decision after 14 years was because something happened in July-August that made me wonder if I need to continue.

When I first started maintaining the Python community, users just asked me to help fix bugs. But if I don’t fix it in time, I get a steady stream of emails expressing their frustration that I didn’t fix it in time, that I’ve given them enough time and hope, but I’m not willing to help them solve the problem.

Remember that there was a bug in Python 3.5.2 when the new version 3.6 was released before it could be fixed, causing the bug to also exist in the new version. As a result, non-core developers say that there should be a release constraint. There are also user comments, fixing a bug is a snap, and I am not willing to deal with it. Be aware that not all bugs are easy to fix, especially if they span multiple releases.

When I tried to explain the complexity of fixing bugs in Python, I was immediately accused of making excuses. Two months later, I saw the same complaint on Twitter: all because of a bug in a venv activation script for a non-mainstream shell (in other words, it doesn’t affect Python’s execution and the system doesn’t break because of it). And they never try to understand how difficult it is to keep Python functioning properly.

The next thing I know, I get feedback about the problem tracker — why is it proposing semantic fixes? One Saturday morning, I replied explaining why, just in case anyone thought it was a bug and spent a whole weekend fixing it. Instead, my well-meaning explanation was mistaken for an attempt to prevent them from contributing to the community. (These users later apologized to me when they learned the truth.)

As a Python developer and community manager, I feel that some threads based on Python are used more than others. Very few users give me feedback on their usage. In the maintenance process, WHENEVER I saw the community members using comments to attack each other, I was very frustrated and felt that I did not maintain the community well.

When I read Nadia Eghbal’s Road and Bridges’ REPORT on the Ford Foundation’s OSS maintenance, I realized that more than a decade of quiet effort and suffering was a waste. (I think every open source project user should read this report). The report clearly states that the community members are asking me for work with no concept of time, because I have been volunteering to work overtime to solve their problems without asking for anything in return. Over time, they took it for granted and I was expected to address any issues they reported back. The report illustrates this phenomenon, and most people want me to help them in their spare time, actually finding some reason for me to work on problems related to Python. (I’ve been involved in all forms of business content since I joined Microsoft, and Python has been part of my work for 14 years).

An analogical explanation of open source work

Many of us who are project maintainers must be surprised to learn about our working conditions. (It’s not an exaggeration to say all maintainers. So far, I have never met a defender who was not abused.) To make it easier to understand, I’ll try to make an analogy.

Imagine, as a child, that you come up with a new and very interesting game (maybe a board game, maybe some other game at the playground). I told my friends about the form and rules of the game. Friends feel particularly interesting to play up. Then a new group of friends want to join, so you reintroduce the game… Later, more and more friends want to join, and you have to introduce the game every time. To save trouble and make it easier for more people to get involved, you decide to spend the time and money to create a manual that contains the game’s contents and rules. In this way, as long as a small partner wants to join, directly read the manual can learn how to play the game.

Then people started suggesting improvements to the game, adding content or rules. You think it makes a lot of sense, so you take the advice, update the rules, re-create the manual, and send it out to those who need it. Later on, there are constant requests for improvement, and you need to constantly improve, revise, and redo the manual. You don’t mind that these suggestions add to your workload in order to make your game better.

However, along comes a group of unknown friends who demand that you must add a “hit” rule. You resent this commanding attitude, and more importantly, you don’t want to add violence to your game. You politely refuse, and they attack you, taking the manual with them. Of course it pains you to see the fruits of your Labour treated so rudely.

In the face of difficulties, how to adjust mood?

Now suppose Python is the game, and it’s some software developer who wants the rules changed. These developers keep coming at you with all sorts of demands: “This needs to change,” or “You should change this.” They don’t approve of what you’re doing, and they don’t listen to any explanation. They’ll walk away when they stop insisting, but that doesn’t mean they think you’re right. Therefore, when someone asks you “why are you doing this?” the best response is not to respond at all.

In addition to the users who constantly question me and give me feedback, I am also tired of the Python users who take it for granted that I should provide their services for free. The worst they can do is download and install the program themselves. (If you’re running Linux, you don’t have to do this because Python is already installed, so just type “Python” into the terminal to start the interpreter.)

I spent a lot of time developing Python to make it free for users to use, but there were always users who had the attitude that they had bought the product and I had to give them “after service.” They thought using my Python was helping me raise awareness, and I wanted to return the favor. The fact that I took the time and effort to develop this code for them to use for free was a gift to them. However, in the eyes of these users, it seems that I still need to take more time and energy to help them for free.

I am of the view

When I go to Python conferences, I never get the impression that people are unhappy with my design or hate Python. Of course, I have met some extreme people who say nasty things to me when they find out who I am. But I can ignore them and reach out to people who are passionate about their work and support Python.

There are about two weeks a year when I get something positive, but there are dozens of weeks when it’s not. While some PyCon users say “thank you for your work,” most of the time I get an understated “thank you” when I take the time to help them out. Online, from both core developers and regular participants, the most I hear is whether I can meet their needs for XX or XX, and there are some daily greetings, but they are in the minority. Some people say that it takes 10 acts of kindness to offset the damage caused by one act of malice, but I don’t think the weight of good and evil can be measured by 10:1.

Community relations for open source work

What should I do next? I don’t want to stop contributing to Python. I made a lot of friends in the community, and whenever I stayed at home, we would exchange interesting things online. But now, something had to change. But until I knew what I needed to change, I had to think the right way to keep things from going wrong.

First of all, I see open source software as open development, meaning that as you share software, you also share responsibility for maintaining it. This means that I don’t see open source as a requirement, as other free software does, but rather as a way to work with users to make the software more maintainable. The success of all this depends on the relationship between the project maintainer and the other users who take their obligations seriously.

Let’s look at the different types of users involved in this relationship. The biggest group is people who don’t even use the program, and they usually ask us, does their system work for this program? Once they find out that the project doesn’t work for them, they might say, “I can’t use it, rubbish!” And not realize that the software wasn’t built for everyone. Whenever this happens, the project maintainer cannot fight back, otherwise the situation will be worse.

The second group is the real users of the project, who often turn to the project maintainer for advice on how to solve the problem. Therefore, their presence can promote the project better. However, when they ask project maintainers to solve problems on their behalf, they may be disappointed. As we said earlier, open source requires people to cooperate with each other to maintain the project. This means that users can suggest improvements to the project maintainer, but they cannot insist that the maintainer do so. In other words, you can ask, “Have you considered adding this feature?” Don’t say, “You have to add this feature,” because project maintainers are volunteers who contribute to the project for free, but that doesn’t mean they have to take orders from you.

The third group is bug providers who report problems encountered during usage to maintainers. As a result, bug providers often want a dedicated area of the community for bug feedback and, preferably, bug classification. What project maintainers want is for bug providers not to require them to fix all bugs. However, when a bug is reported many times, it is important to pay attention because the problem can be serious. There are two key things I would like to tell you about bug providers: First, many bugs are reported every day, and your feedback is just one of thousands. Don’t take your bug too seriously. Second, a bug may occur that affects your usage, but fixing it is not an easy task, so you have to be patient.

The fourth group is patch fixers. They are the most difficult to manage, because patch fixes can only be done when the project maintainer allows them to, and before that, the fixer has to do a lot of work to check for security vulnerabilities. For project maintainers, they must give patch fixers more patience, because it is not easy to review all patches, and not every patch can be fixed. I recognize that this relationship is something Python projects need to improve, so I’m working on moving the project to GitHub to make the patch review process smoother.

There are also connections between project maintainers. As direct representatives of a project, we depend on each other, monitor each other, and support other users in their attempts to maintain the project. And the most difficult thing for us is to reach consensus, because everyone has different ideas.

Expectations for the future

After a month away from volunteering, I hope to make a difference in the community so that the next time I take time off it’s for a vacation, not job burnout. Going forward, I will focus on increasing my work with the community.

In terms of the relationship with users, I think there is no need to deliberately change, just let nature take its course. I still spend my free time checking the emails my users send me to answer their questions as quickly as possible. (I usually choose night and weekend codes, but it depends on the mood.)

My relationship with bug providers is going to change a lot, because I’m going to stop fixing bugs. While I appreciate their willingness to spend so much time looking for bugs, fixing bugs is very basic and takes a lot of time. So I decided to leave it to technical beginners to do hands-on learning and spend my time on more important things like maintaining another relationship within the community.

The other kind of relationship I have with patch fixers is that I’m constantly improving Python software engineering practices so that others have the opportunity to learn Python source code (which is why I moved the project to GitHub). So if I spend my time fixing bugs, I don’t have time for projects, collaboration and maintenance in Python. Thus, forgoing bug fixes and focusing on maintaining relationships with patch fixers gives users the opportunity not only to learn and practice, but also to improve and grow the Python project.

As for my relationship with the project’s maintainers, I don’t think anything will change. Except when things got out of hand during a technical discussion, our relationship worked well.

A month to ponder:

  1. It became clear to me that open source means collaborating on a project and sharing the maintenance work;

  2. If someone presents me with unreasonable demands, I am not obligated to respond to them because they are not my employer.

  3. To better spread out the maintenance work on the project, I needed to stop working on bug fixes and focus on patch reviews.

译 文 : Why I took October off from OSS volunteering

Open Source China