Back to Work + More Presentations

Following my group’s project presentation last week, we got back to work making contributions and got to see what the other groups have been working on.

Presentations!

This week my group was the first to present our open source project contributions, which we did for the dashboarding tool Preswald.

Getting Ready to Present

This week my group was mainly focused on preparing our presentation, which will be on the 23rd. This was a great way to reflect on all of the work we have done so far as well as what the last few weeks have for us.

Part 1 - The Cathedral and the Bazaar

Eric Raymond’s essay provides some very interesting insights about the early days of Linux and how it changed his (and probably a lot of people’s) ideas about open source development. Reading it several decades later, many of the topics he brings up are still relevant in my experience with open source.

Part 1 - Project Progress

Before spring break, my group was able to finish our first round of significant contributions, developing four new features for Preswald.

Open Source Speakers

This week, we had Nick Vidal from the Open Source Initiative give a lecture on open source AI and the mission of the OSI.

First Week of Contributing in Groups

This week we finally formed our teams to start contributing to a project for the rest of the semester. My team was very open regarding the topic of our project and we took our time exploring different projects before coming to a decision.

Making Small Open Source Contributions

After spending six weeks learning more about open source, I frankly still find making contributions quite intimidating. The prospect of walking into a project, learning enough about it to make contributions, and then submitting my work to strangers to critique and possibly use in a release feels like a massive and scary undertaking, even if I am now somewhat knowledgeable about the process and know most contributors are excited to welcome new people into their projects.

Evaluating Open Source Projects

Contributing to open source projects can be a huge commitment, so it’s important to be informed before you jump in. This week we explored how to effectively evaluate a project and decide if it is something worth contributing to, which was a very valuable experience.

Part 1: Git

Git is a fascinating technology because you can use it for years and it will always manage to find new ways to make you feel stupid. At its core Git is pretty simple, if you know push pull add, and commit, you can more or less get by, but when you start going under the hood and trying to explain what’s actually going on it gets a lot hazier. I suppose this is the case with almost any piece of technology, but Git always manages to scare me a bit when I start getting in too deep.

Developing a Firefox Browser Extension

Part 1: The Idea

My team chose to develop a browser extension that tracks the user’s time spent on a website. The user can opt in or out of being timed on the tab, and if they opt in it will mark when they opened the tab, when they closed it, and the time spent on it. No one on my team is very familiar with developing extensions, so we wanted to do something relatively simple that would still be useful. With this, you can do things like see how much time a task took you or monitor how much time you spend on something like social media, so it can still have practical uses despite its simplicity.

The Code of Conduct For Open Source Projects

Part 1: Go, Eclipse, and the Contributor Covenant

Go’s community code of conduct explicitly outlines the values that they expect contributors to uphold when interacting with other members of the community, as well as the staff’s responsibilities for enforcing these standards. In doing so, they ensure that there is an easy to follow set of guidelines for how contributors should act and what to expect if they do not follow the rules, making it easy for staff and other community members to hold them accountable for inappropriate actions. Open source projects attract people from all different backgrounds, so having these expectations set in stone ensures that there is no confusion among collaborators regarding what is acceptable, and ensures that everyone feels comfortable contributing to the project. I believe having a code of conduct like this should be standard for any open source project that involves collaboration among strangers to keep everyone safe and comfortable.

To me, “open source” means a project that is publicly available and allows users to make contributions or new forks of the project. This can be great because it typically means the project is free to access and use, it can be supported for much longer because if the original developers decide to stop maintaing the project it can be continued by others, and it can be easily screened for security risks. People can also use open source projects as the basis for new work, expanding on the original project’s ideas and bringing in new functionality that the original developers may not have thought of or were against implementing. However, open source comes with its own set of issues, as enabling anyone to contribute can pose security risks if not screened properly, developers often can’t profit off of their work and therefore have to develop open source as a hobby if not funded by donations, and any potential vunerabilities in the code are open for anyone to see and potentially exploit. Despite these problems, open source projects are an invaluabe resource and should be worked on.