Thoughts on development using the Cathedral vs the Bazaar Model

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.

Keycloak Progress

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.

Group Reports

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.