(If you would prefer to watch a 30 minute talk on this same content, you can watch my Python US 2018 keynote)
To start, I want to provide my bonafides so you know I’m not some crank spouting some armchair advice with nothing to back up their opinion other than having an internet connection.
For a day job I am the dev lead for the Python extension for Visual Studio Code. Originally the extension was an open source, personal project, but then Microsoft decided it would be a good idea to support the most popular extension for VS Code, so we hired its creator (Don Jayamanne), put me on the team, and then we re-launched the extension as an official open source project from Microsoft (and now we are a team of four developers and a product manager). So I participate in what I would call corporate open source for a living because even if we never received a single outside contribution ever again, the extension’s development will continue thanks to Microsoft.
One day a week for a day job plus plenty of spare time I’m also a core developer on the Python programming language. I have had commit privileges to Python since April 18, 2003, so over 15 years at the time of writing this. So I also participate in community open source where if people who weren’t paid to work on Python stopped contributing, the project would collapse (I’m considered extremely lucky to get a day/week of paid work time to spend on Python, so if it weren’t for volunteers there would be no Python programming language).
I’ve also been lucky enough to have contributed a patch in some form to around 90 projects (depending on how you count). Now a lot of those are documentation changes where I probably fixed a spelling or grammar mistake, but the key point is that I have been exposed to a lot of open source teams.
So, to summarize: I contribute to and manage a corporate open source project for a living, I have been actively contributing to a major open source project for over 15 years, and I have contributed to about 90 other projects. I would like to think I know a little bit about how open source works. 😉 Hopefully that means what I am about to say comes from an informed place and you don’t view me as a total crank.
But the instant you get that first contribution to your code, it becomes an open source project with an open source community of two (if you have users who are just providing feedback then it’s still a community of users, it just isn’t driven by open source yet). And once you get over that initial hurdle of your first external contribution, your project grows in purpose from being a way to share code with the world to being about two things:
- Collaborating on the maintenance of the project
- Having fun
Going forward, your open source project is about balancing those two things. If you’re not collaborating with others then you’re back to a code dump in which case you don’t have to care about collaborating. And if you’re not having fun then you will find yourself wanting to do something else, which means you will no longer want to participate. In both cases, though, bit rot can very easily set in. While participating in an open source project ebbs and flows can occur between these two goals, if you ever lack in one of them then the project will collapse.
Now that we know that the purpose of an open source project and community is to sustain the project and have fun, how do you accomplish that? First, you need people.
Initially your project is going to be very small, so getting more people to help out is great simply because every little bit helps. But as the project grows you also need to attract new people in order to replace people who have left the project. People have children, suffer from burn-out, change jobs, or die. There are various reasons people stop contributing to open source, but it happens and so if you don’t bring new people in then your project’s participants will eventually dwindle down to zero.
But you also can’t forget about those that already participate. Retaining folks must also be considered as people build up knowledge and unique skills for a project. If all of the preexisting participants left en masse then it would take awhile to bring new participants to the same level as those that left.
The trick is balancing both of these needs. For instance, existing participants probably like the way the current workflow works. But then new participants might want some newer approach that the project has not taken on yet. Do you keep things as-is to satisfy current participants or do you change things to try to attract new participants?
In case it wasn’t obvious, making sure open source works is hard. 😉
For me, the overall goal of open source is to attract and retain people to help maintain an open source project while enjoying the experience. I don’t think this is a radical or controversial perspective of what the purpose of OSS is. We all want open source to be sustainable and that requires people who enjoy doing open source. If we don’t have this then there simply won’t be people willing to work on open source because the enjoyment has been sucked out of the experience for them.
Unfortunately we are failing at meeting this laudable goal of making open source sustainable through keeping it enjoyable to do so. An example I like to give is a tweet written by Cory Benfield when he was the maintainer of hyper-h2, urllib3, and requests:
First, I hope everyone who reads that feels somewhat disturbed by the fact that trying to do a nice thing by working on open source has led someone to becoming a worse person. That is not a reasonable thing to ask of anyone and is definitely not sustainable as it doesn’t exactly make one happy to work on open source.
Look at it from the perspective of Cory’s partner. By letting him spend time on open source she has ended up with a worse partner in life. How is that a reasonable trade-off? As a community we drove Cory into a position where his partner could very reasonably say “it’s either open source or me”, and I suspect Cory’s partner would win (and rightfully so). It is simply not acceptable that Cory could even conceivably be put in that position due to him trying to do a nice thing by maintaining some open source project(s).
And this is not an isolated case. I had to take the entire month of October off in 2016 to prevent burn-out from open source. I actually now take a full month off annually from volunteering as an “open source detox” to fight off any potential burnout. I also take at least one day off every weekend from open source work to guarantee that I at least get one day a week that isn’t impacted by open source.
So how have we ended up in this position where we are failing at meeting this reasonable goal of making open source sustainable by keeping it fun to do? Why are volunteers or people paid by someone other than ourselves actually disliking working on open source to the point of it making them worse people? Why do I have to take one day off a week from open source to make sure it doesn’t ruin every day of my life? It all comes down to how people treat each other in open source.
Now I don’t think everyone who treats someone else poorly does it on purpose. I think a large part of the problem is most people have not stopped and thought about what open source is and how that should guide how they interact with others involved in it. Open source is more than just some free source code; there are real people involved here and that simple fact cannot be ignored. Unfortunately, I think a decent amount of people do forget this by not thinking about two key details.
EVERYTHING in open source has a cost
While open source, by definition, is monetarily free, that does not mean that the production of it is free. Even when someone volunteers their time, there is a cost of their time and effort.
Every time I spend work time on open source that’s my employer choosing to donate my time. But it’s also my choice to work for an employer that lets me put any effort into open source. If I’m not enjoying that work then that’s unpleasurable effort which makes me either want to change my job or quit (just like any other job you don’t enjoy doing).
And whenever I volunteer my time for open source, that is me choosing to divert my personal time from doing something else. Whether that’s spending time with family, friends or doing something else that I find fun and entertaining, by spending my personal time on open source I am giving up time that I could have spent on other things. I am literally choosing open source over everything else in my life when I choose to work on it in my spare time.
And I only have so much time to give. Not only am I not spending time with my wife and cat when I contribute to open source in my spare time, but I’m choosing to give up a part of the finite time I have to be alive on top of it. While I haven’t quite hit the midpoint of my expected lifespan, I will eventually die and so choosing to spend what personal time I have left being alive probably shouldn’t be squandered doing something that I do not enjoy.
And this is why whenever anyone says something is “just” a quick fix is not taking into consideration what they are truly asking someone to give up for their benefit. The cost of asking someone to do something for you is disproportionate to the cost of what you’re asking the other person to give up on your behalf. And this applies to everything, including email where the cost of you sending an email has a huge cost on the world’s time as you’re potentially asking hundreds of people to spend what little time they have to be alive to read what you have written. You have to always consider whether what you’re asking of others is reasonable.
To reiterate, just because open source software is free for you doesn’t mean someone else hasn’t paid some price on your behalf to get you that code.
Everything in open source should be a series of kindnesses
Since open source is paid for by others in effort and time, that would suggest that there really shouldn’t be any expectations on your part from what you get out of an open source project that you choose to use. You could view everything in OSS as a kindness that someone has done for you and others. Putting things into that perspective takes away the feeling of expectation and entitlement. This frames open source participation as someone doing something nice for the community and project, as someone having done a kindness for you.
As soon as you start demanding or expecting something from open source you have stopped viewing it as it was intended, and that distortion can be poisonous. When I choose to donate my precious time to open source I do it voluntarily as a nice thing that I enjoy doing. I didn’t do it because someone demanded it of me, and the instant I feel that my time is not appropriately appreciated as the gift that it is, I stop enjoying doing open source. And when someone stops enjoying their contributions to open source, they burn out and quit.
Taking the altruistic view of open source keeps things grounded and healthy. Viewing open source as a kindness someone else has done for you gives the appropriate perspective that this is something nice and no one has any expectations from it. It’s like when I hold the door open for someone. Ultimately I don’t expect anything in return (although a “thanks” is always appreciated). And the person passing through the door doesn’t expect anything else from me either. But when someone in open source makes demands it’s like the person passing through the door criticizing how I held the door open. It’s pointless and simply leads to people no longer being willing to hold open doors for others.
To reiterate, you should view open source as a series of kind acts people have done altruistically. That means you cannot make any demands or hold any expectations of an open source project. Or as Evan Czaplicki, the creator of Elm, put it, “Remember that people do free work because it is fun, not to get stressed by strangers”.
Knowing that open source always has a cost and should be viewed as a series of kindnesses, I want to go through some typical scenarios that occur in open source to point out how people accidentally stop viewing open source as kindnesses. I’m going to talk from the perspective of me as an OSS project maintainer, and that of Stuart, an external participant to a project (and who happens to be the person who gave me the idea of framing these examples in this fashion). I will signal who is doing a kindness for whom using arrows, e.g. “Stuart → Brett” signifies that Stuart did a favour for me.
Using open source
Brett → Stuart
It can be like someone leaving out a pamphlet you find offensive.
When I release open source, I’m doing a favour for you. I obviously didn’t have to release any source code that I produced for others to use for free, but I do it as a kindness for you so you can benefit from what I have already done (later on we will see how Stuart can give back by doing me a kindness by helping with the project).
For the longest time I didn’t think giving away source code could really go badly. But then when a large open source project had a scandal break out about a tasteless joke made in their docs I realized that open source projects can be hurtful, discriminatory, etc. from something as simple as their documentation. Luckily this does not seem to be common, but when a project explicitly tries to exclude or is hurtful towards others then it’s no longer being released as a kindness.
Stuart → Brett
It can be like someone telling you, “you’re stupid“.
Any piece of positive feedback is a wonderful kindness to receive. I’m always elated when someone tells me that they enjoy using Python, how it made things easier for them, etc. Positive feedback is always welcome (and unfortunately can be somewhat of a rarity).
There’s also constructive feedback. That is also an appreciated kindness as that leads to improvement. The key here, though, is that the feedback must be constructive, not negative. If you don’t have feedback that can help improve the project then your other option is to simply admit the project doesn’t meet your needs.
But negative feedback is never necessary. If you called a project stupid it helps no one. It doesn’t help me because I can’t act on being called stupid. And it isn’t a kindness because you could have simply said that my project wasn’t helpful to you for whatever reason (e.g. didn’t meet your needs, doesn’t have the stability you require, etc.). Receiving negative feedback simply makes me come to regret spending time away from my loved ones to work on open source. If you don’t understand why something is the way it is you can always ask why instead of making a declaration that something is stupid.
And people forget that someone put their time and effort into that project that is being called stupid (remember that open source always has a cost). For example, an article once reached the front page of Hacker News which started off by saying the author liked Python … but then they proceeded to point out all the “stupid” and “dumb” parts of the language (most of which, by the way, were because of backwards-compatibility). As I read the article I was able to point out which “stupid” features were mine and which were done by friends of mine. Essentially the author wrote an entire article calling me and my friends stupid. I don’t think the author meant to be insulting to me, but they were and so is everyone else who chooses to call something I put my time and effort into stupid or dumb or some other needlessly negative insult. (When confronted with the fact that he was being unnecessarily negative, the author claimed he didn’t expect the article to be widely shared; the internet is public, so always assume the entire world will read what you post, especially by the people who will take the greatest offense.)
And this extends to bug reports and feature requests. It’s a kindness when you report a bug so that I have a chance to try and fix it. But just because you reported a bug doesn’t mean I specifically owe you anything. I should try to thank you, but there is no contract here that says I have to address your bug or feature request. My kindness was to provide my time and effort for the open source project up until now, but there’s no expectation beyond that of my time and effort. Open source really should be viewed as self-service unless I choose to help further. If something doesn’t work for you then you are free to take the code and modify it to meet your needs; that’s a key tenant of open source. So the idea that any open source project owes anyone anything is a misunderstanding of what open source fundamentally is.
Submitting a contribution
Stuart → Brett
It can be like someone trying to give you a puppy you didn’t ask for or saying, “I’m cleaning up your mess”.
When you submit a change to something, I’m sure your intentions are good. You have put in the effort to try and improve the project somehow and that’s appreciated. But where this tends to go wrong is when people don’t take into account the fact that your considerations for a change are often very different from mine. Think of a contribution like a puppy: you might view it as this cute, wonderful thing you’re giving me while I’m looking at it as over a decade of feeding, walking, and vet bills.
Let’s say you submit a contribution and I accept it. What that means is that I am now expected to maintain that code for a decade or more (Guido released Python to the world in February 1991 which predates Linux’s release in August of that year). So while you might feel done with your contribution once it’s accepted, for me it’s the start of having to care and worry about it for potentially decades.
And then there’s the impact on the Python community. People who identify as a Python software developer number well into the millions. Toss in people who use Python but don’t identify themselves as software developers and we are probably talking about an 8-figure number. That means I have to consider the impact of your change on tens of millions of users and indirectly billions of people using Python software because it is guaranteed to break something when you are dealing with that sort of scale (the fact that Instagram’s 1 billion users are using a Django web site means your change could prevent you and everyone else from seeing cute cat photos someday). And then there’s the fact that your change may have just made literally tons of physical books in bookstores around the world obsolete; something else I have to consider.
Assuming your contribution makes sense, you also need to pay attention to how you communicate. It is not uncommon for someone to submit a change and point out how they are trying to “fix this broken/wrong thing”. I don’t think people necessarily intend to be mean, but realize that when you say something like that you are telling me I failed and you’re trying to clean up my mess. The put-down of saying I did a bad job does not motivate me to want to review your change, nor does it motivate me to want to contribute further if my work is just going to be viewed as bad.
A better way to phrase it is to say you’re trying to help the project out. As stated earlier, open source is about trying to come together to help maintain a project, so if you phrase things around that common goal then your contribution won’t come off as hostile.
Lastly, realize that contributing is not a right. I am under no obligation to accept your or anyone else’s contributions. We are all doing this open source thing to try and help each other out, but if I have to say “no” to you, that does not mean you are allowed to yell at me about blocking you from contributing. Remember, part of my work for the project that we are both trying to help out is to say “no” as necessary. I understand that getting to contribute to a project can be a very proud moment (I know I felt that when I got my first contribution into CPython), but please realize that yelling at me over it is not going to help get your contribution in and it will upset me and contribute to my burn-out (which means less people to look at your next contribution). Also realize that even as a core developer, I don’t get all of my changes accepted into Python; sometimes I make changes that people disagree with and they end up being reverted.
Brett → Stuart
It can be like someone saying, “you’re doing it wrong” or reacting with “why don’t you love me?!?”
When responding to a submitted contribution, maintainers should try to say “thank you”. It’s a simple acknowledgment of the time and effort someone put in to try and help out the project everyone involved in is attempting to keep going. It can be hard to have enough time to say it for every contribution, but it is a good goal to strive for.
Feedback for a contribution should also be constructive. Telling someone they are doing it wrong helps no one; it’s just as bad as when someone says your project is stupid. The goal of working with someone on a contribution should be:
- To help them get their contribution to a place where you’re comfortable in accepting it.
- Help them learn how to contribute again in the future more effectively.
- Pass on some knowledge to the contributor.
In other words the goal is to get the contribution in, make it easier for the contributor to contribute again in the future, and to teach someone something new.
Brett ⇄ Guido
It can be like arguing about politics with friends.
While everything I have discussed so far is how maintainers of a project and everyone else can clash, issues also arise among maintainers themselves. I have actually come close to tears due to an argument I had over email with a fellow Python core developer. If anything it’s actually harder to deal with hostility and negativity from fellow maintainers because not only are they typically very passionate about the project, but you are also most likely going to be working with them for quite a while so it can lead to stress whenever you end up interacting with them in a negative way.
Much like anyone else on the internet, maintainers should try to be self-aware enough to know when something has upset them so they can step away from the keyboard and gather their composure first. Open source is typically not a time-driven thing, so there’s almost never a need to respond immediately to that email, tweet, etc. Waiting an hour or twenty-four before responding is never a bad thing and in general leads to a more level-headed response.
I am well-aware that this blog post paints things as much worse for maintainers than external contributors and project participants, and that’s because it is. Scale factors easily lead to this being a much bigger issue for maintainers than for those only casually contributing to or using a project.
Take Python for example. There are currently 91 people who have commit rights to the CPython repository. The last time I calculated the number of people who call themselves a “Python developer” I got 7 million. To have an easy number to work with that also includes every user of Python who doesn’t call themselves a programmer (e.g. scientists probably typically don’t label themselves a developer first and a scientist second), let’s round up to 10 million. Now let’s say that 1% of Python users are mean (which I suspect is way too low to be accurate; would you say that only 1 out of every 100 people at your workplace is mean?). That’s 100,000 people I potentially have to contend with who are quite willing to be mean to me.
And we don’t say this often enough, but maintainers get psychologically abused by people. Insulting me and a project that I have put 15 years of my life into is not exactly being done to help my mental health 😉. And it’s very easy to end up in a situation where people abuse me because most interactions I have with people are either about a question they had, a problem they ran into, or a change they want to see happen; these are not interactions to talk about the weather outside or to thank me, but about something people want to see changed.
And the abuse does pile up. Some work has shown that if you don’t have a 5:1 ratio of positive to negative interactions with your spouse when arguing you’re heading towards divorce due to the mental toll arguments end up having on you. And from personal experience I would say that ratio is probably a little low when trying to counter-act a negative interaction with someone online (personally it feels more like 10:1). I actually on occasion go online to e.g. Twitter and say I just had a bad interaction knowing that it will lead to some nice comments in order to help cope with the negativity I’m struggling with.
Basically it’s really unfortunate that negativity is driven by reactions while positivity is driven by reflection. I sometimes wish there was #ThankfulThursday or something, similar to #FlashbackFriday so there was something people could react to for thanking people for what they do instead of hoping someone stops and thinks about thanking others.
I think if everyone would just act nice towards one another with the proper perspective of what open source is and how it functions then most of the frustrations people have and the burn-out that occurs would drop significantly. As I said earlier, I have found that phrasing everything in open source as being a kindness really helps put things in the proper perspective. To make sure what I mean by a “kindness” is understood and why I think this is a healthy perspective to take, I wanted to clarify these points.
A kindness should not come with an expectation of something in return
I used to say everyone should view open source as a series of favours. But as time went on I realized that favours easily end up with a connotation of expecting something in return. For instance, how often have you heard someone say, “If I do this favour for you, will you do this other thing for me in return?” This makes favours a pay-it-forward situation where you are doing something with the expectation of it being repaid later.
I switched to using kindnesses because being kind in the cultures I’m familiar with has no expectation of something in return. This does away with unhealthy expectations that people doing something for them has an expectation of something in return. It sets everyone’s expectations for the kindness appropriately; that the person doing the kindness expects to be treated nicely (like any other interaction in the world), but otherwise there is no expectation of getting something in return for that kindness.
For instance, if I view sending a project a pull request as a kindness then I have no expectation of what will eventually happen to that pull request (e.g. accepted, rejected, languishing, etc.). It’s reasonable to expect I will be treated nicely, but beyond that I have to go into the situation with the expectation that nothing will ever happen to my pull request and the only thing I got out of it was the experience of writing the code.
And the same goes the other way. If someone sends me a pull request and I ask for changes, my review was a kindness to the pull request creator to give them feedback to help them get their PR accepted and maybe teach them something. If they never come back and update their PR, then that’s fine as I didn’t do the review with an expectation that it would necessarily go anywhere.
Everyone should act like everything is being done as a kindness for them
When you expand what acts should be treated as kindnesses to all acts, it has an interesting effect that no one has a reason to get angry or upset anymore when something doesn’t happen. While you still have a right to expect to be treated nicely (as you should be as a reaction to any kindness done for you), once you let go of any presumption on your part about what will happen, things become a lot less stressful for everyone involved. And when the stress in a situation drops, it tends to actually lead to more motivation to help because the whole situation becomes much more pleasant for all involved.
Now when I point out that I think open source should be viewed this way, inevitably someone asks about how I would expect anyone to be motivated to work on open source. The thing is that if you’re involved with open source long enough you end up noticing that people are quite happy to help because they want to help. Remember, open source is done by people giving something away for free because they choose to; you could say you’re dealing with a bunch of digital hippies. 😄 In other words you don’t need to worry about open source collapsing if everyone operated as if everything was just a kindness because plenty of people already operate like that. It’s actually those who don’t come in with that expectation who end up “poisoning the well” as it were and inevitably driving away those that would have happily volunteered their time and effort, leading to just those with the improper motivations left to keep a project running (which will inevitably fail due to no one being motivated to help out).
In case I haven’t made it clear enough, I think we should all act towards each other with kindness. If we were all open, considerate, and respectful towards one another (as the PSF Community Code of Conduct suggests), then I think open source would go much more smoothly:
- Open to people doing a kindness
- Considerate about the kindnesses being done
- Respectful of what eventually is done with your kindness
It’s sort of a three-way handshake of kindness (much like TCP’s three-way handshake). When you do a kindness you start the conversation, the recipient of your kindness should be open and considerate to that kindness in response, and then you should be respectful of what the recipient ultimately decides to do with your kindness as the acknowledgment.
Being rude/mean is also never needed. If you look at the purpose of yelling, being rude, or being mean you will notice that their purpose is to try and intimidate the person you are arguing with into being too uncomfortable or frustrated to continue. It has nothing to do with the points being made in the discussion but instead to try and be exclusionary without directly addressing the contents of the discussion. In other words being rude is using bullying tactics as a way of being intolerant of ideas you happen to not like and can’t address directly and fairly.
If I ran the HR department of the internet
It’s one thing to accept that people should treat all of this as acts of kindness and be nice accordingly, but how do you help make sure you act nicely when communicating?
Assume you’re asking me a favour
While this blog post has emphasized considering everything as a kindness, to help you phrase things for effective communication, assume you’re asking me for a favour. For instance, if you have a bug you want fixed then assume when you file that bug that you are asking me to do you a favour and fix it. Since I’m under no obligation to fix the bug, treating the request as you asking a favour of me helps make sure you don’t phrase the bug report as a demand for a fix.
Also assume you’re asking your favour of me in-person. It’s very easy to forget tone when writing text online, so pretending you’re talking to the person at e.g. PyCon might help put you in the right frame of mind.
Assume your boss will read what you say
Make sure that whatever you write your boss and employer will be happy with it. When you do things for work in open source you are representing your company so it does matter how you communicate. I for one do pay attention to what companies people work for and how they treat others in open source (and from conversations with other project maintainers I am definitely not alone in doing this). I also have a pretty good memory so assume I won’t forget which companies have an employee that has treated me poorly.
Assume your family will read what you say
Finally, assume your entire family will read what you say. Would your partner or parents approve of how you communicated? If you have kids, would you like them to pick up on how you communicate? Would your children approve of how you’re communicating? If the answer is “no” then consider rephrasing how you are asking for something.
My thinking is that somehow you will care either how your boss, family, or I think of you and so you will stop and pay attention to how you are communicating.
In case the message in this post wasn’t obvious, being nice to one another and realizing that open source is fundamentally self-service would lead to open source being more sustainable and pleasant to participate in. We shouldn’t be putting the significant others of open source participants in a position where they have to have a chat about how open source is making their partner a worse person.
When I have talked about this publicly I commonly get two questions. First is what about blunt cultures? Should they be penalized by not inherently teaching members of that culture to be as kind/soft in delivery as others? To that I first say we should all give people the benefit of the doubt. So if someone comes online and discovers that they are more blunt than others expect, they should learn that fact in a kind manner and not a rude one (remember, responding to rudeness with more rudeness never solves the problem, it just aggravates it). The other thing I say is realize there’s a difference between being blunt and being rude, e.g. saying “I don’t think that’s correct” is very different than saying “that’s not correct”; one is a blunt opinion while another is someone claiming something is a fact when it isn’t. While I would argue it’d make discourse among strangers easier by rephrasing things as questions for clarification, I wouldn’t say bluntness is the same as rudeness.
The other question I get is about someone having to be the “tone police” and how do you prevent abuse? First, to get the point across as to why we need someone setting standards, I ask if the person would like it IF I ALWAYS TALKED LIKE THIS TO THEM, YOU BLOODY JERK! Doesn’t exactly feel good, does it? 😉 So there is obviously some level of acceptability that we expect people to adhere to already.
As for the abuse worry, I think it’s a red herring. Rudeness is never necessary to make your point so why do you care so much if you’re told you can’t be rude? For instance, do you really have to yell to make your point? Usually yelling is simply a way to try to bully the person you’re arguing with, so it’s simply an exclusionary tactic by trying to scare off the other person by talking louder than them or making them too uncomfortable to continue. With inclusion as a goal, allowing a communication style that provides no benefit but to exclude others simply does not need to be allowed. And if you object to rules from some principle you hold, then I’m sorry but then open source is probably not for you.
Participation in open source is a privilege, not a right. Some people forget this and make platitudes about free speech and such. The problem is people forget that in open source you can simply fork a project and go create your own community with your own participation requirements; you are never beholden to a project such that you can’t ever leave. In other words this is not the equivalent of the government you live under restricting your ability to communicate since you can’t “fork” your country and start a new one without a rebellion. You choose to be in a community, which means you choose to participate under their rules and expectations.
I am hopeful that we can solve this problem of burn-out and making open source unwelcoming/uncomfortable for people as the solution isn’t unknown. But I am worried that due to the social difficulties of getting people to change their general attitudes that fixing this problem is not easy. I’m even more worried for other open source communities, though, because if our great community is struggling with this I can only imagine how bad it is in other places. 😞
But we must start somewhere. So the next time you see someone being rude, kindly let them know that is how it’s being perceived so they have a chance to change their behaviour. And when you interact with an open source project, realize that everyone is just trying to do kindnesses for others so don’t go in with any set expectations or demands of others. If we could help others learn how to communicate better and not have unreasonable expectations then this grand social experiment we call open source will have a chance to continue to succeed.