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.