Day Twenty One: Reflection and Review

Our current assignment is to read two articles from opensource.com and blog our response to these articles.

Sebastian Dziallas' article, How to Teach Undergrads How to Become Open Source Contributors Without Writing Any Code, caught my attention because it involves a different approach to teaching open source. As a computer science major, it makes sense to include coding as part of the core open source experience in a software engineering class; however, not all contributors to open source projects are programmers. Chapter 8 in Teaching Open Source describes the importance of documentation and technical writing. There are many opportunities to contribute to these vibrant open source communities outside of the realm of coding, but it seems as though very few classes offer a glimpse into this alternate perspective.

Dziallas' Release Engineering course started as somewhat of an experiment, and it developed into a highly educational experience. From his descriptions, projects went better than expected, and students were given the chance to see Tom Callaway, the Fedora Engineering Manager, talk in person about some of the same issues that Dziallas mentioned in class. I would like to see more opportunities for people to branch out and explore the world of open source. Dziallas mentions that he has been working with Fedora since he was 16. I am only beginning my adventure at the age of 21, but I am glad to have this opportunity.


Another article that sparked my interest is Anthony Biller's A Cure for the Common Troll. I mentioned much earlier in my blog that I read tech-blogs, such as engadget and gizmodo, on a daily basis. I have not seen as much mention of it lately, but, for a while, lawsuits concerning patent infringements dominated the headlines. Samsung and Apple battled it out constantly over, what is in my opinion, trivial matters. The authors of these posts and many of the readers pointed out that this incessant bickering is a common marketing scheme to help fill the coffers when business is slow.

The trolls that Biller mentions go above and beyond the previously mentioned form of trolling. "Patent trolls," as he calls them, hold patents to technologies and manufacturing processes that they will probably never use. Some trolls make six to seven digit figures based on abusing the patent system alone. Apple has been known to patent anything and everything that they can, but the real patent trolls have no real plans with these patents other than threatening other companies and making an absurd amount of money in the process. I am not a big legal buff and do not understand all of Biller's suggested solutions, but his first solution seems to plug a major loophole in the patent system. Without vague "umbrella" patents that cover every possible domain, patent trolls would have a much harder time abusing the system.

Day Twenty: An Update on our Group Progress

My group met at our usual time and place on Sunday to discuss our accomplishments and decide what to work on over spring break. Matt Vaveris and I decided to focus on bug #12653. This bug involves an Xbox 360 controller, and we both have access to such a controller. Julie will focus on bug #12594 because her laptop has a built-in Blu-Ray drive. David is looking into bug #12699 because the bug report itself is difficult to read. If the broken English cannot be deciphered, the report is useless and needs to be deleted. Jason was not able to attend the meeting, but he can work with David or Julie depending on the level of progress that is made respectively.

I was able to reproduce my bug on two different systems running Windows 7 with the latest updates. My laptop, running XBMC Eden Beta 2, experienced a crash exactly as the reporter described. Here are the steps to recreate:

1. Plug in the controller and make sure that it is on (you need the appropriate drivers for Windows to recognize it).
2. Start XBMC
3. Unplug the controller and Alt+Tab out of XBMC
4. Wait 3-4 minutes
5. Bring focus back to XBMC

I tried this process again on my desktop PC, running XBMC Dharma, with a wireless Xbox 360 controller, and I experienced the same crash. I want to contribute to this bug report with my findings, but the webmaster for the XBMC forums must not be receiving my messages for some reason. The forums still mark me as a spammer, regardless of my email address (I have tried yahoo and multiple gmail accounts). Luckily, Matt has a username, so he can do the talking for us. It is surprising that a bug like this has persisted through Dharma and three beta builds.

Day Nineteen: Explaining the Code

Chapter 8 in the Teaching Open Source textbook is all about documentation. The information in this chapter is easy enough for a newcomer to understand, and it acts as a refresher for more experienced individuals.

Exercise 8.1.1: Practice Good Code Commenting
My team's first contribution to XBMC is an updated readme file with information that was simply left out and referenced in the forums. This is exactly the kind of thing that chapter 8 talks about. The information is there somewhere, but it is rarely easy to find. A well documented project simply takes all of the sources (mailing lists, IRC discussions, and wiki pages) and makes them readable and easily accessible. Open source projects are more approachable if they document this information for new and old users/developers alike.

Exercise 8.4: Plan Your Technical Document
The Nexus Mod Manager (NMM) that I mentioned in a much earlier blog post finally has some documentation in the form of a wiki page here. I still use NMM to this day for all of my Skyrim mods. Steam's workshop seems like a decent alternative, but I still feel attached to the nexus community. My plan was to add a wiki page that documents how to add non-NMM mods, but it appears that another user meatwad2021 already has this idea in mind. Under the "discussion" part of the wiki, meatwad has this to say:

"Considering the chaos that has ensued with Nebula's Skyrim HD 1.5 pack conversion from loose file style to the .bsa/.esp packaging, I've been creating a few new pages dealing with 7zip and SKSE. The next step is to teach users how to deal with files not offered with the Download with Manager option as is required for Nebula's 1.7Gb update. Sooooo, I'm going to take a crack at addding that section here to the existing page."

This update was posted on the 25th, so I might try to contact him and see if he would like some help. Even though my group chose XBMC as our FOSS project, I would still like to contribute to the Nexus community in some way.

Day Eighteen: RMH Homebase Continued

After wasting countless hours on a virtual machine running Ubuntu 10.04 and another virtual machine running Ubuntu 11.10, I finally got RMH Homebase to work on the 11.10 virtual machine. A fellow classmate of mine posted an install guide to his blog here. Although I followed very similar steps during my own installation attempts, his guide corrected whatever I was doing wrong.

The assignment for today is exercise 5.7 and 5.8 in the Software Development book.

Exercise 5.7: Debugging
As the book mentions, there are two places in RMH Homebase that display a shift's "notes" field for editing, calendar.php and calendarFam.php. Both of these modules include calendar.inc, so refactoring this "bad smell" should be as simple as adding a function to that file and replacing the old code with a function call. I added the following function to calendar.inc:


function predates($a, $b) {
return ($a->get_year()<$b->get_year() || ($a->get_year()==$b->get_year() && $a->get_day_of_year()<$b->get_day_of_year());
}

This function will return true if a's year is less than b's year or, in the case where both a and b are during the same year, a's day of the year is less than b's day of the year. In other words, this function returns true if a predates b. Unfortunately, the test file"testCalendar.php" is not present in my tests folder. I will have to hold off on unit testing until I can find a copy of this file or make a file of my own.

Exercise 5.8: Examining the Code
A. Sub Call Lists (SCLs) are viewed and edited through functions included in the module subCallList.php. In editShift.php, either "View Sub Call List" or"Generate Sub Call List" is displayed depending on whether the shift has an associated SCL or not. Here is the code:


if(!$shift->has_sub_call_list() || !(select_dbSCL($shift->get_id()) instanceof SCL)) {
echo "<input type=\"hidden\" name=\"_submit_generate_scl\" value=\"1\"><br>
<input type=\"submit\" value=\"Generate Sub Call List\" name=\"submit\"style=\"width: 250px\">";
}
else {
echo "<input type=\"hidden\" name=\"_submit_view_scl\" value=\"1\"><br>
<input type=\"submit\" value=\"View Sub Call List\" name=\"submit\" style=\"width: 250px\">";
}

As you can see from the if-else statement, not every shift has a sub call list.

B. Archived weeks are weeks that are set to the status "archived". The status can be set using the function set_status($s) to "unpublished," "published," or "archived." Calendar.php includes a statement that does not allow archived weeks to be edited by anyone. I cannot find any modules that call set_status($s). I only see if statements that check to see whether a week is archived in order to hide it from view.

Day Seventeen: Group Planning

My group met at our usual time last Sunday and made a general outline of our schedule for the rest of the semester. I created and shared a Google calendar with every group member, so it is easy for any of us to edit any important events. We hope to address four additional bugs over the course of the semester and save a week or two for preparing a poster and the final presentation. A link to our schedule can be found here.

Back to RMH Homebase
I tried to get RMH Homebase running on my Ubuntu 10.04 virtual machine, but I am having difficulties with the MySQL server. Apache seems to be working fine, and PHP5 is pretty straight forward. I am not certain that MySQL is where my install fails, but it is the most likely cullprit. I will walk through the steps I took to install for reference. A link to the most helpful webpage that I found is here.

Download RMHHomebase 1.5 from the sourceforge page

Install tasksel and then the LAMP stack

$ sudo apt-get install tasksel

$ sudo tasksel install lamp-server

Set MySQL root password
$ mysql -u root

At the mysql console type:
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('yourpassword');
mysql> CREATE DATABASE rmh15DB;
mysql> GRANT ALL PRIVILEGES ON *.* TO 'yourusername'@'localhost' IDENTIFIED BY 'yourpassword' WITH GRANT OPTION;
mysql> \q


Install phpMyAdmin

$ sudo apt-get install phpmyadmin

$ sudo nano /etc/apache2/apache2.conf

note: add "Include /etc/phpmyadmin/apache.conf" to apache2.conf

Follow the directions in README1.5.pdf

Day Sixteen: Bad Smells

Exercises 5.1-5.3 in Software Development: An Open Source Approach involve finding and fixing various "bad smells" in the example software, RMH Homebase. As with most open source exercises, the first step is to download the source code. Install Mercurial and checkout RMH Homebases' repository on sourceforge.

$ sudo apt-get install mercurial
$ hg clone http://rmhhomebase.hg.sourceforge.net:8000/hgroot/rmhhomebase/rmhhomebase

Find and fix the "Bad Smells"

Long Method: A method should do one thing and only one thing. addWeek.php violates this rule of thumb  by accepting various parameters, such as publish, reset, and remove in order to change the main function's actions.

if($_GET['publish'] && $_SESSION['access_level']>=2) { $id=$_GET['publish']; $week=get_dbWeeks($id); if ($week->get_status() == "unpublished") $week->set_status("published"); else if ($week->get_status() == "published") $week->set_status("unpublished"); update_dbWeeks($week); add_log_entry(''.$_SESSION['f_name'].' '.$_SESSION['l_name'].' ' . $week->get_status().' the week of get_id().'&edit=true\">'.$week->get_name().'.'); echo"
Week \"".$week->get_name()."\" " . $week->get_status() . ".
Back"; } // resets a week if the user is a manager else if($_GET['reset'] && $_SESSION['access_level']>=2) { $id=$_GET['reset']; $week=get_dbWeeks($id); delete_dbWeeks($week); add_log_entry(''.$_SESSION['f_name'].' '.$_SESSION['l_name'].' reset the week of get_id().'&edit=true\">'.$week->get_name().'.'); generate_populate_and_save_new_week(substr($id,0,2),substr($id,3,2),substr($id,6,2), $week->get_weekday_group(),$week->get_weekend_group(), $week->get_family_room_group()); echo "
Week \"".$week->get_name()."\" reset.
Back"; } else if ($_GET['remove'] && $_SESSION['access_level']>=2) { $id=$_GET['remove']; $week=get_dbWeeks($id); if ($week->get_status()=="unpublished" || $week->get_status()=="archived") { delete_dbWeeks($week); add_log_entry(''.$_SESSION['f_name'].' '.$_SESSION['l_name'].' removed the week of get_id().'&edit=true\">'.$week->get_name().'.'); echo "
Week \"".$week->get_name()."\" removed.
Back"; } else echo "
Week \"".$week->get_name()."\" is published, so it cannot be removed.
Back"; }


This code tries to do three different actions in one function. The easiest fix is to separate these actions into their own functions. The goal is to have high cohesion.

Too Few Comments: Having looked through most of the code, it is safe for me to say that this software has too few comments overall. Some files, such as personEdit.php, have a decent number of comments. The comments do a good job explaining "why" instead of "how" something is done.  A pair of fresh eyes can look at personEdit.php and get a sense of what is happening and why is it important. In my Operating Systems class, students are encouraged to comment all but the most obvious lines of code. An instance variable "counter," when used with a loop, is obviously a counter. Commenting every line would classify as too many comments, and this is also a "bad smell." personEdit.php finds a point in the middle of both extremes.

Other files, such as editMasterSchedule.php, only have a few comments for hundreds of lines of code. Maintenance accounts for a large percentage of a software's life cycle; therefore, good documentation is necessary in order to reduce maintenance  costs and avoid future hassles. The function get_day_names() in editMasterSchedule.php is a simple example of too few comments. Monday through Friday are determined through a very similar process via if statements, but Saturday introduces a substring method that is not used for any other day of the week. Why? If there is something intrinsically different about Saturday that requires it to be handled differently than a weekday, a comment should reflect that. Given a few months, it is difficult to forget even your own code. Comments increase readability and reduce maintenance costs. It might take a few extra seconds to type a comment, but the benefits are well worth this extra coding time.

Data Clumps: A data clump occurs when several variables consistently appear together. The only data clump that I can find in this code is related to the date. Month, day, and year are kept together in a date object, but the string name and three character abbreviation are also used to identify days. The function get_day_names in editMasterSchedule.php assigns these string identifiers manually, but this could easily be done in a custom date object.

Speculative Generality: Speculative generality is defined as "inserting features into the code for functionality that is not part of the current requirements." Having looked over chapter 5, appendix A, and RMH Homebase's source code, I have not noticed any included features that are not part of the requirements.

Day Fifteen: Software Architecture

Chapter 4 in our textbook, Software Development An Open Source Approach, reintroduces many themes and ideas that were previously mentioned in several earlier computer science courses. The recurrence of this information suggests that it is vital to good software engineering practices. For this blog post, I will provide a brief outline of chapter 4, mainly for my benefit, but also for the benefit of others.

4.1  Architectural Patterns

• Multi-Tier pattern: "GUI components are isolated within the user interface layer and database interactions are isolated within the database layer."
• Client-Server pattern: "separates the functionality of a typical user of the system from that of the server that hosts the database that all users access."
• Transaction Processing pattern: "useful for systems that accept a stream of transactions and process each transaction fully before moving on to the next." ex. ATM
• Model-View-Controller (MVC) pattern: "separate the functionality (the model) that underlies the user interface form the code that controls how the user sees (the view) and interacts with (the controller) the system."

4.2  Layers, Cohesion, and Coupling

• The Layering Principle: "each component appears in a single layer; the user sits at the top layer and the database is at the bottom layer."
• "allows developers to visualize the system as a small umber of interconnected vertical layers."
• The Maximum Cohesion Principle: "All the functions that relate to a single concept are gathered into a single module or class. A software architecture is maximally cohesive if all its modules and classes are cohesive in this way."
• The Minimum Coupling Principle: "Two modules are coupled if either one shares information or receives services directly from the other. A software system is minimally coupled when the number of interaction between all pairs of modules is kept to a minimum."

4.3  Security

• "The first step in ensuring security is to understand the client's requirement that the new software protect confidential and other sensitive information form unauthorized access. A software security policy must be defined for the new system that implements that requirement, and the software must incorporate that policy in a transparent and verifiable way."

4.3.1  Architectural Vulnerabilities

• "Common types of software flaws that lead to vulnerabilities include:"
• "Memory safety violations, such as buffer overflows and dangling pointers"
• "Input validation errors, such as format string bugs, SQL injection, code injection, e-mail injection, directory traversal, cross-site scripting in Web applications, HTTP header injection, and HTTP response splitting."
• "Race conditions, such as time-of-check-to-time-of-use bugs and symlink races"
• "Privilege-confusion bugs, such as cross-site request forgery in Web applications, clickjacking, and FTP bounce attack"
• "Privilege escalation"
• "User interface failures, such as user conditioning, blaming the victim, and race conditions"

4.3.2  User-Level Security

• "When reviewing the security aspects of a software system, we need to ensure that the system enforces the following constraints on users:"
• "Each authenticated user has a unique login id and password, and access to all system functions is provided only after the person enters his/her id and password
• "Each authenticated user has access to only those system functions that are appropriate for their level of access, and no others."
• "Each visitor to the system has access only to those system functions that are appropriate for the general public to access."

4.4  Concurrency, Race Conditions, and Deadlocks

• Many synchronization problems can be avoided with a technique called "locking"
• Locking: "Any session accessing a resource (table or row) in a database gains exclusive control of (a "lock" on) that resource throughout the time required to complete that access (read, write, or update). If a second session tries to access the same resource while the first session has a lock on it, the second session's request is put into a queue until the lock is released. All requests for access to the same resource are handled in a first-come-first-served order."

Day Fourteen: Submitting a Patch to XBMC

Several members of my group struggled with Personal Package Archives (PPA) when compiling XBMC from source. The process is relatively simple once you discover the command format and find the PPA that you need  (I went through these steps for XBMC in an earlier post), but we felt that this information should be present in the readme file. The readme sends you here to a broken link for support documentation on adding a PPA to your system. The readme also links to the recommended PPA for XBMC (development version) here, but it does not provide the command for adding this PPA to the apt-repository, even though this readme is specifically for Ubuntu.

For our first bug-fix, we decided to update this documentation to reflect more accurate information and also to make it easier for future users. XBMC has a wiki page that describes the process of submitting a patch in great detail; however, it does not really mention standards for documentation. The changes to the readme file and running the "diff -u" command were fairly simple tasks. The difficult part was working up the courage to actually submit the file. We double-checked everything and then double-checked it again. The whole process was definitely more nerve wracking than it needed to be, but none of us had ever submitted a patch to an open source community before. 

The ticket can be found here. It seems like we have already received some comments from the developers. I hope everything goes well *crosses fingers*.

Day Thirteen: Fixing the Code

Chapter 7 in the online Teach Open Source textbook deals entirely with patching. It includes many helpful tips and exercises that prepare readers for a real patch submission. The assignment for this class includes exercises 7.2.2, 7.8 and 7.9.

Exercise 7.2.2: Comparing Diff Formats
In the previous sub-section, 7.2.1, the author provides a simple "Hello World." C program for the reader to use. After creating a copy of the file and changing the period to an exclamation mark in the new file, the author runs the following command to diff the two files:

diff -u hello.c.punct hello.c

The "-u" flag represents the unified diff format and creates the following output:


--- hello.c.punct 2012-02-10 01:06:26.431385116 -0500
+++ hello.c 2012-02-10 01:04:49.221384225 -0500
@@ -5,6 +5,6 @@
 #include <stdio.h>

 int main() {
-    printf("Hello, World!\n");
+    printf("Hello, World.\n");
     return 0;
 }

Without this flag, the output is much simpler and shows only the lines that are different, but this format lacks context without the rest of the code. Here is the same command but without the "-u" flag:

8c8

<     printf("Hello, World!\n");

---

>     printf("Hello, World.\n");

Exercise 7.8: Create a Patch for a New File

I  am not sure that I fully understand this exercise. The directions are to "create a patch file that represents a new file, foo being created with the contents bar." I assume this means to create a folder, "foo," that does not contain anything. I diff'd foo with /dev/null, but I received an error (diff: foo/null: No such file or directory). The patch file was created, but it is empty. Here is the command that I ran:

diff -u foo /dev/null >exercise-7.8.patch

Exercise 7.9: Patch Echo

This exercise is very straightforward. Just follow the instructions, and everything works perfectly. I ran the modified echo file and received the reversed message. Here is a copy of my patch:

--- src/echo.c.reverse 2012-02-10 01:48:15.131391331 -0500

+++ src/echo.c 2012-02-10 01:49:16.921559563 -0500

@@ -260,9 +260,8 @@

     {

       while (argc > 0)

         {

-          fputs (argv[0], stdout);

           argc--;

-          argv++;

+          fputs (argv[argc], stdout);

           if (argc > 0)

             putchar (' ');

         }

Day Twelve: Debugging the Code

The assignment for next class is to read chapter 6 in the online Teach Open Source textbook and complete exercises 6.4 through 6.7.

There is not a whole lot of reading in chapter 6 compared to some other chapters. It is centered around the exercises instead of blocks of text and encourages the reader to spend time learning about how a bug tracker system works through practical application. XBMC uses Edgewall Software's tracking system, which is simply called Trac. The landing page for XBMC's tracking system can be found here. All of the descriptive fields mentioned in 6.2.1, such as summary, description, comments, reporter, owner, version, severity and priority, status, and resolution, are present in XBMC's tracker.

Exercise 6.4: Find the Oldest Bug
The oldest bug for XBMC is Ticket #3077. It was created on 07/15/06, and it was last modified on 01/19/10. Based on the description, playback from a playlist does not function as intended when the user the user tells XBMC to play with dvdplayer. Once the first item is played, XBMC reverts back to the default mplayer. The owner, arnova, submitted a placeholder patch to fix the bug, but there has not been any detectable activity for over two years now. It is possible that a fix was included in a later release and the owner and/or the developers simply forgot to close the bug report. This is definitely worth investigating.

Exercise 6.5: Create Your Bug Tracker Account
I mentioned during our group presentation last class that XBMC's forum would not let me register again. I created a username/password several weeks ago but forgot my credentials. There are no obvious ways to retrieve lost log-in information, like a "forgot your password?" link, so I tried to create a new account. I used my private gmail account and my school gmail account, but both attempts returned a message that states that XBMC does not allow spammers to register for the forum. One of my other group members, Julie, mentioned that she had a similar problem, but she said it went away after a day or two. I waited a day and even created a new gmail account, and yet I am still getting the same response whenever I try to register. I contacted the webmaster and hope to receive a reply soon. The bug tracker is linked to the forum username/password; therefore, I will be account-less for a little while.

Exercise 6.6.1: Reproduce a Bug
I looked a lot of the bug reports and tried to find one that seemed easy to reproduce. Ticket #12592 states that XBMC crashes when a movie is renamed in a certain way. The steps to reproduce are as follows:

1. Open XBMC and go to you Movie library
2. Select any of your movies
3. Hit 'c' to open context menu, then select 'rename movie'
4. type some diacritic letters anywhere into the text field (but not at the end)
5. move cursor at the end of the field and hit the backspace key twice quickly

When I hit 'c', a context menu opens, but there is no option to rename the video. The bug reporter mentions that the bug is absent on Windows (the report is for OS X). I was curious to see if a similar problem existed on the Linux version, but it appears that there is slightly different functionality or implementation here. Perhaps the hotkeys are different, and I just did something wrong; however, another user reported that he or she was unable to reproduce the bug in Linux just two days ago.

Exercise 6.7: Bug Triage

Without my username, there is not much I can do to triage bugs. I noticed a few bug reports that could use a closer inspection, such as the one mentioned in exercise 6.4. Most reports that I found were reasonably documented from a technical aspect. I will work more on this exercise once I hear back from the webmaster and get a working username/password.

Day Eleven: Choosing a Bug-fix

My team met earlier today to discuss possible bug-fixes for XBMC. There are dozens, if not hundreds of active tickets, but there are relatively few specific to Linux. Some of the more interesting bug reports that we came across were for different systems, such as Apple TV and iOS. While several users report similar problems, we cannot duplicate these errors without access to similar systems and testing possible fixes would be a nightmare due to this limitation. Many of the Linux-specific bug reports mention the bug and provide a possible solution either in the report or in the comments. It would be possible to implement these fixes and submit a patch, but I am not sure that is what our professor had in mind with this assignment. Still, if the report is listed as open and the fix is in plain sight, perhaps the community is just waiting for someone to make the extra effort.

I noticed that a lot of the reports were self-reported, as in a developer noticed the bug and posted it for other developers to see. In these cases, the reports were quickly assigned to the developers with the skills or the knowledge required to fix the bug. These reports mainly deal with problems that were introduced by the beta release or problems that are extremely important.

However, all hope is not lost. In the midst of assignment-irrelevant reports, I found a possible gem. Ticket #12124 mentions a missing dependency (libltdl-dev) and asks for someone to add this package to the build-dep list and to the README.ubuntu file. This missing dependency could explain why I had trouble installing XBMC on Ubuntu 11.10. This bug might seem a little simple, but there is not much else out there at the moment. A new beta release is on the way soon, so I expect more bug reports here shortly.

Another issue that I noticed is, for lack of a better term, bug responsibility. In some reports, community members traced the bug to a conflict between XBMC and 3rd-party applications or add-ons. If finding a bug in the core functionality of XBMC does not yield any promising results, it is possible to look for bugs in these popular add-ons.

Day Ten: Examining an Article

In IEEE's July/August 2009 publication of Software Domain-Specific Modeling, there is an article by David Garlan, Robert Allen, and John Ockerbloom that addresses the difficulty of software reuse. The article is titled Architectural Mismatch: Why Reuse is Still so Hard, and this title alone was enough to catch my attention. I worked a little with various components and popular APIs in my graphical user interface design class to develop software mash-ups. It seemed difficult to me then because I was learning all of the languages involved, but I just assumed that my lack of experience was the main culprit--who wouldn't struggle with learning three new languages and various APIs for one assignment? The software that we were designing was grossly over-simplified compared to an entire system built for business application, yet it introduced some of the problems that the authors discuss in their article. When trying to design a system from modular parts, one can read all of the documentation and build a system that fits together conceptually; however, when one goes to actually build the system, the interactions between parts can reveal emergent properties, such as architectural mismatch, that impede the development process.

The authors state that a component makes three types of assumptions: assumptions about the application domain, assumptions about infrastructure, and assumptions about components at the same level of abstraction. The main solution the authors suggest for this mismatch is to work withing an "architecturally specialized design domain." This may limit interactions between some components that are built with different domains in mind, but component integration and design standards greatly lessen the headaches involved with trying to link two components that might be incompatible due to an inherent flaw in the way that they were designed.  Ultimately, money decides software engineering best practices. Designing a commercial off the shelf (COTS) product is supposed to be a simpler, more cost-effective way to design products. The next to last paragraph in the article says it all: "Even supposing that you have appropriately modeled evolution's cost, the potential for architectural mismatch might eventually make changing an existing system too expensive to allow effective innovation." Even if the designers make a system that works as advertised, there is a risk for "architecture lock-in" that could outweigh the benefits in the long run.

Day Nine: The Cathedral and the Bazaar

Our current assignment is to read Eric Raymond's essay, The Cathedral and the Bazaar (CatB), which can be found here, and blog our reflections. Having read through the essay in its entirety, I am surprised that Raymond never lists his "lessons learned" all together. The way the text and his stories relate to a specific lesson learned makes sense, but to leave them scattered throughout the text without a single list of every lesson for reference seems strange. Here is a list of every lesson learned for reference:

1. Every good work of software starts by scratching a developer's personal itch.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
3. ``Plan to throw one away; you will, anyhow.'' (Fred Brooks, The Mythical Man-Month, Chapter 11)
4. If you have the right attitude, interesting problems will find you.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
7. Release early. Release often. And listen to your customers.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
9. Smart data structures and dumb code works a lot better than the other way around
10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.''
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend
17. A security system is only as secure as its secret. Beware of pseudo-secrets
18. To solve an interesting problem, start by finding a problem that is interesting to you.
19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

That should be all of the lessons that Raymond listed. Every lesson is interesting to me in some way, but lesson five, and the story behind it, reveals a fact that I have only recently come to realize: the community determines the success and the livelihood of the software. This concept is obvious now, but, before I looked over FOSS projects last semester and discovered that some projects have been abandoned and neglected for many years, I never thought of software from this perspective.

Just today, I installed Ubuntu 11.10 on my HP Mini 1125nr and discovered that there is a bug with how the OS handles the monitor backlight. My netbook's screen would go dim and would only turn back on if I reset the computer. After a quick Google search, lessons seven and eight  revealed themselves in a forum topic and a link to a bug report. An initial user reports a problem; several users report having a similar problem; knowledgeable users and/or developers suggest a solution; the bug is fixed in the next release. The bug could have been avoided with more extensive testing before release, but the problem as quickly identified and fixed with the help of "many eyes."

Now that my group is able to compile XBMC from source, I look forward to diving deeper into the community and the software. I am sure that, in my efforts to contribute to XBMC, I will experience something that relates to at least one of Raymond's many lessons. It is important to recognize the strengths and weaknesses of open source and learn from these lessons.