Reflections on a Decade of Open Source Contributions

Over the past decade, I have had changes merged and released in 30+ open source projects, ranging from foundational Java infrastructure to operating system tools to Linux desktop software to typography and music notation systems. Some were major projects with 50,000+ stars, while others were niche. For some I contributed only once, while for others I became a regular contributor or maintainer, and a few became major chapters in my life.

• Java Ecosystem: OpenJDK, Jenkins, Groovy, Jetty, JBang, JNR, Apache Ant, Apache Commons BeanUtils, Apache Commons FileUpload, Apache Commons Net, Apache Maven, Apereo Java CAS Client, EZMorph, Json-lib, and Monte Media.
• AI, Big Data, Full Stack, and Systems: WordPress, bpftrace, Presto, OSHI, vite-plugin-electron, vue3-observe-visibility, Isomux, and ptools.
• Linux Desktop: Ghostty, WinApps, QtPass, Universal Wayland Session Manager, Wayle, liblxqt, lxqt-openssh-askpass, qtermwidget, scmpuff, and meteo-qt.
• Typography and Music Notation: MuseScore, FontForge, tex-linebreak, Neanes, and xetbook.

You can see the full list of open source contributions I have made on GitHub.

In a day and age where AI is breaking down the social contract of open source software, it is worth reflecting on how to give people a good experience contributing to open source projects. Here are three lessons I learned from maintaining open source software:

1. Set clear expectations for merge. Few contributions are ready to merge right out of the gate. But in my experience, once a contributor feels that you are committed to working with them to get a change across the finish line, they will step up to the plate and do what it takes to finish it.
2. Reply in a timely fashion to issues and PRs. So many open source projects struggle with this. The demands on maintainer time are real, but I have learned that it usually does not take much to write a quick one-sentence reply, even if it is just “I do not have time to look at this right now, but I will get back to you soon!” That reassurance means so much to a potential contributor.
3. Be open to new use cases and directions. Some people have used my open source software in ways I never anticipated. It is important to be flexible and adapt to where users and contributors want to go rather than stubbornly sticking to a founding vision. By doing this, you can attract many more people to the project.