On October 1, 2016, I stopped volunteering for open source projects -- including Python -- for a month. While I still did open source work for Python as part of my job, I spent absolutely zero time helping any project outside of work (so no evenings, no weekends). This was the first major break I have taken from Python development since I started participating on python-dev in June 2002, over 14 years ago (even on vacation, there is always email).

Why did I take a month off?

What led to this month-long break after 14 years of continual volunteering? It was basically a culmination of several things in July and August (and the usual small things), all capped off with a report that helped put into perspective how mistreated I have felt. To start, someone wanted a bug fixed which I had commented on. When the bug didn't get fixed, they personally emailed me asking me to fix it as a consultant within three days. When I said I didn't have the time, they then asked me to do it anyway for free because they still had their own three-day deadline and shouldn't I just want to help them out?

Then there was a bug which had a patch in a comment that I had assigned myself. I unfortunately got side-tracked with some things that had to land before the Python 3.6 feature freeze, so I missed fixing the bug for Python 3.5.2. People then started to state that it should have been a release blocker (although none of these people were core developers). Someone then commented about how they couldn't understand how I couldn't have made this "two-click" fix, even though applying a fix to Python is not as simple as two clicks (and especially not when it spans multiple versions like this fix did). When I explained the complexity of applying a fix in Python, I was then told that it seemed like a "reasonable excuse" instead of acknowledging they didn't realize how hard it is to keep Python functioning. Two months later I had different people that I respect on Twitter complain about the exact same bug. All of this for an issue in an venv activation script for a non-mainstream shell (in other words, it was not vital to the execution of Python so no systems were going to fail due to the patch slipping).

And then there was the question on the issue tracker about why something worked the way it did with an offer to "fix" the semantics. On a Saturday morning I replied back explaining why the semantics were the way they were to prevent the person from needlessly spending their weekend developing a patch that wouldn't necessarily be accepted. Unfortunately my attempt to save someone from needless work led to a passive-aggressive response about how I was preventing them from contributing. When asked if their message was meant to be passive-aggressive -- giving someone the benefit of the doubt is always good and they may have just had a bad day -- they fully admitted it was meant to be passive-aggressive and continued to act aggrevated towards me. All of this over me trying to save someone wasting hours of their weekend (the person did later apologize to me).

And on python-ideas there were a few threads which went over the top. Now normally one wouldn't take what happens on a mailing list personally, but as one of the creators and administrators of python-ideas, I take the tone of that mailing list seriously and when I see people not acting nicely towards one another it's rather frustrating as I feel partially responsible for the aggregate tone of python-ideas.

Finally, Nadia Eghbal's Road and Bridges report on OSS maintenance for the Ford Foundation helped me recognize the abuse I have tolerated for well over a decade (everyone who uses open source should read that report; the page count might seem high, but the font is big and the margins are wide 😉). That report really made it clear how people have made demands on my free time simply because I previously gave them that same gift to help make Python, as if the gift of my free time is in perpetuity. It also helped clarify how that claim is often hypocritical as most of people wanting me to do something for them in my spare time actually work with Python professionally and so have a business justification to help improve things while that wasn't true for me (only since joining Microsoft have I had any form of direct business case to working on Python as part of my day-to-day work, so that's for only just over a year out of 14).

An analogy of open source development

For some people, when they realize how me and all other project maintainers out there are treated, they are horrified (and I'm not exaggerating when I say all project maintainers; I have yet to meet a maintainer who doesn't suffer this kind of abuse). Others, though, don't quite get it, so I've tried to come up with an analogy to help explain it.

Imagine you're a 10-year-old kid and you've just come up with a new game (it can be a board game, something you play on the playground at recess, etc.). You tell your friends about the game and its rules and they also find it fun. You and your friends start playing it regularly and some other kids notice. These other kids come over and ask what you're playing, and so you explain it's a game you came up with and tell them the rules. Those new kids go run off and play the game and find it fun. Those kids tell their friends, and suddenly you find yourself explaining the rules constantly. To make your life easier and to help other kids playing the game, you take the time to type up the rules to the game and make paper rulebooks using your allowance. So now, instead of explaining the rules verbally, you're handing out a rulebook you paid for out of your own pocket.

Then the first suggestion comes in for changing the rules since you started printing them. They ask if you have ever considered adding some rule, and you say it makes sense. So you update the rules, make new copies of the rulebook, and then hand out the updated rules to anyone who wants them. This happens a couple of times, and honestly you don't mind because people have been nice about it and it makes the game better, even if it does lead to more work for you to integrate the rules and print out new copies since it improves the game for everyone (you included).

And then some kid who you don't know walks up to you and says "you need to add a rule about getting to hit people". Now you don't exactly appreciate someone phrasing it like you have to do something, but the other issue is you disagree with adding something that includes violence. You politely say you don't think it is a good rule to add to the game. The kid proposing the rules says, "screw you!" and storms off. And yet this same kid grabs a copy of the latest rulebook as he walks away. Not exactly something you would have liked as a kid, nor would you want to see your own child treated this way.

How I'm treated on a regular basis

Now imagine the game is Python and that jerk who demanded you change something is actually an adult software developer and there's way more than just one of them. And that tone of "needing" me to change something is constant. People saying things like "this needs to change", or "you should change this", or "I think you should change this" really gets exhausting because you know they are not coming from a place of openness if they have already stated upfront that they think you're wrong (and when they don't get their way, they often don't just say "okay" as they leave). People who ask if you "have considered this?" or "why is it this way?" have a much better chance of being listend to.

But it's not just about people constantly thinking I'm wrong and letting me know that. The entitlement that people bring with them when talking to me is also exhausting. Simply because people use Python some folks seem to think I owe them something. People forget that they were given Python for free and at worst they had to download it and run an installer (if you're on Linux there's a decent chance you just had to type the six letters in "python" to launch the interpreter since Python was already installed). There was absolutely no money exchanged, I didn't get directly paid at all for any of the time I put into helping Python at all, and yet people who chose to use Python seem to act like they paid me to use Python and so I need to react to their needs as such. The best guess I can come up with as to why people act this way is they feel that by using Python and helping to make it popular I owe them my career or something. Basically I gave people the gift of my time and energy to produce some code they received for free, and yet some seem to think that gift has an addendum that attaches my time and energy in the future.

Adding some perspective

Now obviously the general Python community does not act this way at all. When I'm at any Python-related conference -- e.g. PyCon, PyData, meetups -- I never feel like people are there internally fuming at me for some design decision I made or hating on Python in general. I of course do run into the occasional bad actor at PyCon when they realize who I am, but then I can just look at the rest of the space I'm standing in and realize everyone else I can see is quite happy with the work I have put into Python.

But while it's nice to get proper perspective roughly 2 weeks out of the year, I don't get that perspective automatically the other 50 weeks. While people at PyCon do say "thank you" for the work I put in (which is always very touching and appreciated), the rest of the time I only get a "thanks" when I complain about how someone mistreated me. Otherwise the only people I hear from outside of core developers and regular participants online are people wanting something from me, and unfortunately the ratio of people asking nicely to those that don't isn't great (they say it takes 10 acts of kindness to cancel out one bad act, and I don't think that the ratio of good-to-bad is as good as 10-to-1).

Defining expectations for open source

So what the heck am I going to do? I don't want to burn out and completely stop contributing to Python. I have enough friends in the community now and have fun when left alone that I don't want to walk away entirely, but something does have to change. But to know what to change, I need to know how I think things should be to identify where things are out of alignment.

To start, I view open source software development as doing development in the open to help share the maintenance and responsibility of that software with others. That means I don't view open source like some do with free software as some philosophical imperative but as a way to foster collaboration with others who also have a use for the same software to make maintaining that software easier. All of this means open source and its success comes down to the relationship between project maintainers -- who have gotten to that position by showing the most dedication to maintaining the project -- and everyone else (I'm obviously ignoring whether the project is actually useful).

Let's look at this relationship in regards to the different types of people involved. The largest group is those that don't even use the project. This group includes people who are just curious about the project, considering using the project, or those who have already decided the project doesn't work for them. When interacting with project maintainers, people in this group typically ask questions to help them decide if the project is right for them, e.g. "does this project help with this use-case?" Where it goes wrong is when people start to say things like "this project doesn't solve my use-case so it's trash" without stopping to realize that not every bit of software is meant for everyone (and that inclues programming languages). This also means project maintainers should never say things like "your use-case is ridiculous".

The next group of people is actual users. This group typically comes to project maintainers with questions about how best to accomplish some problem. People who fall into this group are also the people who promote a project the most. Where people in this group tend to falter when interacting with project maintainers is making demands. As I said earlier, I view open source as a collaboration among people to help maintain a project. What this means is that users are free to ask project maintainers to do something on their behalf, but they are in no position to make demands of the project maintainers if they aren't helping with the maintenance. In other words it's fine to ask "have you or would you consider adding this?", but it's not okay to say "you need to add this" as project maintainers by the sheer fact that they are volunteers and you are not paying them means they really don't have to do anything.

After users are bug reporters. This is a group of people who are not only users, but actually took the time to report an issue they found with the project. For this relationship, bug reporters should expect project maintainers to provide a place to report issues and to triage them as they arrive, while project maintainers should expect bug reporters to not demand that their bug be fixed. For project maintainers triaging bugs is never fun, but when someone puts in the effort to report an issue you should at least make sure it's managed properly so no one else accidentally reports the same issue. For bug reporters, I think there are two key things to remember: there are a lot more bugs being reported than just yours every day, and just because you think your bug is a priority, that doesn't mean it is for those doing the work to fix your bug (which I know is not exactly a comforting response when the bug is affecting you, but unfortunately fixing bugs is not simple or easy).

The next group are patch contributors. This is probably the hardest relationship to manage as patch contributors are doing hard work, but that work can only come to fruition if project maintainers let it. Because patch contributors have to do a lot of work to make a patch happen, they deserve to have their patch reviewed. For project maintainers, they deserve some patience from the patch contributor as it's not easy to review all the patches that come in, nor can all patches be accepted as not all changes make sense to accept. I will be the first to admit that this relationship is the one the Python project needs to improve (and thus why I'm working to move the project to GitHub so we can make patch reviewing as easy as possible for all involved).

There is also the relationship among project maintainers. As the direct representatives of a project, we all rely on each other to act accordingly. We also try not to prevent others from doing what they can to help maintain the project. Probably the trickiest bit is trying to reach consensus on design choices (although in the case of Python we can always ask Guido to just make a final decision, sometimes to his reluctance).

Going forward

After spending a month away from volunteering, what will I change so that the next time I step away from open source it's because I'm on vacation rather than to prevent burnout? In the end I think I will focus on things that directly help with increasing the collaboration between me and the community.

Between me and users I don't specifically see anything directly changing. I will probably continue to not read volunteer-related emails on evenings and weekends to avoid getting upset from how someone treats me (I will do code work on evenings and weekends as time and the mood strikes me, though).

Between me and bug reporters, that relationship will change a lot as there won't really be much of one going forward. While I completely appreciate people taking the time to report bugs, I think it will be most productive for me to essentially stop fixing bugs. This is actually surprisingly difficult to do as fixing simple bugs allows me to do work that isn't challenging and yet feels rewarding. Be that as it may, by me no longer fixing bugs, it frees me up to focus on another relationship within the community.

What I want to do is focus on my relationship with patch contributors. Learning as much as I have from contributing to Python's source code has been a continual driver for me to improve Python's software engineering practices so others can also have the chance to learn like I have (hence why I'm leading our move to GitHub). I also realize that if I keep fixing bugs then there's nothing that requires patching which leads to a dearth of starter projects for people who want to get involved. It also isn't the most effective use of my time if I truly want to help spread the collaboration and maintenance load of Python. So by practically fixing no bugs I give other people a chance to learn from fixing them, freeing me up to spend the time to guide people through the process of fixing those bugs, with the hope that some patch contributors will become project maintainers themselves and help maintain Python.

As for my relationship with project maintainers, I don't really see that changing much. I might step in a bit more to try and calm down flare-ups on the mailing lists when technical discussions get out of control, but otherwise I'm happy with the relationship I have with other project maintainers.

And that's it. During my month off: