Over break, we our class was tasked with reading “The Cathedral and The Bazaar,” which was effectively the first notable academic work to closely inspect the core differences between software characterized by closed-source development with slow, orchestrated releases (cathedral,)and software that was alternatively open source with constant changes always flowing in from the decentralized user base (bazaar.)
Most of the general philosophy brought forth in the work holds up today, if not more than ever, especially because of the evolution of one sub-field of technology: AI. With AI assisted tooling for developers, the barrier of entry for developer contribution to the “bazaars” has massively decreased, but it also means that people with expertise are more crucial than ever with some of the dangerously misunderstood changes being submitted to a repository. There is more inclination to lean towards “cathedral” style software models in the modern day as a result of this inherent risk from careless AI use, and we have even seen some “bazaar” style models recently take action to make the contribution process more scrutinized. Even with all of this change, the philosophies covered in the paper still hold.
Progress on our project has been steady. Ben and Albert have made a pull request for their issue, and me and Jerry have begun work on our multi-level feature, also going as far as to reach out to the developers communication channel in order to get advice on a design decision. Albert has also started work on an issue I previously reported. We are looking forward to seeing some of our changes get merged soon.
In terms of the work other groups have been doing, it seems to be quite similar to some of the things we have achieved with a large bulk of changes being documentation based, but there were actually a good portion of bugs & features that were developed, and in the cases of some groups, already merged which is cool to me. Most people seem to be on a similar page with communication though, where it varies greatly on a case to case basis, and usually takes a duration of time veering towards the longer end, so I am put at ease with this and as a result have been having a better time being patient with maintainer responses.
]]>Although it took a while for it to catch on, I am glad for companies like Red Hat initially going forth and pioneering open source within the professional industry, as I know for a fact we benefit from it greatly today. Many companies today have sectors of employees that they pay primarily to maintain open source software because it is so crucial for business operations. Additionally, open source software can be profitable based on how companies model their business around it (as previously seen and mentioned with Red Had,) so I am a true believer that as time goes on companies will adopt more and more open source ideologies as the software continues to strengthen and legitimize.
The issue I previously opened about the Maven Wrapper being outdated got a merged pull request, so that was a success. Ben and Albert have been continuing to work on different issues surrounding the themes, and me and Jerry have made meaningful progress on our organization based session timeout feature implementation, with us having touched the database, changelog, and model layers of the application. Now all we need to do is create our service implementation and then create a UI component to test our work, and we will have an MVP ready to put on a pull request to show maintainers.
For my personal contributions, I have been starting to find myself more comfortable in addressing issues and making changes. Particularly, I have been contributing to an open source project known as “Archipelago,” which is a multi world game randomizer to make gaming with friends more interactive, social, and fun. I made a bonafide code fix and created a pull request for it yesterday not just regarding boilerplate or getter setter methods, but touching actual OS level concepts in multiprocessing, which was very cool to me. It passed a review and I am hoping for it to get merged soon.
]]>Over the past few weeks of school, there has been a break, a faculty strike, and lots of open source project progress. All of these things have been showing promise so far, but today I want to discuss open source progress on Keycloak. Me and my group mates have been making steady contributions, with issue creation, discussions, and commits. I personally have been able to open an issue regarding a bug I found during dev environment setup on windows, have made a pull request for some documentation edits I made to address an issue, and started a discussion on the scope of a brand new feature that would make legacy database migration to Keycloak much easier.
I won’t bore you, the reader, with the fine details, but essentially Keycloak has built in support for many password hashing algorithms for safe storage and encryption of user data, but there is a legacy hashing algorithm that is still very common in some application architectures that lacks built in support with Keycloak. Thus, migration to Keycloak for these applications auth handling proves to be a tedious task. By building this feature, it would allow much simpler legacy app migration, so that is the possible feature I discussed in depth and am waiting to get eyes on.
In terms of issues too, our group is tackling larger code issues now. Ben and Albert are working on translation support for custom UI themes, while me and Jerry are working on making configuration of client session kill time more granular (essentially, we want the administrator to have greater control over which groups of users have longer or shorter session login persistence times.)
In terms of personal contributions, I have been getting some things merged and also have a couple more ideas for projects to contribute to, so I am quite excited that I am really getting into the swing of things overall.
]]>Over the past week, we have been assigned groups with which we were prompted to determine our policy for working with one another, while also determining what projects we would like to contribute to. We had a couple of ideas in mind ranging from low level projects like Cython, to libraries like Pandas or even a game engine in Godot, but what we ultimately decided on is an open source user management and authentication tool known as “Keycloak.” We believe this project will work as one of us is quite familiar with it to begin with, and there are multiple parts of the stack that we could contribute to, (all of which use technologies with which we are familiar.) I am really excited for this project because it looks like it will provide me an opportunity to learn more about writing security focused software, and those sort of techniques are something that I feel like has not been very present in my CS education thus far. In terms of my solo contributions, I think I will try to make some contributions to Cython and/or Pandas in my free time, as those are technologies that I may want to contribute to even after this class ends (beyond Keycloak itself.) Overall, my group seems very eager and we get along well, so I can’t wait to start getting into these things.
I’ve decided to start to delve more into solo contributions via something I am very familiar with: tech recruiting. I am very well versed in the professional sphere for technologists (especially for an underclassman,) so I decided to use that subject matter knowledge to contribute an underclassmen focused externship opportunity I was aware of to a repo that did not have it already. I love using resources like these to find opportunities to develop myself professionally in the field of tech, so I decided it just makes sense to give back to that same vein of resources in a way. Hoping that it gets merged soon :)
(note: at the time of creating this blog, there was no requirements for its parameters uploaded on the wiki.)
]]>I think this is the thing I am looking forward to the most in this class. All of our discussions around different topics regarding open source software will finally face praxis, and I am eager to feel the direct learning outcomes in my group. I am hoping we can contribute to a project that is used by other developers, because I gain great pride in creating tools that people actually gain utility out of (as characterized by my personal projects.) I know that I can contribute a good source of organization and leadership regarding how we actually go about collaborating with our group contributions, as I have a lot of experience with guiding those sorts of things. I also hope to be able to improve and also apply my immediate technical knowledge that I have been building both in my studies and my own free time to our project.
Of the few small open source contributions that I have made, I still think my most proud is from our own open source projects that we build in a group, specifically when I updated some technical functionality of our web extension. Beyond that, I have fixed some typos and formatting on the project evaluation template on the course website to increase the quality for other students. However, one thing that I have noted is that I have been very fearful of contributing to larger projects because I worry that I don’t know enough/will be berated for making a “stupid suggestion.”
This is a bit personal, but I guess this fear actually comes from when I was younger, around 14 years old. I was working on my own video game, and I encountered a bug in my movement script. At this point, I had made one game before, so I thought it was worth asking for help in a chat room that I joined specifically for the game engine I was using. Upon sharing my script, the two people that read my code started tearing into it, one of them asking if I “even understood what I was writing.” This ended up shaking me so deeply to my core that I dropped that project, and I still think about it whenever I share my software with people.
I’m hoping that with the benefit of being in a group of students contributing to the same project, I will feel less afraid and alienated, and progressively build up the courage to contribute on my own. I know this sounds silly, but I really hope that this ends up being the case for me, since I just want to feel like I can add something to these projects in a way that matters.
]]>This week, we were tasked with creating and subsequently presenting our own open-source projects with a group of random partners. I had a great time collaborating with my project partner to develop our own extension that we could actually get real utility out of, but I don’t want to talk about us.
Rather, I want to talk about the extensions and presentations created by the rest of the class. In observing all of these presentations, one big thing that I recognized that even with very tight scopes, most of these projects always had emergent issues or new features that needed to be developed. What this shows is the true scale of open-source for larger projects, and it opened my eyes to the fact that all of these contributions are actually solving real issues, as opposed to just being made for the sake of it. I even saw this in our group’s project, in which the minimum viable product was quite small.
As for the presentations viewed in the Wednesday class, I was pretty interested in what had to be said by each of the speakers respectively. Ultimately, the two main points touched upon were the open source philosophy of building so that others could expand on your work, and the future of AI integration with open source projects, and why we need to tread carefully.
The topics themselves were interesting, but I think a decent portion of that can be attributed to the style of the presentations. I noticed that all three of them felt very conversational in nature, almost like a podcast at some points. Even though only two of the three had graphics, this conversational nature was enough to keep me actively engaged in all three. I think adapting this conversationality into my own lecture/presentation style could help with engagement of people in the crowd, as well as my nerves by making the environment feel lower stakes without being too casual. I’m interested in integrating this into my tactics in the future.
]]>I already had a decent amount of familiarity with version control, and Git more specifically before coming into this course, but I do think that the exercises still taught me some extra tidbits of useful information that I will most definitely use in the future (and in some cases have already started using.) Commands like git reset & git diff were ones that I was not aware of the use cases for, so those were quite interesting to see in action, and I look forward to becoming even more masterful at the technology as time goes on in this class.
The project that my group evaluated was exercism, which seemed interesting, but unfortunately seems like it would be difficult to interface with and contribute to. However, there are also projects like Godot and Cirq, that seem accessible all around and also hold a lot of my interest, being related to game development and quantum computing respectively. I really look forward to contributing to a project because I want to understand what the workflow is like for making contributions to tools used by thousands if not millions of people, and I am eager to finally have my work make an impact in some way shape or form. I think the biggest challenge for any project would probably be getting acclimated to the documentation so I could begin actually making meaningful contributions. The only way to really overcome this is with time and dedication, which I plan to exert to create meaningful software and supporting documents.
]]>Ultimately, we were paired with random people to continue to study how these projects are structured, before setting up our own. Overall, I thought this was a very productive and fun experience. Initially, we begun by writing a Firefox extension following the documentation tutorial so we could get a broad overview of what the development workflow would look like for our prospective project.
From there, we started to look at other open source projects for inspiration, while also familiarizing ourselves with how they were set up in order to maximize community engagement.
Finally, we ended up brainstorming our own idea for an open source extension, and decided to settle on a configurable tab dropdown application that can help with things like using chat apps, or conducting research without constantly jumping between tabs. We are still in the process of setting up the repository, but the prospect of the project excites me, and I am eager to witness how an open-source project functions from the perspective of an administrator.
Surprisingly enough, we didn’t face many challenges on the front of collaboration itself, I think the team member I worked with so far have a style of work and communication that melds together very well which allows great efficiency in our work. The only issue was one of our team members not showing up, but I am confident that once we are all familiarized with one another then there shouldn’t be any glaring conflicts to grapple with (at least immediately.)
]]>Starting with an open source software as robust as go, we can see the code of conduct not necessarily being overtly explicit on the types of contributions that are allowed. Rather, a heavy emphasis is placed on the social etiquette of contributors. A likely purpose for this is to minimize a baseline level of alienation within any community surrounding any given open source software, and in retrospect, this makes a lot of sense. If you scare away new contributors with your culture, then your technology is less likely to have newfound ideas brought upon it, and thus its quality will eventually stagnate (which is the exact opposite of what is trying to be achieved with open source.)
Continuing to look further into Go’s code of conduct, we can find that it has actually been adapted from the contributer covenant base code of conduct document, with the primary change that the “enforcement” section has been altered to “conflict resolution,” likely to convey a less punishing tone regarding community guideline infractions.
Eclipse has also adapted from this code of conduct, but it primarily differs from Go’s on the basis of having more restrictions on contributor behavior, even going so far as to include the aforementioned enforcement section as opposed to altering it in the case of go. My hypothesis is that this difference likely arose through the difference in management and development of the companies that founded these open source technologies (Google and IBM respectively,) and this dichotomy of culture leads to a slightly different set of values being enforced, even if there is similarity.
This can be seen further with the Sugar Labs code of conduct, which follows a template completely unique to the previously mentioned one, as it is based off of the Ubuntu code of conduct. The main overarching difference with this code of conduct is that respectfulness is left a lot more to the fair judgement of the contributor, as opposed to the previous codes, which have some explicit examples of what is not at all tolerated.
Looking at another open source project from Google in Cirq, we find that the code of conduct is actually identical to Go’s code of conduct, further reinforcing the fact that codes founded by different people and organizations are quite likely to have variance primarily based on the founders values. Thus, there is actually no necessity to alter Cirq’s code of conduct from Go’s, as the same moral principles and social etiquette holds.
Prior to this activity I had never really thought of open source software doubling as a community as well and needing guidelines for behavior by extension, but in retrospect it makes a lot of sense. I hope to come back with more insights to the nature of these technologies as I progress through this course.
This talk was also interesting to me, further bringing attention to the community management and social aspect of open source development that is crucial for the success of any project of this nature. Essentially, the talk focused on three main points that I was able to derive: Clarity, Management, and Mentorship.
First, I will start with clarity. The speakers from the linux foundation emphasize the importance of defining a “North Star” for a project, a common, clear goal that the technology being developed aims to work towards. Combined with this north star, there is also emphasis on the clarity of documentation and communication for which people hold what roles and what that entails. Ensuring that everybody is clear on what work needs to be done is not only conducive, but crucial to success for any open source project.
Next is management. Management isn’t necessarily framed from a perspective of absolute authority by the speakers, but rather as facilitation of community behaviors. Conflict resolution, meritocratically charged decisions, and rough consensus are all tools that open source pioneers need to be well equipped with to ensure communities stay both efficient, and in check from a behavioral standpoint. Debate should be allowed, but project derailment needs to be prevented.
Finally is mentorship. Without mentorship, many projects are doomed to fail, as over time they will only become more and more inherently complex as contributions begin to pile up. In absence of proper onboarding and mentorship of aspiring fresh contributors, projects will slowly become dormant as the engineers experienced enough to do something with it begin to move away, and those who are not struggle to grapple with what is already left for them to deal with. Proper mentorship facilitates community engagement and iterative idea generation, so this is the last main pillar that I was able to derive from this talk that is very important to have in an open source community.
Ultimately, soft skills while especially overlooked in a field as meritocratic as technology, is very important in order to facilitate consensus and harmony within any open source community.
]]>It’s a term that practically every technologist has heard, but upon being asked what it is, there tends to be a large margin of variance in their answers.
When I hear the term “open-source,” the proper definition that comes to mind is software that is open to the public to be modified and distributed under the bounds of some given license.
However, what I feel is the possibility for innovation and freedom, by allowing the masses to contribute to the augmentation of each technology that they use on a day to day respectively.
The main draws of open-source technology in my opinion are the following:
However, it also has some drawbacks:
Regardless, I think that the pros greatly outweigh the cons in why you should start using it, but ultimately these things come with the nuance of case-by-case bases.
I alongside many personally find open source software to be my main method of creation. Not only directly through coding languages, but through the libraries on top of them as well.
Some of the following that I use/have used are:
There is a lot more to be said about software of this nature, but I am looking forward to get my hands dirty with it more rigorously over the course of my open-source class, which prompted this blog to begin with.
]]>