CSCI-UA 480 Student, Spring 2024
I have to say I’m extremely content with our presentation. Being the first team to present freed me of some anxiety I would’ve had had we presented later. In my previous post, I mentioned that I believe we prepared well and our slidedeck was solid. In the end, I think we were able to organzie our ideas well and our information was concise. We may have not had the best visual presentation but that probably wasn’t any of our strengths to begin with.
This week has been a rough one it terms of contributing output to Bitwarden. Over the past two week we’ve been working on a bigger documentation change that we believed we could take the intiative on. I had submitted an issue just to communicate that it was something we as a team were interested in doing. Unfortunately, the devs got back to us basically as we were ready to submit a pr. They informed us that the technology wasn’t deprecated but in fact was something they were planning to push in place of the old one– they had jumped the gun without informing the community. Since that was our last big push to submit another contribution it was unfortunate that our efforts to contribute before the presentations ended on a sad note.
Knowing my own nature, if I were a software developer in the 80s and early 90s I would’ve certainly subscribed to the Cathedral approach. The thought of meticulously approaching a problem and creating bug-free, efficient, near-perfect code (while in practice impossible) is far more inticing than releasing early and often. Yet as Raymond puts it, upon further inspection the Bazaar style works, and most importanly, for a reason. Gathering an army of self-selected and self-motivated developers where bug finders and bug fixers intersect inevitably gets things done. In other words and as Raymond said: “Debugging is Parallelizable”. I enjoyed being able to talk about the effects of Linus’s at the time new approach to software development and it was interesting to hear from my peers their unique perspectives and intersts. It reminded me all the more that everyone has a unique skillset that’s ready to match a problem.
Christopher’s presentation, once we finally had things setup, was genuinely engaging and interesting. I really enjoyed his presentation on Tidepool, and their unique approach to Open Source software. Due to the nature of their product, they are not and cannot be open to contributions from the greater community. Christopher did a great job explaining how Tidepool’s software is mostly a function of a forked repo and software made internally that has been vetted by the FDA.
I know it’s fairly obvious to say that dealing with diabetes is extremely tough. However, I don’t think the average person can truly conceptualize how difficult it really is. My little sister was diagnosed with type 1 diabetes after suffering from intese pain. When her condition first started to show symptoms and was rushed to the hospital, the doctors had done their best to normalize her blood sugar levels. Unfortunately, her body had grown accustomed to operating at a high blood sugar level and, having been lowered too quickly, induced a seizure lasting several minutes. Learning how to deal with her condition as a family has been complicated and difficult.
In an effort to contribute something to Bitwarden this week while I understand the code base, I combed the issue page for some low hanging problems I could attempt to solve. In my search, I found that users would often post problems that had more to do with poor direction following/poor local installations than the code base itself. One user I encountered had tried to install the Bitwarden-CLI using Homebrew, ignoring the devs instructions to install using npm.
My group and I decided that we wanted to contribute to Bitwarden. The community is extremely friendly and they respond to issues and pull requests incredibly fast too. The repo is sort of complex but we all have relative experience with the languages that they use so learning curve isn’t that steep. In their contributing docs, they have a useful repo architecure guide that walks contributors through the basic structure. So far, setting up the development environment and signing the contributor agreemeent has been relatively easy.
In my first blog post, I commented on how I was inspired by the founders, contributors, and maintainers of FOSS. To me, they were of course contentious and opionionated, but led arguably the most important software movement. Linux, GNU, OpenCV, Pytorch, Tensorflow, etc. have completely shaped software as we know it today– something closed-source may have never been able to achieve.
Picking a project has been quite the endeavor. It’s difficult to find something that has open, beginner-friendly issues and is active enough for our class. I had been truly excited at the prosepct to contirbuting to Pytorch, Godot, and Zed, but I severely lack the skills to contribubte to their newbie-labeled tagged issues. OpenMl uses a stack I have a lot of experience in, but rarely sees any updates or discussion. I’ve looked at many more and they tend to fall along these lines.
So far, it’s been a daunting task to find an Open Source project that I both want and have the ability to contribute to. I’ve spent a significant amount of time combing through the issues tabs of various Open Source projects to find a beginner-friendly contribution I can make. The projects I mainly wanted to contribute to include Godot, Pandas, Matplotlib, and Zed. Fortunately, Pandas and Matplotlib had a few issues that were accessible and tagged as beginner-friendly that I believe I can work on promptly. However for the vast majority of Open Source projects, the urgent issues require knowledge of the repo that takes time and dedication to understand. This comes as no surprise to anyone but nonetheless I needed to make any sort of contribution quickly.
This week my team completed and presented our web extension WebPad. Truthfully, I thought our group worked fairly well together, as we all completed our work without any real need to constantly follow-up or push for timely delivery. We were all able to divide the work needed to be done seamlessly and simply complete it. For the most part, I ended up doing most of Part 3 and 4 with some input and quality assurance before pushing it to the Course Wiki. For me this was fairly straight-forward, and I was glad to get the busy work out of the way.
This week’s Git exercise was a nice refresher on some basic Git functions I’ve lazily let the VScode GUI handle for some time now. I suppose the exercise revealed I’m by no means a Git pro. However, after some debugging concerning merge conflicts I was able to finish the exercise in a reasonable amount of time. Being able to work it out together in a group added another layer of fun too. I usually program alone so working through the problem together was pretty refreshing.
On a personal level, I do believe it’s important to establish a Code of Conduct. A Code of Conduct is necessary in order to lay out the rules. More importantly, it serves as a way to make collaboration kinder. Software developers are, for better or worse, extremely opinionated. This often leads to extremely defensive and passive-aggressive behavior that can be antithetical to collaboration, improvement, and growth. Among projects that care about minimizing or eliminating this sort of behavior, the Code of Conduct serves as a concrete agreement community members can point towards when they want to punish this or any brand of disagreeable behavior. I doubt every developer reads the Code of Conduct before contributing to an Open Source project. However, I view the Code of Conduct like a car manual. While everyone should probably read it, when something goes wrong (in this case behavior wise) it’s the first thing you look at when you want to learn how to fix it.
Ironically, whenever I’ve thought about Open Source Development I’ve always had this sense that it’s inaccessible. Mind you, that could be my irrational fear. However, it’s hard not to think about Open Source Development as being comprised of highly motivated, monolithic developers who create projects that make the world go round. I think using this description, Linus Torvalds and Linux come to mind as well as GNU. To me, it’s hard not be intimidated by these projects, and the community of developers that maintain them. Linus is notorious for being blunt and “mean” and I think some of that attitude has been influential, especially on forums like StackOverflow (the acronym RTFM comes to mind). Nevertheless, it’s difficult not to encounter and/or use projects created by the Open Source community. Two of my main tools that I use for my web development projects are Flask and MongoDB, both completely Open Source.