This week in class, we focused mainly on evaluating open source projects and seeing what open source projects would be appropriate given a person’s skillsets, timeframe for doing substantial changes to a project, and previous experience, as well as ensuring that I am working on an open source project and there is some sort of structure (e.g. code of conduct and contributing readme) going on to prevent toxicity in the project. After looking at multiple open source projects, I kind of felt a bit of concern in finding a project that works with my given constraints.

Johanna, our professor, actually gave a pretty good framework for evaluating whether an open source project would be appropriate for a person to contribute to. First, it should align to your own goals in mind and/or skillsets you already have (so it kind of sounds appropriate for someone who wants to gain some experience or already have experience working on an iOS app to seek out open source iOS/macOS/watchOS apps to contribute to). It should be a project that you can easily get started with (in terms of compiling and running the project code that you cloned from a repo, as well as having issues that are labeled such that a beginner could try fixing the issue). It should be a project that doesn’t feel mentally draining to work on (and I’m talking more in terms of how other people act when you have to work with them on contributing to the project). It should be relatively active.

However, when we started looking at the projects, I started feeling a bit concerned about finding a project that aligned with all of these goals. Whisky, a frontend GUI to make launching Windows apps and games easier (with the use of Apple’s Game Porting Toolkit and Wine), seemed like a good project. However, I didn’t like how it was mainly a one man show (and as such, it would be hard to break into contributing for the project). The fact that there were no clear labels for good first issues in the issues page was also kind of a problem too. (Ironically enough, I would probably be able to contribute to this project relatively easily if it wasn’t for the fact that this project was a one man show, since I have Swift and SwiftUI experience, which this project uses extensively.)

Then, there were the projects that had a lot of good activity and are conventionally good open source projects to work on (though it’s a bit too popular to contribute and stand out in), like Godot, a 2D and 3D game engine. There is a lot of documentation specifying how to create and structure pull requests for clarity, as well as encouraging the development of unit tests just in case a future contributor accidentally breaks a functionality a current contributor implemented. There’s a good code of conduct that seems to work well with preventing toxicity. However, it seems to be a bit too popular and whoever is contributing to Godot must be familiar with the game engine (which I clearly am not, as I am mostly an iOS developer that takes advantage of SwiftUI’s cross platform abilities to make apps for macOS). Ditto for VSCode, but I’m pretty familiar with VSCode and the functionality, but it’s far too active and there aren’t really good first issues to work on.

(Although, it seems like I am pretty much banned from contributing to any of the projects listed above for this class.)

To sum up, I am looking at this idea of working on open source projects with a little bit of concern, since I feel like there are times when I want to work on open source projects, but it’s just way too active, or the community is too toxic, or the project just doesn’t have the structure in place to ease users into working on the project (which becomes particularly annoying if you have limited experience working in a certain tech stack or programming language and need to learn that too). This latter concern would also be compounded by the fact that I would have to learn the tech stack or programming language as well (and in a relatively short amount of time), as well as the potential unfamiliarity of using the software and understanding why people use the software.

I feel that these concerns could most likely be alleviated by dogfooding (or using the app as if I am an actual user of the app) the app when working on the project, as I feel that I can act on major pain points of the app if I know what they are and try to figure out where in the code the pain points are caused from. The other way I could probably try to get around this issue is to try and find a less active project (but still active enough), unlike the previously mentioned projects and try to poke around a bit and see what issues come up. I could also find a software application project where there is strong platform support (such as an iOS or Android app, where both Apple and Google are great at pushing new features users can actually see and interact with), or a project where there is a lot of rewriting/refactoring going on (e.g. a project that is transitioning from an older to newer UI framework). (Heck, maybe I can even start my own new open source project!)

Furthermore, I feel like I’ll have to do a lot of due diligence in terms of picking the right project in terms of reviewing the community activities. I will need to see how fast issues are solved, as well as the actual vibes of the community (which is easier when all the discussion occurs in real life, but not really when I’m offline). Code of Conducts and contributing guidelines can only go so far in terms of dictating how these open source projects go.

I am excited, however, about potentially contributing a lot to an open source project to the point that I become a strong contributor in that project to the point that other commercial companies might see my work as an asset and convert my volunteer time to this open source project to a paid position (that’s mainly working on the open source project, but revolving around whatever fixes or changes need to happen for the business needs). I’m also excited to get a chance to potentially work on a tech stack that’s just different enough that I can quickly adjust to the new tech stack at hand and potentially learn a thing or two about best practices working with that tech stack. (And don’t forget about how it looks good on resumes, although I already have a good amount of personal projects in the form of apps for Apple platforms, though it tends to use newer APIs, which these open source projects may or may not do.)

Ultimately, I am feeling a bit of everything when it comes to working on a new open source project. A bit of concern over maybe choosing the wrong project for any number of social, experiential, or technical reasons (compounded by actions the project owners or maintainers do), but a lot of excitement over how working on open source projects can improve my skills in a tech stack/programming language I am currently familiar with or build knowledge on a tech stack/programming language I am not familiar with.