What contributing to Open-source is, and what it isn't

What meaningful OSS contribution looks like

• Many argue contributions work best when you already use the software and have a concrete itch: bug to fix, feature you need, packaging you rely on.
• “Random” PRs to projects you don’t use are seen as low‑value; context and vested interest matter.
• Good contributions consider long‑term maintenance: changes merged become the maintainer’s ongoing burden.

Motivation and “drive‑by” / resume‑driven PRs

• Several maintainers complain about PRs done mainly for CVs, events, or swag: superficial fixes, refactors no one asked for, untested platform support, or style-only changes.
• Others distinguish between:
  • “Itch‑scratching” one‑off fixes by real users (viewed positively, even if one‑time), and
  • “Vanity” PRs from non‑users who expect mentoring and merge.
• Some think intentions shouldn’t matter if the contribution is solid; others say intent strongly predicts spammy work and is a necessary heuristic.

Beginners, mentoring, and gatekeeping

• Disagreement on whether the article is discouraging juniors:
  • One camp says it’s “gatekeep‑y” and overgeneralizes from one project.
  • Another says the message is: start from your own needs, join the community, don’t expect free training.
• Maintainers stress they didn’t sign up to mentor people who barely know how to code or use git, though some are happy to invest if contributors stick around.

Non‑code contributions (UI, docs, support, testing)

• Multiple comments highlight high value in:
  • UI/UX audits, mockups, and coherent design rationale.
  • Writing and improving documentation.
  • Answering support questions and writing guides.
  • Systematic testing and high‑quality bug reports.
• UI work is noted as politically and subjectively fraught; careful communication and clear reasoning are essential.

Starting your own project vs joining existing ones

• Building your own project is praised as a learning path, but:
  • Most personal repos get no users; that’s fine but not “community” OSS.
  • If something becomes popular, the long‑term maintenance and documentation burden can be unexpectedly heavy and stressful.

Ownership, responsibility, and practical advice

• Maintainers emphasize their right to ignore or reject contributions; time is limited and coordination is real work.
• Corporate constraints (IP, legal) can limit contributing back upstream.
• Concrete tips: use the software, start small (docs, bugs you hit), talk via issues before big features, provide minimal repros and environment details, respect “no.”