Thoughts on Open Source

Explain (in your own words) the difference between software development following the cathedral model and software development following the bazaar model; which of the two environments do you personally prefer

The cathedral model of software development is one where there is only a main group of people in charge of building the entire project.

On the other hand, the bazaar model of software development is a more open style that allows input from all sorts of people. Users are free to go in and take a look at whatever is going on in the codebase.

While I personally prefer the bazaar model of software development, I am most familiar with the cathedral style. It feels much easier to organize and keep track of. However, I can see all the potential benefits of the bazaar model and hope to get used to working in that sort of environment.

The Cathedral and The Bazaar essay has 19 “lessons”. Pick two of these that you find to be the most intriguing, interesting, telling, or ones that you simply liked. Quote them in your blog and try to explain what they’re supposed to mean.

Every good work of software starts by scratching a developer’s personal itch.

I found this lesson to be interesting because good software is one that fully solves the intended purpose. If a developer has a personal interest that they are creating software for, then they should know the ins and outs of that issue. They’ll know exactly what users are looking for, and where to push back on unnecessary features.

Good programmers know what to write. Great ones know what to rewrite (and reuse).

I picked this quote because I’ve learned about the perils of wanting to rewrite old code the hard way. Many naive programmers (including me) see an old piece of code that can seemingly be condensed into a much shorter version and itch to make the change. The thing is, that old code has stood the test of time. There might have been years of changes and bugfixes that are unknown to you. Things may have been written some sort of convoluted way because they needed to be, not because the previous developers were incompetent. By needlessly rewriting old code, it is very easy to fall into trouble.

Comment on the discussion of free vs. open, in what way are they similar and how are they different?

While free and open source software are often thought of the same thing, there are a few differences between the two. Free software is a smaller subset with all open source sofware. Free means that users have “the freedom to run it, to study and change it, and to redistribute copies with or without changes” (Stallman).

While most open source software is also considered free software, there are a few exceptions. In the case where licenses prohibit the private use of a modified version of open source software or have weak licenses without copyleft, there are restrictions placed on the user. Some products are also delivered with tivoized software that bar users from running modified versions of it.

Previously, I didn’t know about this distinction between the two terms. But after reading Stallman’s account on it, I understand and agree with it. Keeping these two separate is very important to foster the growth of truly free software. I like how the new version of the GNU license looks to adress the tivoization issue.

Personal Progress Towards Team Project

This week we’re still familiarizing ourselves with the codebase and seeing what sorts of issues we can tackle. I created a Google spreadsheet to organize different issues we might be able to work on. Most of the week consisted of playing around with a few issues and getting a few development kinks out of the way. All the changes I made would disappear whenever we ran Caprine. I realized that this was because Electron prioritizes the downloaded version over our local copy. Uninstalling Caprine and only running it locally through npm fixed that problem.

I learned more about Electron during this time and how exactly Caprine worked. I realized it was essentially just a mini browser that only ran messenger.com. This made things a lot more simpler because I realized that all the calls were made by Facebook itself, and that Caprine was nothing more than a window to view messenger.com. The entire codebase was just a collection of additional features for convenience or aesthetics.

Next week I hope to start with some actual contributions, whether that means adding documentation, commenting on issues, or submitting real code. The spreadsheet our group has been working on will definitely help in that regards.