I think that this course sort of met my expectations. I wish that we had started covering Linux and Bash earlier. I also would have liked to start my “big” conribution earlier. In terms of my dreams, they were lofty, and I knew that, but I think I met or exceeded my own expectations for contributing. I don’t think I truly believed that I would be able to even build a project, and so that I was able to find one, and contribute something that was almost code, is exciting to me. So I don’t want to say I would change my asnwers, because I still maintain lofty dreams, but I know that I still have a lot of work left to do. :)

It is strange to have finally reached this blog post, as it’s been sitting in the repo for a while. In class, we had a quiz, which I did not do so hot on. Other than that we mostly covered Linux commands, and spoke about how open-source can be a business, though I still have unanswered questions, of course :)

I completed this issue. Here is my pull request. In older versions of git, it is not possible to perform a shallow clone. The build files in osquery required the ability to do this, and so would crash with older versions of git. The maintainers noticed this, and requested that perhaps it should be possible to fall back on reguler, deep clones in the case where a user had an older version of git. That is what I worked on implementing. Initially I ran into errors which I thought I recognized, but they were, in fact, the very error that I was trying to fix. I made my fix and oepned a pull request, and I was asked to change the root directory of the build. I did this, and again ran into errors. I hopped onto slack with one of the maintainers, who realized this was happening and said that the new change required more fixes, which perhaps should be opened as a separate issue. Then my PR got merged!!

My issue got jacked, so I found a new one, and this time it was assigned to me. Seems like an easier issue anyway so we’ll see what happens. I’ve been working on it, and building the project takes a ton of time, which is unfortunate haha. I think it’s mostly because of all the cloning. That’s probably the most challenging part, though there’s also the aspect of trying to install an older version of git in order to properly test this.

This week we went over our projects, and then we went over bash. I knew most of the stuff we went over.

In class:

We did a fairly long exercise about fetching, merging, branching, and rebasing. We used a GUI tool to visualize the effects these commands actually had on the repository in terms of branches. I will explain briefly the difference between a merge and a rebase, as I’ve understood it. A rebase onto a branch takes your commit history, a rewrites it atop the branch. You can also use a rebase (especially an interactive one) to squash commits. This all generally results in a cleaner history, as there are no merge commits. A merge attempts to combine all of the changes automatically, and if it cannot then the user can manually fix the conflicts. Then a merge commit is left atop the branch. This results in a slightly “dirtier” history, as there are merge commits when master is merged into another branch, and then another one when the other branch is merged into master. One must never rebase on a public branch, because it is hard to undo and hard for other people to combine with their code later.

In class:

On Thursday in class Bill Reyner came to speak. It was very interesting to hear about open source from the perspective of the private sector. It seems that many companies contribute to open-source projects. Sometimes they do it just to give back to the community, or to recruit, or because a project they worked on might be maintained by the community, or to band together agains a competitor. Of course, almost all of these are within the scope of helping themselves, but I guess the private sector has to thrive on something :) I missed class on Monday unfortunately, do to a Jewish holiday. (Shemini Atzeret in the US).

In class:

On Thursday in class we did an activity where we had to explore an open source repository. Marco and I explored empathy and found that it was not very active. On Wednesday in class I looked through many repositories, and found osquery which is pretty active and I am tending towards contributing to.

In class:

On Thursday in class Karen Sandler came to speak to us about licensing. She answered many of our questions, stressed the importance of open source code, but also raised a lot of issues in my mind, such as what might incentivize companies to make their code open source. On Monday in class, we spoke about IRC and set up a class chatroom.

On Thursday in class we all practiced collaborating on a git repository in groups of 3. We created issues and opened pull requests, as per the guide posted. I updated my contributions file with a few contributions that got approved. I posted a question to ask Karen Sandler. I read the article found here. I think the reading was pretty good, and really helps make contributing more approachable. I am curious as to what exactly a “casual” contribution is, but it’s good that more than a fourth of “casual” contributions are just documentation, formatting, or translations. That gives me hope, maybe I can already consider myself a “casual” contributor and more contributions lie in my future :D

On Thursday in class we all practiced collaborating on a git repository in groups of 4. Several conflicts (both merge conflicts and other types of conflicts), arose throughout the process. On Monday we were taught a standard good git workflow. CLone from the remote repository. Create a remote fork. Make changes. Push them to your remote fork. Create a pull request from your fork to the upstream project. Merge the pull request upstream. Pull the upstream changes to your local clone. Rinse repeat. I opened an issue on someone else’s blog, and then just hit the edit button on GitHub, which created a fork of the repository under my username. Then once I made a commit, a branch was automatically created on my fork. I opened up a pull request from that branch on my fork to the original repository. I did not need to create a local copy on my machine at all. I also didn’t need to worry about merge requests, as the project is very small comparatively.

I thought that the article was pretty repetitive, though some parts were interesting. It kept stressing that open-source doesn’t require technical know-how, which I think is obvious to those with technical know-how. But the term “open-source” doesn’t really enter the lexicon of laypeople, and so it is an intimidating term. I wasn’t sure about open-source business models, and after reading that article, it sounds pretty strange. In some ways, I don’t like that. The RHEL model is not ideal. Charging people to be part of a community I feel like goes against open-source philosophy. And making parts of your code proprietary and selling them also seems to go against the philosophy. I think open-source developers should make money, and I may change the way I feel about the things I’ve said above, but there must be some better way to do this.

Licenses sound confusing, and I’m sure they are, but they don’t come into play most of the time as far as I know. Though it’s useful to know on the off-chance that some lawsuit or something comes up. It’s also definitely useful to be aware of the resources available so that I can just use them whenever.

I am taking this course because I have been, for a while, interested in contributing to open-source projects but I have found it difficult to do so. I am hoping that through the guidance of the class I will be able to make a significant contribution to a projecct.