I've always tried to contribute to open source software whenever I've seen the opportunity, but becoming a maintainer of an open source library gave me some completely new perspectives.

I've used Emacs for almost a decade, and I used Vim before that. Maybe the fact that vi key bindings are just another package in Emacs, called Evil, was one of the reasons I switched to Emacs. I like modal editing, but I don't use Evil. Instead, I use God mode with Emacs key bindings.

At some point, I discovered Doom Emacs, which packed a lot of functionality that interested me compared to other Emacs distributions.

I moved all of my personal Emacs configuration to Doom Emacs, which resulted in less code in my personal configuration. I still had a decent amount of code to personalise God mode, and someone suggested that I should make it a part of Doom Emacs. And so I did - I authored a God module in Doom Emacs. Almost all of my personal configuration for God mode was moved to this module, and my personal Emacs configuration shrank even more.

Things were going great, until there were too many itches in God mode to scratch. Contributors would have submitted pull requests to God mode, but the repository was archived. Chris Done, the original author of God mode, had moved on to bigger things, and didn't have enough time to maintain God mode. I volunteered to maintain it, and had the repository transferred to Emacs Orphanage where it would be actively maintained. That way, there would be more eyes on the repository and I wouldn't become a bottleneck in the future.

I started improving things at a small scale, such as:

• Reducing boilerplate configuration needed for God mode.
• Improving test coverage.
• Improving documentation.
• Making versioning consistent (in MELPA stable).

Most of the code for configuring God mode shifted from the module in Doom Emacs to God mode itself. Contributions started pouring in, and I started doing things that a maintainer should be doing, such as:

• Investigating test failures in older versions of Emacs.
• Deprecating support for really old versions of Emacs.
• Improving naming conventions of methods and customisable variables, without breaking existing configurations.
• Organising issues using labels.
• Closing stale issues that would never be implemented in God mode.

I was essentially supporting contributors who wanted to add features to God mode. The most significant feature, in my opinion, was allowing God mode to work in tandem with Evil (see #113). More people started using God mode - stars on GitHub went up, and downloads on MELPA went up. You could see how much people enjoyed using it through their comments on issues and pull requests.

From #118:

"... I feel like god-mode has filled a massive hole in my emacs config."

From #125:

"... A week ago, after using Vim for around 20 years, I have decided to try Emacs. I had tried Emacs multiple times in the past, but every time I would run away (screaming) due to its poor ergonomics ... I would like to thank the developers of God mode. Without you, I would not be using Emacs."

This points to a fundamental principle:

Improving the developer experience of an API indirectly improves user experience of both the API and products consuming the API, presumably on a larger scale.

Call me old fashioned, but the term API here doesn't refer exclusively to hosted services - libraries and frameworks provide APIs too.

The line between users and developers is blurry in the context of Emacs packages. However, providing package users with guardrails to contribute, such as documentation and good automated test coverage, nudges them to contribute and become developers.

Can extension methods solve the expression problem? »