Recently, I stumbled upon an old video by ThePrimeagen where he claimed he’d quit using Vim for good after its major update.
For those who don’t know, Vim is a ubiquitous text editor, especially popular among avid terminal-oriented users. It is a legendary software, but it has a steep learning curve, to the point that “quitting Vim” has become a meme for being notoriously unintuitive.
ThePrimeagen is a prominent Twitch streamer, and a stark advocate of Neovim, a fork of the original Vim editor. In his video, he makes a solid point about the stubbornness of Vim maintainers to stick with a custom scripting language. On the other hand, Neovim, promotes the well-known Lua language for its powerful plugin system. This alone determined his final choice to stick with Neovim, and as of 2025, I doubt he has changed his mind.
The delusion behind open-source
This story is somewhat related to what I’m trying now that I work full-time on Passepartout. Passepartout is an open-source project in that its code is public, but there are almost no code contributions, just issues. There are good reasons behind this.
Many of those who create some sort of open-source software think that it must be interesting by default, just because it’s open and available for free. Rarely will they realize that popuplar free software not only is popular for being free, so they live the delusion that the open-source model “doesn’t work”.
For example, pick any GNU tool (grep, sed, make, …) or even Linux. They became popular because they were useful. Being free and understandable software made them thrive through public contributions, but this was never the first step.
The interest in contributing to an open-source project is determined by multiple factors, in order of importance:
- Goals
- Well-written documentation and directions
- Welcoming community
- Technical stack
- Stable software architecture
Now, observe how any well-known free software meets 1-5 in that order.
Vim and the self-conscious tech
Given that both Vim and Neovim are amazing and well-documented products, their tech paths reconnect with the initial backstory.
Lua makes Neovim infinitely more attractive than Vim when it comes to adoption and open-source, and the choice of Vimscript over Lua may even determine the death of Vim in the long run. I don’t know the “drama” that resulted in the fork of Neovim, but I wouldn’t exclude that Vim took its relevance for granted just for being the OG of the two. In fact, I don’t think that Vim today can claim being cooler than Neovim other than for being the original one.
Even if a software is well-crafted, it’s evident that a Pascal application will only attract a handful of developers, whereas JavaScript would open up to the entire globe, and the same applies to Vimscript versus Lua. If your software is written for yourself and requires developers to learn a new technology to contribute, either it is the most remarkable piece of art in software history, or you might well end up yelling at your echo chamber.
A new JavaScript API in Passepartout
The Vim story taught me that I needed to make my project more accessible to the potential contributors, otherwise it will never be more than a one-man team.
While I invest a lot in making the software architecture as modular as I can, I haven’t spent as much time in documenting how to start contributing to the codebase. I know myself how intimidating it is to submit a PR to someone else’s repository, so it’s crucial that we, the maintainers, provide a viable entry point to those willing to collaborate. A welcoming, non-judging community also reduces the friction of the first public contribution.
One part that I’ve always found potentially accessible was the Providers API, which is how Passepartout auto-compiles VPN configurations for a plethora of provider servers. Nevertheless, no one ever contributed a single provider, and no wonder: providers were generated in CI with a convoluted set of undocumented Ruby scripts. Who on Earth would want to touch that mess?
When I found out about JavaScriptCore to solve a different problem, I suddenly realized how scripting could be a lower barrier to enter the Passepartout codebase, as there are way more JavaScript than Swift developers out there.
With the help of AI, I rapidly converted the old Ruby legacy to a brand new Node.js implementation that most developers would find easy to understand, develop, and test without even installing the app. Then I started documenting how to submit a provider step by step. This doesn’t imply that people will start adding new providers today, but offering accessible tools and documentation is a strict requirement for that to happen.
Conclusions
Open-source success isn’t about being free, it’s about being accessible. Tools like Neovim thrive because they choose approachable technologies like Lua, making contributions easier. Similarly, by adopting JavaScript for scripting, Passepartout lowers its barrier to entry and opens the door to wider community involvement. If you want contributors, you must meet them where they are.