Week 5 - Project evaluation

This week, I have been scouting the open source expanse for a project to work on. My criteria are straightforward: the ideal project is active, useful to me, and in a domain I have experience in. In my brief search, I’ve found a few projects that seem promising.

In class, I made a project evaluation of Ghostty that among other things, gauged how active the project is and how easy it is to set the project up locally. As I had expected, Ghostty is quite active and simple to set up (it only took running three commands!). Evaluating Ghostty as a project to work on, I also really enjoy using Ghostty as my terminal emulator. The reasons why are a little out of scope of this post, but I should point out that this post was written in Ghostty running Neovim. For my last criterion though, I have no experience writing Zig, which Ghostty is primarily written in, and I have no experience building application software, let alone a terminal emulator. The good news is that I don’t think this completely disqualifies Ghostty because Zig’s basic syntax looks easy to pick up and a few issues are scoped so that they don’t require too much domain knowledge.

Unfortunately, I don’t use any of the other projects evaluated in class and aren’t useful to me. VSCode is active and is a TypeScript project, which I have experience in, but as the evaluation points out, is an advanced project that requires a familiarity with the codebase. In a similar vein, I find Whisky is active and useful, but I don’t have any experience with Swift.

As I move towards making contributions to projects, I think the greatest challenge for any project is to find a first issue to work on. It’s often difficult to be first to claiming the “low-hanging fruit” issues and build familiarity, but it’s often even more difficult to make progress on challenging issues without familiarity. The two approaches I’ll take to combat this chicken-and-the-egg problem are to frequently check the issues list and to read merged pull requests to better understand how contributors reason about making changes.

Written before or on February 23, 2025