Contributing to the tools I rely on every day
Open source is not charity. It is how serious software gets built, and it is how serious engineers grow. The tools I use every day — Emacs, org-mode, the entire GNU stack underneath them — exist because people contributed on the margins of their time. Not for payment. Because they cared about the craft.
There is a form of intellectual dishonesty in depending on something without ever looking at it closely. I have been using org-mode for years as my primary system for thinking, planning, and writing. At some point it becomes uncomfortable to only consume. You read the source. You read the docs. You start noticing things.
Contributing back is, at its most basic level, paying attention. It is taking the thing you noticed and making it slightly less wrong for the next person who reads it. That is enough of a reason.
Org-mode is my operating system for thought. Task management, journaling, agenda views, knowledge management, and static site publishing — all of it runs through plain text files in a format that has been refined for over twenty years.
It is a GNU project. The codebase lives on Savannah, not GitHub. There are no pull requests. Contributions happen via patch files sent to a mailing list — emacs-orgmode@gnu.org — and maintainers apply them with git am. Old-school, deliberate, and surprisingly pleasant once you understand it.
Because I use it daily, I read the documentation constantly. That is where typos live — not in hot paths, but in the explanations and docstrings that everyone skims and nobody fixes. Small errors in documentation are a form of technical debt. They erode trust, create confusion, and compound over time.
git.savannah.gnu.org/git/emacs/org-mode.git, stay on main. No forks needed.git format-patch HEAD~N produces numbered .patch files — one per commit — containing your name, the commit message, and the diff.emacs-orgmode@gnu.org. Subject line: [PATCH N/M] description. Include TINYCHANGE in the body if the change is under 15 lines — this waives the FSF copyright assignment requirement.git am < your.patch. Your name and email go directly into the commit history. No rebasing, no merge commits — just your work, attributed correctly.Patch series submitted to the org-mode mailing list. All fixes are prose corrections in documentation, release notes, and Elisp docstrings.
| Patch | Files | What Was Fixed |
|---|---|---|
| doc: Fix multiple typos | doc/org-guide.org doc/org-manual.org |
4 prose errors in the clocking and agenda sections — missing word, wrong plural, duplicate word, missing auxiliary verb. |
| etc/ORG-NEWS: Fix typo | etc/ORG-NEWS | "varible" → "variable" in a new feature entry. |
| lisp: Fix typos in docstrings | ob-tangle.el · ob-lilypond.el ol.el · oc-basic.el ob-comint.el · org-persist.el org.el |
11 errors across 7 files — spurious "be" in passive constructions, duplicate "or", wrong article "an a", misspelled "succesfully", and missing preposition "to". |
| lisp, testing: Fix typos | ox.el · ox-html.el org-agenda.el test-org-habit.el |
6 errors — misspelled "succintly", spurious "on" in "set on with", wrong plural "value are", duplicate "the". |
| lisp/org-table.el: Fix typo | org-table.el | "filed" → "field" in the docstring for org-table-exit-follow-field-mode-when-leaving-table. |
| lisp: Fix typos in docstrings | org-protocol.el · org-mobile.el org-feed.el · org-id.el |
5 errors — "indented" → "intended", "his work" → "this work", missing preposition, wrong verb tense, subject-verb disagreement. |
| lisp: Fix typos in docstrings | ox-publish.el · ol-doi.el ob-emacs-lisp.el · ob-org.el ol-docview.el · ol-w3m.el |
6 errors — subject-verb disagreement, double article "a the", wrong participle, split sentence with misplaced period, "test" → "text". |
Typo fixes are the entry point, not the destination. They teach you the codebase layout, the commit message conventions, the mailing list culture, and the maintainers' expectations — before you touch anything that could break.
The next level is substantive: incorrect docstring descriptions, misleading option documentation, missing edge cases in comments, or small behavioral bugs that are easy to reproduce and narrow in scope. Those require understanding what the code actually does, not just reading it for errors.
Org-mode is one of the most carefully built pieces of software I have ever read. Contributing to it — even in small ways — is a privilege and a continued education.