Why You Should Watch Open Source Even If You Don't Care For It

Although most of the software I have written is what could be characterized as proprietary, I have followed many open source projects with interest and have come to admire not just the quality of the code but the process whereby it comes into existence.

Developers whose disdain for open source prevents them from coming into contact with it cheat themselves. This is hardly new knowledge; however, my deductions and learning from open source &0151; in as much as they reflect my unique circumstances and propinquities— may prove useful to you, so I invite you to read on.

Refactoring
People who write commercial software, even those who are the staunchest advocates of refactoring, do not give refactoring its dues. Even in the most refactoring-friendly shops, this is done as a one-off process and never acknowledged as benefitting more than the project at hand.

In the open source world however, refactoring is given more attention because, to paraphrase the famous saying, refactoring anywhere is boost to good code everywhere. My favorite example is how the Linux kernel code has been systematically rewritten even when, as a product, it has consistently outperformed its nearest competitor for a very long time.

So, why do open source developers refactor more? DaVinci-like artistic pride in their work (which is always open for the world to examine) is a prima facie motive.

However, I think there is also a realization among these developers that by improving on earlier work, they improve on their skills as developers and hence their chances of writing better code in the future.

This, I think is a philosophical stance that any development team would profit from. Granted that there are release cycles and deadlines to satisfy, developers can still plan for refactoring. This might be achieved by regularizing schedules and avoiding, in as much as possible, the extremes that make developers go from consecutive all-nighters around release date to WOW-ridden time-killing days.

I know overtime and comp time are sometimes inevitable, but they should be the exception to the rule. A good project manager or head developer should plan for professional development during bench time with as much care as he/she would budget project-earmarked time. Under such circumstances, enhanced refactoring can be worked in quite easily. Google's 20%-time rule is perhaps the most creative way to achieve this.

Code Review
In the commercial software world the very phrase code review has almost the same connotation as administrative leave except that the latter is less tedious. This is very unfortunate especially since it hurts quality and promotes more bugs than any other practice I can imagine.

Agile shops have helped to remove some of the stigma associated with the phrase, but it is the open source world that has led the way. Open source developers welcome code review the way painters prepare to display their work in a swanky gallery. Why is this?


After monitoring discussion threads for couple open source projects, I have to come to realize that the reason for this confidence might stem from the following factors I've observed :

1. bad code and its correction is viewed as a learning experience for all as opposed to an embarrassment to the originator


2. there is no shame in needing correction and a developer whose code was corrected is still allowed to or encouraged to correct the code of others if necessary


3. 
   there is a pervasive sense of ownership in and responsibility for "the application" as opposed to one's piece alone
   


4. open source developers use their continuous code-review process as a means to collaborate — not recriminate

QA and Testing

Sometimes, inevitably so, despite the best efforts to separate testers from developers, there is pressure on the QA team to certify software too quickly. Understandably, this pressure to ship or release by a certain date is due to the fact that delays cost money.

However, a better practice would be to prioritize QA reports and provide graded certifications so that a product can still ship on time with an assurance given to customers that there will be reasonable number of updates included with the original price of the software product. Besides, updates and downloadable patches are quite inexpensive to provide over the Internet.

One reason many open source products have far fewer bugs than their commercial counterparts is that, in the open source world, bugs are sought feverishly and expected as part of the process. In the commercial world, however, I am afraid bugs are seen as nuisances and departures from "the original plan."

This transparency might seem self-defeating on the surface, imagine how devastating it would be if a disgruntled ex-employee were to leak the truth to the press!

Before anyone mentions Windows Vista, let me hasten to say that I do not condone the release of incomplete products to paying customers. Buyers have a right to expect a certain finish and polish to commercial software products, but they might be more likely to accept certain limitations with the understanding that there are a few minor fixes pending — remember the "we owe" sheet you had to sign at closing when you bought your last home?

Division of Labor
Project managers for both commercial and open source software projects subscribe to the principle of labor division. However, open source projects seem to benefit more from its application. Why is this?

It appears that open source projects are a lot more flexible in how they are structured. In other words, people are willing to drop previously assigned action items and take on new ones as circumstances dictate. Egos seem to be less hypersensitive and players are more flexible.

The reason commercial shops are so inflexible has less to do with IT that with HR. It is a shameful display of incompetence on the part of IT managers that they have not realized that HR titles don't always fit an individual's true capabilities or the specific needs of a project. I would be more forgiving of IT managers if there weren't other fields in which the same issue is handled in a much better way.

In the movie industry, for example, the director may play parts in a scene which, in turn, might be directed by another person. The finished movie is more important than nominal titles and no one feels cheated by such practical reassignments. Likewise, in the software industry, we need to be able to reorganize a team as many times and in as many ways as we need to create a truly best-of-breed product — titles be damned!


Bottom Line
Regardless of whether you see open source as the enemy or as a complement to commercial software, you stand to gain from learning the secrets to the success of projects that have bested competing teams with a lot more resources. These are true code gladiators whose work bears some examining.

I encourage all developers to look at some of the code out there. Every SourceForge project has a link to the code; and the home pages of the projects listed may have links to their respective discussion boards. Failing that, a Google search or the Wikipedia entry for the application in question will do the trick.

Code on!