How NOT to behave in Open Source

Source: Dev.to

walks up to the counter, asks to see the manager, demands that the restaurant offer vegan‑friendly options, hands the manager a cookbook full of vegan‑friendly recipes, gets rejected, walks out of the restaurant, and leaves a 1‑star review.

To the average human being, appeasing the specific demands of an individual who has no regard for your time, work, or budget sounds ridiculous. On the other hand, the average human being does not take into consideration someone else’s time, work, or budget.

As an open‑source maintainer myself, I have come to appreciate the strenuous work of the giants whose shoulders I stand on. I want to surface how much these people are doing, and I want to help you appreciate and contribute in as frictionless a way as possible.

Who is this article for?

Whether you are getting started in open source, a “vibe coder,” or an opencl*w instance, hopefully this article will do you some good.

This article assumes you have a basic understanding of a version‑control system like git, and that you have some familiarity with a git‑hosting provider such as GitHub or GitLab.

How to Be a Headache for Maintainers

Let’s talk about some ways you can be an absolute pain to open‑source maintainers.

Side effects may include getting bad publicity on social media, getting banned from the project, or just getting butthurt after your issue or pull request is rejected.

How to Get Your Issue Rejected

1. Submit an extremely vague bug report

2. Request a port to a different language / framework / OS

3. Pitch a large‑scope feature request

4. Open a vague PR for the sole purpose of trolling

How to Get Your Pull Request Rejected

1. Vibe‑code a massive feature implementation

2. Open a PR that only adds your name to README.md

Being a Civilized Contributor

Now that you have a general idea of what not to do, let’s go over some ways that will help you work more seamlessly with open‑source maintainers and contributors.

General Etiquette (applies to both issues and pull requests)

• Express your gratitude – Open‑source software may be free to use, but time isn’t. If a project is important to you or has helped you, express your gratitude to the maintainers—that’s what keeps them going. If you can spare a few dollars, consider sponsoring the project.
• Search and read – Are there duplicate issues similar to yours? Are there work‑arounds? Has someone written a blog post that solves the exact problem you’re facing? Finding an existing solution or work‑around is more valuable than waiting for a response.
• Be verbose – Provide as much information as possible. Cross‑reference relevant issues and pull requests. Make it easier for the maintainer(s) to help you.

Issues

Issues count as contributions on your GitHub graph for a reason. Stop thinking of issues as customer support; start thinking of them as a way to positively contribute to the project.

1. Before you open an issue, consider the amount of engineering effort that is realistically available:

   • How many active maintainers are there?
   • When was the project owner last active?
   • How many open issues already exist?

2. Avoid introducing unnecessary overhead – Will your issue provide a solution if completed, or just introduce more problems and overhead? For example, requesting Windows support for a macOS‑only application will bring its own set of challenges.

3. Estimate the impact – Does your issue describe something that, if fixed, would benefit a sizable portion of the user base, or is it a niche edge‑case?

Pull Requests

1. Read the contribution guidelines – Most projects have a CONTRIBUTING.md that outlines the preferred workflow, coding style, and testing requirements.

2. Start small – A well‑crafted, focused PR is far more likely to be merged than a massive, “everything‑and‑the‑kitchen‑sink” change.

3. Write clear commit messages – Explain what changed and why it changed.

4. Add tests – If the project has a test suite, add or update tests to cover your changes.

5. Be responsive – If a maintainer asks for changes, address them promptly and politely.

TL;DR

• Don’t be a pain: avoid vague reports, massive unsolicited features, and self‑promo PRs.
• Be a good citizen: show gratitude, do your homework, be thorough, and respect the maintainers’ time.
• Contribute thoughtfully: small, well‑documented changes and well‑researched issues make the open‑source ecosystem healthier for everyone.

A Large Impact

Is the issue affecting the majority of the consumer base, or is it very specific to you?
Consider whether a workaround, forking the repository, or a dependency patch might be more effective than waiting a few months for the next version to be released.

Pull Requests (Best Practices)

When opening a pull request, try to adhere to the style guides and conventions specified in the project as closely as possible.

• Retain clean commit history – Spend ~30 minutes learning how to squash, describe, reorder, and rebase commits.

  • Split your changes into small, very verbose commits that cross‑reference related issues and pull requests.
  • Explain why changes are being made, not just what they do.

• Automated testing – If the project has a testing environment, write unit/integration tests to ensure correct behavior.

You as a Maintainer

Being a maintainer or project owner comes with a set of responsibilities. If you want to build reliable software for people to use, you should dedicate the time and effort to keeping it that way.

• Accepting contributions – Do not blindly accept external contributions without testing and thorough review.

• Be transparent – When accepting, rejecting, or commenting on contributions, explain why you reached your decision.

• Be organized – Manage issues, pull requests, and commits methodically.

  • Break changes into PRs and commits, describing them in detail.
  • Cross‑reference issues and pull requests.
  • Don’t close an issue as “completed” if it isn’t truly finished.

• “Being nice” is not your focus – It’s okay to be blunt as long as you are verbose.

  • Don’t give contributors the impression you’ll accept every contribution.
  • Rejecting a contribution might hurt feelings, but it won’t hurt your project. Saying “no” is fine.

• Delegate work when necessary – OSS rarely pays the bills, so you likely can’t work on the project full‑time.

  • If a past contributor or someone who opened an issue shows interest, ask them to submit a PR for you to review later.

• Archiving – If you can no longer work on an open‑source project for personal reasons, archive it to let people know development has ceased.

Conclusion

This article only scratches the surface of what it means to be an open‑source contributor and maintainer.

If you got something out of the article, I hope you’ll take the time to apply it and make the lives of open‑source contributors and maintainers easier.

We’re all in this together. Let’s share the load.