The Promise of Open Source

14 Jun 2025 open-source · technology

Using open source software can be a fair bit of work. I emphasize that this is a choice, as it is entirely possible to install Ubuntu on your computer and use it for all your daily activities, without thinking about customization. Say you want to open multiple windows, and have them all take up equal space on your screen automatically. This is possible: You can use a tiling window manager. There is free and open source software out there which can do it. However, it is not being marketed anywhere by anyone: so you have to search for it. There are no automatic QA suites that run against it, nor is there testing to verify if each version installs without hiccups on a wide variety of supported operating systems. There is no such thing as a fixed release schedule, or quarterly OKRs, or a vision document. The project does not employ UX researches, who talk to users of other tiling window managers, or product managers that compare the project against its competition. The setup that the project author is using might be the only supported system. To me, these are minor annoyances when one considers the substantial promise of free and open source software.

I use a mix of open source and proprietary software on a day-to-day basis.

1. My primary phone is an iPhone running iOS (proprietary)
2. The gaming console in my house runs a proprietary OS, originally based on OpenBSD (open source)
3. My computers have some distribution of Linux installed (open source, but with proprietary drivers)
4. Some of these computers have Windows installed in a dual boot configuration¹
5. The secondary phone is running Android. The OEM no longer sends OS updates, so it is stuck on an old version of Android.
6. The e-reader uses proprietary firmware and a proprietary operating system that is based on the Linux kernel
7. The Internet router uses proprietary firmware written and maintained by the manufacturer of the router

… this sort of inventory is interesting. I understand that living completely on open source software is very difficult. I am not an ideologue about this: One must use the tool that fits one the best. If you want to use iMovie to edit your videos, or iCloud Photos to manage your photo library, then you should. I believe that this choice must be personal and intentional. The only criteria for me is one must not “go with the flow” and choose the path of least resistance.

Let’s say I was to live completely on open source software. Almost everything that is proprietary in the above list can be replaced given infinite time, effort, and cash. This does not appeal to me, and may not appeal to you either, but it is possible.

For instance: Recently, I attempted to install OpenWRT on an old router. It went horribly: The installation seemed to “just work” at first, buoying my hopes. A couple days later, I noticed that it was not actually working. Attempting to track my way back to the problem, I managed to soft brick² the router. Through some (unknown and random) combination of reset button presses and pulling-the-plug actions, I was able to at least get the router to boot, and fix the router by installing its stock firmware. The router is now usable. However, the recovery was not complete because the login page for the router still (inexplicably) redirects to the OpenWRT LuCI CGI page, even though OpenWRT has been apparently completely removed from the device. I don’t need that router to work desperately, and I was experimenting for fun, so I knew the risks. I can still clearly see myself half a decade ago in college, considering this move to OpenWRT; back then, I decided not to try it because I might lose the only device I had at hand. This is the jeopardy of playing around with open source. (I have chosen a somewhat extreme example here. The stakes are usually much lower when one is dealing with software; for instance, if someone is considering replacing the Microsoft Office suite with LibreOffice, then go for it! There are no downsides and it is a reversible decision.)

The ability to read and improve code is the big advantage with open source. I believe that this is overstated in most circles, and especially by the ideologues. “You should use Linux because all the code is open source. If you see something you don’t like, then you can go in and improve it!” This is something that I have heard many times in conferences. However, this is not possible in as an individual user of a software package, because even though the code is available, the expertise required to update the software that one uses is not easy to acquire. In projects that are not particularly well-managed, even having the expertise might not be sufficient, because the projects’ dynamics are not very friendly to outside contributors (see this excellent story.)

I can think of many projects that I use where I would like to contribute minor changes. I have been able to make meaningful progress only on a few of these, because the programming languages I know are limited. Once again, the interests and expertise of each user become the deciding factor. This promise does have benefits for all users though: If enough people use a software package, then a handful of them may run into the same problem, and one of them might have the expertise to fix the problem. If the problem is actually fixed, then everyone who uses the package benefits from the output. This fundamental “more than the sum of its parts” nature is the reason I think contributing to an open source project is rewarding.

In my case, I have ideas for the things I use daily:

1. Firefox: A web browser. I have wanted the ability to set a native keybinding for copying the link of the currently open webpage in the browser. I get by using the Copy-as-Org-mode browser extension, along with the extensions keyboard shortcuts feature. This setup works well enough, but I was never able to understand Firefox’ code enough to make a patch
2. GnuCash: A Qt-based GUI accounting application. I have run into a couple obscure bugs in my usage. Neither of them were major, I reported one of them back in August 2020, but I did not get a response. I could not independently figure out what part of the code they were happening in. Another change I have wanted for a while is a minor update to copy, to make some alert messages easier to understand, but even this apparently simple change has remained elusive to me
3. Notmuch: An application to index and search e-mail based on tags. I wanted a feature to write tag updates to a file. I managed to make sense of the (excellently written and very readable) C code and wrote a patch for this. The patch works and I have been using the patched version of notmuch for several months, but I never understood the tests enough to fix the failing ones, and submit a patch upstream. I will probably not bother with applying this patch when I upgrade to the next version of Notmuch
4. PaperWM: An excellent Gnome extension which has given me the confidence to truly abandon i3wm and stick to Gnome (I know Gnome has a lot of issues.) I ran into a serious, and distracting bug; one that a window manager should never have: 2-3 crashes everyday requiring a full restart! The bug was easy to track down, and a simple fix was easy to write. (This extension does not have any tests, so that was not a hurdle, but it also makes building confidence in a fix difficult.) I opened a patch upstream, and the patch was accepted into the version where I saw the error. The patch to the default branch was not accepted because I did not reproduce the bug on the latest version of Gnome. I totally understand the maintainers’ reasoning. After this positive experience, I feel confident that if I run into any other bugs with PaperWM in the future, I can fix the bug and work with the maintainers to get bugs fixed upstream.

Open-source legacy software also makes it more likely that a lighter weight replacement comes up and displaces the ancient behemoth. The classic case that I can think of is Wireguard’s displacement of IPsec. Wireguard was possible because the Linux kernel, and IPsec, were both open source, enabling the author to see the problems with IPsec’s huge size, and the possibility of a new VPN protocol that would fit well within the Linux kernel. The effort required to write and upstream Wireguard into the Linux kernel must have been huge, and it would not have been possible if any piece had been proprietary. A proprietary protocol might not be popular enough to warrant anyone thinking deeply about replacing it; or worse, the protocol might have become a commonplace due to its sustained usage at large enterprises, making its replacement technically challenging, and causing it to survive despite the existence of severe issues and better alternatives. I can not really imagine running IPsec at any point for a sustained period of time. Running Wireguard has not been a problem and I enjoy being able to run a VPN immensely.

---

Using open source software keeps computing interesting. It keeps enthusiasts engaged with the way computers are changing. It keeps users aware of what’s possible when one gets out of the walled gardens. There are perhaps three levels of engagement with open-source:

1. Users: Use things as-is
2. Hobbyists: Tinker with open source software at the edges
3. Enthusiasts: Make significant changes or new packages

Everyone is expected to walk down all three roads depending on what they use and their expertise: I am a user of VLC, Firefox, Debian as-is; I tinker with Gnome-Shell extensions; I build command-line tools to make configuring Wireguard easier.

Everyone can contribute, that is great. No one feels left out or like they are not contributing, that is even better. It is amazing that all of this, this ecosystem, continues to work. I will always be grateful for open-source software and actively support it by going down whichever one of the above three paths makes the most sense.