Reflection: "The Cathedral and the Bazaar"

Our assignment for the first of February was the read The Cathedral and the Bazaar by Eric Steven Raymond.  For those of you who have never heard of this essay, it's about closed versus open-source software and Raymond's journey through the creation of an open-source project called Fetchmail.


First off, I would like to say that I really enjoyed reading this essay.  The way it was written seems quite similar to what Dr. Bowring is asking us to do for this class, which is to write this blog and use it to publish our experiences during the semester.  If you read it online as I did, you can see a revision history for the essay (the last revision was done 11 years ago).  I liked being able to see that because it shows that Raymond really did go through the development process.  He didn't simply publish an essay and leave it alone.  He went back, maybe cleaned it up a bit, added to it--not unlike what programmers do with coding in open-source projects.


In the essay, Raymond gives 19 rules or lessons that he learned along the way about developing open-source projects.  Since there are so many, I'm only going to share the ones that struck me the most (although you should go read the essay to find out about the rest).


1.  "Every good work of software starts by scratching a developer's personal itch."
Think about it.  Every little program, piece of software, application--all the popular ones anyway--are the result of a developer's personal itch.  Why are they so popular?  It's simple: the good works of software shows in the effort put into the coding.  When the program is something that you know will be beneficial to your needs (and then possibly the needs of others) you put more time and effort into what you're doing, and it shows.


5.  "When you lose interest in a program, your last duty is to hand it off to a competent successor."
This one seems like a no-brainer to me.  As a developer, even if you lose interest in a program you will still want to see it succeed.  After all, you helped bring it to life.  It's only natural to want to find someone capable of carrying on in your place.  If the next developer isn't competent the program dies.  Simple as that.


8.  "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone."
This rule was one Raymond dubbed "Linus's Law" after Linus Torvald, the software engineer who initiated the development of the open-source Linux kernel.  The author described it as follows:
"In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect. In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena—or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door."
Basically, Raymond says it has the Delphi Effect--"the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than the opinion of a single randomly-chosen one of the observers". This is also the principle behind Wikipedia and why it has thrived and grown in popularity.

January 23

Our group met earlier today. We discussed things we found on the XBMC wiki, forums, and IRC channel. We also talked about the possibility of changing our group name, but for now we're all okay with it. Oh! I just realized that I've completely forgotten to mention to you who's in the group. Sorry about that. The group members of Team Triple J are Jason Leonard, Matthew Vaveris, Jimmy Joy, David Schirduan, and myself. Anyway, the meeting didn't take too long. I think it's because we all did this last semester in CSCI 362 and know the ropes a bit better now when it comes to getting things going with the group project. With the exception of Jimmy and David, who worked together in a group last semester, we haven't worked together before. I like that. It's a way of preparing us for the real world. Let's face it, once we graduate and go off to work in this field, we probably won't be working with the same people on every project. Learning to work well with others is something we all need to learn at some point in our lives.


Anyway, the other task assigned to us was to set up Subversion and get used to doing that again. Now, for those of you out there who have never heard of or used Subversion before, I'll explain it for you. Subversion is a software that allows users to maintain and update current files. It's a repository actually. When you update the files in the repository on your computer, the file history is there in case anything goes wrong. It was very useful last year with keeping up with the files for the group project last semester. Well, it was useful once we all figured it out. It took my group a little while to get the hang of it the last time I used it. At the beginning of the group project we were using Google Groups to communicate and create our group progress reports. A week or two in to the project, we started using the Subversion repository more and realized how much easier it was to share our file that way. One of my friends in the class helped me set it up on my computer because I was having problems with it on my own. He walked me through the setup and showed me the features since he'd seen it before, so I felt comfortable using it once I started playing around with it. If any of you are considering using Subversion, I highly recommend it.

January 19

Each group presented their top three projects in class yesterday to see what everyone is interested in. Unlike last semester in CSCI 362, each group's top pick was different, so that made it easy for every group to choose their top pick as their project for the semester. My group's top choice was XBMC (Xbox Media Center) and we will be having another team meeting this Sunday to talk about it.


Our assignment to do before Friday's class is join an IRC channel for our project. We are to look at the history and listen to the traffic. In addition, we are to join an e-mail or newsgroup list and find an interesting thread to explore.


Now, for those of you following this blog and aren't sure what I'm talking about, don't worry. I'm just learning about this too. IRC stands for Internet Relay Chat. Basically, it's a way for multiple users to chat about a project over multiple channels. You use an IRC client program to be able to send messages to the others users. There is an online tutorial available at http://www.irchelp.org/irchelp/irctutorial.html if any of you are interested in checking it out on your own that tells you how to get started using IRCs. Another website that might be helpful is http://fedoraproject.org/wiki/How_to_communicate_using_IRC.


I tried to join the XBMC forum on their website and it wouldn't let me register. I tried twice and was rejected both times. It seems to think I'm a spammer. I'm not sure what the problem is, but I sent a message to the administrator to see if the problem can be resolved. Other than that minor headache, the forum is filled with a lot of interesting threads -- developments, feature suggestions, help and support, hardware. Almost every subject heading for the threads has a time stamp that shows it had activity today, and there is box at the bottom of the page that shows you how many users are currently active in the forums. It's really neat and I can't wait to get the chance to explore it further.

January 17

I finally got two of my textbooks (one of them is the book for this class) on Friday afternoon, and I am reading like crazy to catch up. The other members of my group met Saturday to discuss candidates for our group project this semester. I was unable to meet with them because I had a prior engagement that prevented me from attending the meeting.

When we met in class on the 13th, we came up with a list of attributes that we would like to find in a project. We came up with several, but the top two that we decided on were: no projects that use C or low-level languages (each member of the group has had problems with C in the past, and none of us want to use it again if we can avoid it); and find a project that has recently been updated and looked at by the the creators/user. The project that has really caught my eye is XBMC (Xbox Media Center). I like the versatility of it (it will run on Linux, OSX and Windows) and I think that will be useful when working on the project. It is widely used and  has a variety of functions.

Dr. Bowring also asked us to start looking at articles in computer science magazines that will be the focus of a blog post in the next few weeks. I chose an issue of IEEE Software and examined the table of contents to see what article would catch my eye. I have found one that seems very interesting, so I will be reading it later to decided whether or not this will be the article I will write about. 

And So It Begins....

I have never had a blog before, and I think that this will be a fun and interesting way to keep track of what I'm learning in Software Engineering Practicum (CSCI 462) this semester. I am a senior computer science major at the College of Charleston, and after taking the long and winding road to get this far, I am beginning to see the light at the end of the academic tunnel.

Yesterday we were randomly placed in groups of five, and I am a member of Team 3 (Team Triple J). We may be the third team, but we will not be taking home the bronze! Each group's progress  and experiences will be kept on the class Wiki (http://csci462-2012.wikispaces.com/).

For this course, we are asked to attend the Palmetto Open Source Software Conference (POSSCON) 2012. I just registered for this conference and am looking forward to attending.