Open Source and Proprientary Approaches To Bugs and Quality

Why does it take so much longer for bugs to get fixed in proprietary software than in open source software? It isn’t just the number of “eyeballs” looking at the source code, or even the quality of those eyeballs; it’s a matter of attitude. Keep reading to find out more.

“Given enough eyeballs, all bugs are shallow.”

This “religious” dispute over “open source versus proprietary code” seems to be one of the eternal discussions in IT.  The success of open source software cannot be denied, and certainly part of this success is due to the open source approach to bugs and quality. It is true that proprietary code companies have whole divisions of Quality Assurance Engineers and testers, which sometimes outnumber their development teams (for instance, for Microsoft the ratio is 1.4 testers to one developer), but does this translate to software of higher quality? Or more precisely: how often does this massive tester presence lead to more bugs discovered and fixed?

What makes open source so successful in dealing with bugs? The joint efforts of millions of people versus the strict hierarchy in proprietary code companies? The fact that volunteer open source programmers are not threatened with the loss of highly paid jobs when it becomes clear that their code is full of bugs? Or is it the lack of pressure to hide the bugs the boss has written, no matter how severe these bugs are? The answer is –- all of these and many more reasons that go to the very essence of open source are the factors for its success in dealing with bugs and achieving quality and reliability.

Those who work on open source software shares a different spirit. It is the free spirit of people who are determined to do things the way they must be done. Open source is also an open attitude to bugs and quality; when thousands of people have access to the code, sooner or later somebody will spot a bug. When there is a will to fix it, not to hide it, bugs are easier to overcome.

{mospagebreak title=The Costs/Quality Correlation}

If the correlation between costs and results is measured, one might think that, since so much money is invested in quality assurance in big companies, this must either lead to bug-free software or count as a bad investment. Well, everybody knows that there is no bug-free software, and it is a small consolation that with so much money and effort, proprietary code companies still have so many critical bugs that often remain unfixed for too long.

If it sounds more optimistic, you can think what could have happened to software quality without companies spending so much money on it. If quality cannot be achieved when money is invested in it, can you imagine what would have happened if nobody cared about quality? So, it could be worse than now. Well, if money is not the problem what could be the reason that proprietary code companies still operate so inefficiently in comparison to open source software as far as quality is concerned?

A cornerstone concept in open source is that “Given enough eyeballs, all bugs are shallow.” It best describes the approach to bugs –- when many (knowledgeable) people review and use the software, there will always be somebody who will know the fix to even the most mysterious problem.  Sure, with 1.4 testers (not including external reviewers) per developer, you would think there must be enough eyeballs. Is the quality of the eyeballs a factor, or is it something else?

Our Bugs Are Our Trade Secrets

Most proprietary code companies are aware of their bugs (or at the least the most severe ones). But it is the attitude of the company and its management — “our bugs are our trade secrets” — that prevents disclosing and/or fixing of bugs. There are many examples of such an attitude, the latest one being the recent Ciscogate.

Sure, not all cases when somebody spots a bug are investigated by FBI and go to court, but this case clearly demonstrates that companies are more interested in hiding the truth at any cost than in correcting their product. Cisco’s situation is a typical example of the arrogance with which big corporations deal with their opponents –- and not only in respect to disclosing “top-secret” information that their products have defects that could have a very strong negative impact on the business of many companies which have purchased and use their equipment.

If it were only Cisco and if it were only this case, it would have been fine. (No matter what the outcome of the case is, one point is certain: Cisco’s reputation is seriously damaged, more by their aggressive defense than by the fact that a severe bug has been discovered in their product). But a similar approach to bugs is typical for many proprietary code companies — when a bug is found, they behave as if this bug is not their fault and try their best not to fix it, but to hide it. 

As a result of the approach proprietary code companies have towards their bugs, it is rare to see a proprietary code company have a publicly accessible bug database, while for most open source companies this is more the rule than an exception. Bug databases are very useful, because information about potential problems is gathered there.

Browsing through a bug database is not done because of curiosity to peep into other people’s mistakes.  Bug databases are not places to show the world how many defects a piece of software has; rather, by giving information about known bugs, they help all users of the software avoid getting into more trouble. When one knows that a particular module has some unrefined issues, he or she will use this module with caution in order not to get trapped. In a way, bug databases are a means of being more honest with your customers and partners.

{mospagebreak title=If There is a Will, There is a Way}

What is stopping proprietary code companies from dealing honestly with their bugs is not lack of money, or time, or qualified staff, but lack of desire to do it unless forced by circumstances.

In general, bugs are not something that developers and companies gladly admit to. It is absolutely logical that nobody is happy to admit his or her mistakes, no matter if commercial interests are involved or it is purely ego.  And as one can  conclude, commercial interests are a very strong motive for hiding bugs, probably more powerful than even the ego of somebody who is in power to prevent disclosure of his or her mistakes. But a mistake cannot be corrected, if it is not identified.

Just compare this attitude to that of the open approach of the Firefox Foundation, which pays $500 for reporting a severe bug! Are you still wondering why, for some proprietary code companies, it takes years to fix bugs?

Fortunately, the pressure from open source seems to be a driving force for proprietary code companies to adopt better approaches to bugs and quality. Although it is still not a rule, proprietary code companies do invite external testers and reviewers. Microsoft, for example, discloses parts of their code to selected external testers. I bet no one believes that Microsoft does this out of altruistic motives.

Usually external testers and reviewers are representatives of selected partners who will use the software, not the general developers’ community, but still it is better than nothing. If these external testers and reviewers have the expertise and above all the freedom to be honest, this could help eliminate a lot of bugs —  either before the software is released, or later when there is a production version, external eyes can help to make it more stable.

{mospagebreak title=Will the Arrogance of Proprietary Code Companies Last Forever?}

The most often quoted and unfortunately not the only example of arrogance in the software industry is Microsoft. If there were no external pressure, they would be happy not to disclose, not to mention fix, a single bug. Probably there are no reasons to believe that Microsoft or any other company that has a monopoly over a given market segment will voluntarily turn into a nice guy overnight.

The arrogant position of commercial companies is easily explainable, when taking into account the amount of money that is at stake.  Billions of dollars are invested in proprietary commercial software and the major concern for such a company is how to make a profit. If customers buy and digest what they are offered, why make additional expenses to improve something that in any case sells well?

I do not want to go into more detail in comparing the quality of open source and proprietary source applications simply because it is not possible to measure them one by one and then draw the line with the grand total. I just mean that the approach of open source towards bug is more progressive than the sometimes cowardly approach of proprietary code companies. And since quality revolves around bugs, which approach to them is accepted does matter.

By no means am I saying that open source software lacks problems with quality. On the contrary, there are enough of them, especially problems related to usability and applications integration. It is a widespread opinion that in general open source applications lag behind in the terms of user-friendliness and usability, and that it can be very tough to make the latest build of your favorite application run with the kernel of your choice, or integrate it painlessly with the other applications on your open source operating system.

Yes, it cannot be denied that usability and integration are also important and that they are also part of quality. But they come after reliability. If the system constantly crashes, who cares about smooth screen lines and the clear instructions in the dialog boxes?

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye