Skip to content
markdown guide

I had been in both camps:

In user camp

  • When you get annoyed that some bug is not fixed for years (there are famous tickets, like 7 years old)
  • When you with the best intention open a ticket to improve something and it is got rejected
  • When you solve the problem yourself and provide PR, but it's not got merged for months
    • Then you close some of your PRs, so the author could focus on most important one for you and author get mad because you closed PR too soon
  • When you decide to fork some open-source to introduce your fix and end up maintaining it yourself

In maintainer camp

  • When people open tickets without reproducible details, even when your template asks for it
  • When people ask you to solve their problem for them (which is out of the scope of your project)
  • When I don't have time or moral powers to answer tickets or review PRs


I have no idea, but some thoughts:

  • sometimes maintaining is way too much work for one person to do on their free time
  • code of conduct
  • understanding that open-source is not when somebody is doing something for you for free. Open-source is life philosophy - you can use somebody's work and ask for help, but you need to give away something in return. Nobody owes you a thing, the author may decide to help you, but as well can refuse without any explanations.

Open-source is life philosophy - you can use somebody's work and ask for help, but you need to give away something in return. Nobody owes you a thing, the author may decide to help you, but as well can refuse without any explanations.



One thing I've noticed is when contributors propose a PR before discussing their approach first and you're stuck in an awkward situation where the PR would have to be modified heavily in order to be merged or you close it and turn down a new contributor. Very awkward.


The number one rule of Open Source: Always assume everything is said with the best intentions.


I think fostering engagement in open source projects is a tricky task. In my opinion, two steps are key (among others):

Being open minded about contributors ideas. If the project is truly open source, then everyone's input must have value.

Letting people know that their contributions are valuable and impactful regardless of how simple they are.


Being open minded about contributors ideas. If the project is truly open source, then everyone's input must have value.

I have a different definition of open-source in my head. Open-source doesn't mean that the project should be open for all technical ideas (of course it should be open for all people to contribute and use). The idea of open-source is (my PoV):

  • that if you have some ideas with which core team doesn't agree you can always fork and implement your solution (diversity of solutions and ideas)
  • that you can learn from the source
  • that you can use it independently of the commercial or political situation and not affected by copyright issues

Letting people know that their contributions are valuable and impactful regardless of how simple they are.



When I say being open minded, I don't mean necessarily that every idea needs to be adopted because it is an open source project. I just mean accepting different views and inputs on what could be implemented.


Picking at minor things in PRs can be a big turn-off. I feel that folks should just edit the PR to make minor changes. That feels is far more collaborative and constructive than putting in comments about typos or suggestions to rename things.


That reminds me that one of the first contributions of a feature I did the BDFL thanked me then rewrote the feature their way and pushed it out as a release. I felt that I had been listened to and I could immediately upgrade to get the feature. That was a better outcome all around than being ignored or asked to rewrite if another way.


In an ideal world, that is a great way to go about it. But most maintainers may not find the time to do all that. A short review in text is much faster, if more frustrating for the person opening the PR.


I feel it's better to make a computer do code linting, than to do this in a PR review. Nobody minds when a computer picks nits, but when people do, it's taken personally πŸ˜‰

The review should focus on the logic, that the PR makes sense, and then run it though a linter for code style.

Bonus points to the reviewer for lint instructions or offer an editor.conf for the project.


But, surely it is better for you to learn the style so that your next PR doesn't need to be rewritten.

In general we are trying to build a community not just add your feature.


Probably the number one thing is keeping the communication about the ideas. (Reminder to self as well.) Avoid describing or characterizing or comparing or attributing motivations to other people. It is a lot more boring and informational, which is exactly what you want when talking about problems or disagreements. And if others make personal characterizations of you, rather than going on the defensive, ignore them and refocus back on the ideas. Examples comparing characterization vs idea.

Characterization: You are doing it wrong. You should be doing X.
Idea: Here is how I am avoiding that problem: X.

Characterization: Did you read the definition of AbstractDecoraptorProxyFactoryPattern? It obviously says X.
Idea: I think I see the problem. Try X.

The word obvious is a red flag. It is often a subtle personal attack.

Characterization: How has this bug not been fixed?
Idea: This bug is still causing a problem for me. X.

Characterization: Are you just wanting to argue?
Idea: I am still having trouble understanding your perspective. Can you give me some concrete examples?


An epic but simple thing: don't act like Lennart Poettering.


Controversial subject. Yes he's position is not what other expects, but death threats which he received is not a solution either. Since those times Linus step back from his role and Linux adapted CoC...


I disagree with the man's micro$ofty, god-module approach to systems, bereft of even a token effort at decentralization, decomposition, or enabling autonomy. And I think it likely informs or resembles his understanding of human nature.

But death threats? That's a serious and unnecessary escalation.


These are the things that usually cause contention.

Response or lack of.

Nothing more annoying than asking a question about a feature or bug and getting no answer. Especially if it's a bug that can leak sensitive data.

Dictator mode aka abuse of power.

This is more common where financial gains of some sort are expected, for example in crypto. You get to see devs that want to be the absolute authority in every and all decisions, usually to the detriment of the others.

I feel there's no margin that defines what is right for now. It's just a matter of trial and error but a lot of people get it right.

PS: source may be biased. source is me.

Are you listening?

I can live with any technical change as long as the core contributor says the real reason why they want something X way and ensures that I have the means to navigate whatever way that is.


I'm not an open-source maintainer or a regular contributor (would like to be, just have not gotten into it) so as an outsider, it looks like a mess of a problem to solve. You want to be open-minded and allow everyone to contribute to having the best possible product, but there seems to be so much crap to deal with. If you go to any somewhat popular repo and look at the pending issues and pending pull requests you can see this.

Open-source maintainers are putting their project out there to benefit others. Contributors want to help get involved or fix a problem they are having. It can be disheartening if the maintainer does not acknowledge any of it.

Users with good intentions could post an issue requesting something that falls outside of the vision that the maintainer had for the project. The maintainer may not want it in their project and it could spark some negative attitude in saying that.

Pull requests can just show up for features. If it wasn't discussed or asked for and the maintainer does not want it, what happens to it?

There are also the "contributors" that post issues and follow up comments that sound like they are demanding work be done without actually contributing to it. It could be in a negative or positive tone. In both cases, some person is adding stuff to your to-do list for your personal time. The negative versions are especially bad like those comments that say something along the lines of "wow it has been X months and we still don't have this." I can see how a maintainer might feel having to see that fairly regularly.

GitHub issues look like the primary form of communication but it looks like a mess to me. Anyone can create an issue with any content. It could have good content in it or it could not. It could spark a long discussion with no resolution. It could be a personal insult. There does not seem to be great built-in features on GitHub to place restrictions on these or to help gain some control over it.

If I were a maintainer, I feel like I would have some fairly strict ground rules (and make them very clear on the repo) to maintain my sanity. That likely would not go over well with a community, AKA I'd be an open-source "dictator". I would likely put restrictions on who gets to create issues (past contributors only, those who have helped others with their replies, or something along those lines), the content of those issues (needs a minimum set of information/template filled out), all PRs would be tied to an issue with an approved label, feature requests would be assigned to the user that requested it with a due date, etc. Everything else would be closed.


That's works both ways.

As maintainer always try to respond in a timely matter. Timely could be weeks (but rather not), it should be no big deal. But do respond! Even if you don't want it, thank the contributor for their effort.

As a contributor, don't expect your input be accepted in a timely matter, or at all. You are not entitled.


Just to explicitly clarify on the George Carlin skit.

Thou shalt always be honest and faithful, especially to the provider of thy nookie.

As a maintainer, your users are thy nookie. As a user, your maintainers are thy nookie.

Thou shalt try real hard not to kill anyone.

Should be rather obvious, don't kill your users, don't kill your maintainers.

Forking a project is a way to kill. Try first to extend it.

Thou shalt keep thy religion to thy self.

This is mostly for the users. (e.g. if the maintainer uses spaces, you use spaces.)

But also for a maintainer. If a user wants to add support for FreeDOS or Haiku, invite them to maintain it.


For committers:

  • don't shame a person for being a newbie / not knowing the language / not reading the FAQ
  • don't insist on every formality if you can do it yourself with a keystroke (e.g. code style)
  • discuss the code, not the person
  • don't assume a gender. Some names sound female but they're not.
  • even if you don't accept the change, say it nicely.

For users:

  • don't ask a question and then go on vacation
  • name the version
  • don't expect anything. Be happy when you get something.

For all:

  • be nice
  • try to give feedback within 24 hours

Don't assume a gender ... my husband has had that issue, though not as part of Open Source. In his case, Veteran's Affairs sent me a letter saying they do not acknowledge same-sex marriages, which is wrong, yes, but had nothing to do with our paperwork. His parents thought they gave him a good, wholesome, godly name, even if it does sound like a female stripper's perfect stage name. Then there's the people who ask me why I have a ponytail as a guy, which is weird, as I don't think I look like a guy, but maybe it's the absence of a pink, frou-frou dress with matching parasol throwing them off.

So, yes, absolutely that.

That said, if anyone feels like contributing to anything of mine, I'm willing to listen, but slow to respond (don't take it personally, I'm a 24/7 caregiver for a very high maintenance old woman, work full-time with a completely random schedule, and spare-time for coding or even basic communication is a rare treat. I'm also tab-vs-space agnostic, and I prefer to not have dependencies if it can be helped, as I like things that keep working even if someone else's project breaks. I also love giving people credit for what they do. As far as I'm concerned, working, robust contributions = a good chance of sainthood.


Respectful language.

I do not have a lot of open source experience, but i have a lot from working with teams across the planet.

Both theirs and mine have boiled because of short or socially unaware comments. :)

Probably the most annoying part is that the only reason i personally started to behave better is because someone offhanded showed me an article about PR language about 2 years ago.

It made me realize that wording things differently not only meant less discussion, it also helped me see my own style biases, which made me a better developer.

We need more awareness on this, but not in a Linus stops working kinda way.
It needs to be constructive.


When I was a jQuery maintainer in 2011, our big rule was: the first 3 words you wrote when responding to issues and questions were "thanks for contributing" and the 4th word couldn't be "but". Helped frame conversations positively right out of the gate.


Laying out clear priorities.

Also, getting funding. Helps a lot when you can start hiring your community.

Classic DEV Post from Jan 22 '18

5 Top Sites for JavaScript Interview Preparation

When you finally find the perfect role you want to make sure that you maximise your chances of getting an offer. Here are some resources for checking your JavaScript, Node.js, React and Redux knowledge.

Ben Halpern profile image
A Canadian software developer who thinks he’s funny. He/Him.