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.

The Article

This article is rather long, and there’s a lot to unpack. But I understand exactly what the author is speaking about. This is the entire problem with open source, I think. It’s a really nontrivial problem to create, maintain, and protect open-source projects. Paying contributors is impossible, and most people need to work and make money in order to subsist, leaving projects that are “free” in a very difficult situation. Though the author proposes a few types of solutions, they require in-depth analysis, and each project would probably need to adopt these solutions in a different way. Obviously, it’s also much harder for a samll (but useful) project to do, and so the larger projects control more of the market of contributors, so to speak.

I’ll summarize a bit more on this article. A lot of it is talking about Makers vs. Takers. Makers help contribute to a project, and Takers have the ability to do so, but do not. Often, Takers affect the open-source market negatively, because while Makers invest money and time into open-source, the Takers will invest that same amount of money into IP, and therefore gain a competitive advantage over the Makers, which will be detrimental to the open-source projects that the Makers contribute to, as the Makers lose money or are required to invest in IP to keep up.