Exploring open source communities was like taking a peek behind the curtain for me. I have used a lot of different open source software, and actually exploring the spaces that created them makes me more thoughtful of the environment that made the tools I use regularly. Properly managing not only a community but a team at the same time takes a certain skill set that varies from project to project. I think overall the foundation of how an open source software runs is not too different in different projects, but as it gets larger and the pool of people who want to contribute gets larger there’s going to be a lot of different ideas and thoughts on how a community should proceed.
I particularly think of the situation with audacity and it’s community splitting because of thoughts on privacy and data collecting. One major difference caused a new branch that is managed by completely different people even though now the separate program, tenacity, is very similar to the original project, a single ideal can cause a split in the people who want to work together to create software. On one hand I can imagine it could be seen as a problem for some people that the people who they want to contribute to their software could leave and do their own thing, but on the other hand it’s definitely a positive thing that open source software developers have options and aren’t forced to work on a project they don’t agree with and can even take the project in their own direction without completely hijacking the community.
I worked on a little text based game called Text Fighter. It was completely written in Java so I figured I would be able to contribute in a way that felt meaningful. The community wasn’t super active, most of the contributors had made only one or two changes, and the developer made it clear that this is a project he works on occasionally, but it wasn’t dead. The first problem I ran into was navigating the file structure. It was confusing because where I thought I would find the code I found folders that were named after his email, and then the files ended up being inside those folders. It was structured like /Text-Fighter/src/com/kalebmarc/textfighter and apparently that seems to be a thing that programmers do because intellij and github will shorten it to as if it was all just one folder, or they shortened it because the in between folders contained nothing other than the next folder, i'm not entirely sure and that's part of what confused me while trying to navigate.
After successfully locating the files I wanted to edit, I began to make my changes and found that I couldn’t properly test them because an error was coming up whenever I tried to run or build the program. It was using dependencies, which I wasn’t familiar with, to run the test versions of the program, but I didn’t know how to make them work so it would stop the entire program from running, even though I wouldn’t even use them in the end. It’s a little off putting because I selected this project since I thought I wouldn’t run into any programming elements that were too advanced for me, but I knew nothing about separating the test files from the normal files and setting up the testing environment that the developer was using, and there wasn’t really any explanation on how to in the documentation. I ultimately deleted the test files, since I figured out I wasn’t using them.
So having gone through that, my first thoughts on how to improve open software’s ability to welcome new people is probably to make sure that people understand the different skill levels needed to effectively contribute. A lot of the projects I browsed through that had the tag “beginner-friendly” felt like there was either no programming needed or too much, and they don’t always make it clear. The github feature that shows what language is being used was very helpful, but putting in the documentation what level of understanding of the language is needed would be helpful to identify where someone could help.