As a group, our contributions have had varied, positive impacts. We made changes that make the platform more accessible. We enhanced the software to render it more complete and polished. We performed feature implementation research for areas that haven’t yet been explored, which can act as guides for future development. A bug relating to building the tool was reported and fixed as well, improving the quality of life for developers and users who build from source. We plan to have ownership of the code we implemented in the future, taking responsibility where appropriate. We also plan to tie up any lose ends, even once the course is through.
]]>My pull request to enhance theme generation on Keycloak is still in review. That isn’t to say it has been under review this whole time, just that it hasn’t been reviewed by the primary code owner yet. And unfortunately, that [partially] blocks development on my other issue to implement rendering of custom theme names. This slowdown is primarily caused by the release of Keycloak 26.6.
So in the meantime I have worked on this new PR, requiring users to enter the name of their realm before deleting it. Deleting a realm (and its associated data) is irreversible, and the goal for this is to mitigate accidental deletions.
I decided to publish the Gradescope privacy extension my team and I made in class on Firefox Add-ons. It can be found here. I also decided to revert some of the features implemented in the original code as they felt unnecessary for a privacy focused tool. Additional changes were made to the CSS. The extension functions as expected when users hold student status, but bugs may appear if the user is a professor.
I created a discussion post on Mozilla Connect. I believe there should be a hotkey that allows the user to toggle visibility of the sidebar on Firefox, although as of today, it has not received any community feedback.
]]>As a result, the presence of open source software in the realm of for-profit enterprises has skyrocketed. Take, for example, ESLint. ESLint is the go to JS linting tool, and is used in combination with pre-commit by virtually every company, team, and/or project working with JavaScript. It is invaluable to the code maintainance of certain repositories.
So, do they just take the free software and move on with their days to generate exorbitant profits? Not always. Thankfully, many companies realize the value open source projects and developers provide them. So they give back. ESLint’s sponsors, as of today, notable include Vite, SAP, Icons8, Discord, Netlify, and 1Password. Companies and organizations also give back via non-monetary contributions. If a team needs a feature implemented or a bug fixed quickly, they oftentimes have the resources to do it themselves and submit a PR for it.
Open source software adoption in the commercial space can be a catalyst for development of tools which can benefit everyone. One perspective, adopted by many manufacturers in the automotive industry, is to cross collaborate on certain things so that they all have the foundations to build separately and focus on differentiating themselves. Automotive Grade Linux is a perfect example of that, with leaders like Mazda, Toyota, and Honda backing it. This [hopefully] helps to ensure that the software inside the cars we drive is safer, because if more companies rely on the same tools, you would expect them to ensure that their tools are good. Additionally, it allows car manufacturers to focus on doing what they do best, actually manufacturing cars.
I am hopeful for wide-spread adoption of open source software, both in commercial and non-commercial spaces, and I believe that it would bring very benificial changes.
]]>Development within a silo, all alone, can be very detrimental to a project. Your perspective is influenced by you and if you have a customer, them. However, if you develop with the idea that your code is public (even if nobody else looks at it), you are pushed to consider multiple different perspectives for what users may want or need, resulting in a project with stronger foundations, more useful features, etc.
With the proliferation of AI tools, it is important that developers continue to use oversight. One of the greates strengths behind the Bazaar Model is that many different people are contributing their different, unique perspectives and ideas. If everyone is using the same AI tools, which are all trained on the same data, then people are no longer contributing their own ideas. However, AI tools do have their place in Open Source Software Development. They enable faster triage, code reviews, and more. They also allow for new contributors to very quickly enter a code base and make small adjustments.
So I don’t believe that AI tools should be dismissed by open source projects. But it is important that contributors use them carefully, ensure that the tools are not replacing the thinking and creativity that really matters.
This past week, my PR to enable locale-based theme description translations was merged into main. I had initially created the PR in ‘Draft’ mode, and after some back and forth with a maintainer, got the code to a state that was good, and they moved it to ‘Ready for Review’ and put it through. This PR makes Keycloak a little more accessible, because users from other countries will be able to read the theme descriptions in their own language, once translations are made.
I made an additional contribution by creating a new issue highlighting how a current feature could be enhanced. Current theme generation has many hardcoded values, which prevents multiple custom themes from being loaded. Additionally (with the new description fetching logic implemented in my PR), we can now utilize locale files stored within themes to render custom descriptions. For this ticket, I plan on proposing dynamic string handling as well as creating locale files with the custom descriptions when generating theme .jar files.
I also made a clarifying comment on someone else’s PR, who was working on a similar part of the code base as I.
Listening to the stand up reports this week, I was glad to hear that other teams were making progress. Many teams were working on smaller enhancements, such as documentation. What I believe is happening is that that many people are not users of the projects they chose, and so they are picking up tickets they see on the Issues pages that are easier to complete. Additionally, it can also be difficult to find your footing. As students, we are fresh to the projects, and it isn’t always easy to understand a codebase. So people may have trouble picking up tickets that have large impacts on functionality. I have spent almost all my time focusing on themes contributions, and I am beginning to actually understand how it works, and I believe is an advantageous for me to focus on themes further.
]]>As for contributions to our group project, I began work on a draft pull request to implement translation of default themes. This is proving to be a tough issue because:
But the good thing is, it’s learning opportunity. Here is the link to the PR.
]]>I also made a contribution to the General Dynamics Wikipedia page by correcting the title of the GDEB subsidiary.
]]>Listening to other groups perform their standups put into perspective the speed our team is able to work at. Others were getting their development environments set up while we were already busy assigning work and creating issues. Relatively speaking, they were experiencing the same things we had already gone through.
However, our speed was not fully to our advantage. We had overlooked rebuilding the source code of the repository and created an issue for a feature that was already implemented. Once we realized that, the issue was closed. It is difficult to be a user and be fully up to date on the status of what still needs to change because the nightly build is far newer than the versions that the maintainers release on Docker.
]]>Our group began by scheduling a meeting and evaluating the projects we were interested in together. This involved reviewing each project and exploring the software. When we decided we were interested in a project, we attempted to install the development environment. After that, we moved on to the next project on our list.
In class, we looked at the projects we had selected for our final decision. It came down to Keycloak and Pandas. We decided to go with Keycloak, as working on a visually interactive tool was more appealing.
No obstacles have been hit yet, but when they are, we will fall back to our working agreement defined here.
We will soon begin evaluating different tasks we can take on, and determining how we can contribute as a group or as individuals with similar goals.
]]>To prepare for choosing the projects we would soon choose to contribute to for the rest of the semester, I completed new evaluations and followed different Getting Started processes.
Although I had already gone through this process earlier, I completed an evaluation for Keycloak - so that it’s info was available to others in the class organization. Keycloak is a project that I would like to contribute to for this class.
Next, in class, a group of students and I evaluated Electron. We used Gemini’s Deep Research model and compared our evaluation with its. It is good at finding URLs, but falls short in other areas such as judging friendly-ness to new contributors and those sorts of things. It’s documentation is straight forward, but I could not complete the build process. Around an hour after running the build command in my terminal, a brew error is thrown and I could not solve it. Electron is not a project I would be willing to contribute to for this class.
Next, I followed the evaluation and build for Jellyfin. This was easy and took around 10 minutes. Afterwards, I used the service to stream some of my music. Jellyfin is a project that I would be willing to contribute to for this class.
I would also be interested in contributing to GIMP.
So far I have made contributions to the class GitHub repository, Keycloak, and the highlight project made by Aisha Roslan, Yuxuan Qin and Ruilin Guo.
For the class GitHub repository, I reported an issue regarding .DS_Store being tracked. I am also working to get a typo fix merged into the reporitory. The challenges with this contribution are mostly in relation to different issue reporting and fixing practices.
As for Keycloak, I added a way to render descriptions of themes for the application, that way users know what they are selecting. So far, this was my most difficult contribution. I had to make different revisions to code across multiple files, making changes that were not only visual. Due to the difficulty of the changes, this was the most rewarding to complete. I plan on adding a field to the theme creation menu so that users can create descriptions for their own themes.
Regarding highlight, I implemented a button and logic allowing users to copy MLA citations of their highlighted text to their clip board. This was relatively straight-foward, and the team was responsive and helpful.
]]>Watching each presentation, my main thought was “would I download this”? Admittedly, I am more interested in extensions that can better the tools I already use than purely aesthetic ones. This aligns with trying keep my working environment unbloated and efficient. While a browser-intergrated language model could be handy, having it take up all of my RAM wouldn’t be.
Two projects that stood out to me were tab-down, made by Sebastian Capellan and Angela Gao, and highlight, made by Aisha Roslan, Yuxuan Qin and Ruilin Guo.
tab-down is a browser-in-browser tool, allowing users to keep a tab in the corner of their screen that can be displayed when hovered over, and is visually similar to the MacOS Quick Notes feature. Except you can’t run web-apps or load sites in the notes app.
highlight is a neat extension that allows you to make highlights on the fly across different sites, and find all of them in a central place. I think it would be cool to add export functionality to the highlights, incase you want to cite them.
Neither project attempts to pack in unwanted features, and does what they intend to do.
I found the keynote with Kelsey Hightower entertaining. He emphasized the importance of the communities behind open-source projects and encouraged corporations to contribute. Even if core contributors have such great differences that they end up branching off, it is important to understand that it is the nature of open-source, and to keep co-collaborating.
Craig McLuckie, in the second video of the summit, spoke more about supporting open-source communities. What he considered important for corportations to do though was to adopt the projects they value and to “vote with your wallet”. It is important for OSS communities to be recognized for their work, because otherwise, who are they making the software for?
The final video was with Linus Torvalds and Dirk Hohndel. Their conversation highlighted that open-source development still has it’s drawbacks. When a project becomes huge, the code’s integrity can outweight many of the benifits of open-source development, such as public, cross-colloboration (in regards to Linux’s security incident response). Working on these kinds of projects can also be very time consuming, and are not always what you may want to spend your life working on.
Oftentimes, when I present, I feel as though I am there to deliver on keep points. And I believe that may the case for my peers in class. But after watching the keynotes, I realized that a much more entertaining and captivating presentation is one that has a story or a narrative. Something to keep the audience engaged. Both Kelsey Hightower and Craig McLuckie had anecdotes in their talks, and much of Linus Torvalds and Dirk Hohndel’s Q&A included reflections on the past, relating to the topics they were discussing.
Having a story to tell or take the audience along with you on makes for a far more engaging presentation, and this is something I want to work on. When the time comes, I hope to add a little of this to my presentation.
]]>