Posted by: Anonymous Coward
on March 15, 2007 11:09 PM
Hello DifferentAnonymousReader,
Thanks for your posted comments and thinking process behind them. I like to respond to your points so we are on the same page.
Thanks for confirming my general point "... suspect you are correct about the unaddressed, and serious, issues in many widely used programs<nobr> <wbr></nobr>...". I am happy to see I am not the only one to share this opinion.
I was not trying to suggest that OSS/FOSS has better security or quality due to the open nature of the code. My comparison to proprietary software was simply to point out a few basic points of differences or common themes that exist in software that transcend FOSS/OSS and proprietary software. Those points being:
1) Developers generally have the same attitude in both venues, proprietary software and FOSS/OSS, in that they often will say the problem cannot exist because they do not experience the issue, they know better what feature and how to implement the feature, or are unwilling to make the effort to validate/consider the issue.
2) The serious issues that I stated exist in FOSS/OSS as rule never happen with proprietary software as too much is at state. Of course there are proprietary software examples where clearly functionality was not thought out or changed even if not buggy in addition to some classic buggy releases or bug fixes that messed up more than fixed issues. Generally the serious nature of system crippling software behaviour, let alone going on over several releases and years of a proprietary software program do not happen. This was the basic point I was making.
3) FOSS/OSS really has no formal QA or testing plans. To highlight this more there are a number of key FOSS/OSS projects that are interrelated and there is no effort to QA these as a collective and their interactions/assumptions let alone the number with many intermediate releases. What happens often is alot of fingerpointing that problem is some other FOSS/OSS project by the FOSS/OSS project the issue is beign reported to.
4) The FOSS/OSS issues/security fixes are more open book in what they are about. The code fixed by implication means the exact nature of a fix is known. Security fixes are geneerally more responsive in time for FOSS/OSS than proprietary software. Proprietary software often only fixes the issue if the issue is publicly known or will be made made public.
5) One reason for these major FOSS/OSS issues is because it depends on developers having the free time to work on the issue and the extent of time it may take to work on the issue. This is nowithstanding a comment you make I will address a bit later in this reply.
You are 100% correct for one reason, at least for me, why I like FOSS/OSS. Open data formats, no data lock in, not being forced to re-enter data to use a different program, the code does only what you expect and can be inspected to confirm, et al. Whereas with proprietary software one can never be sure and as you know there have been many privacy issues uncovered with proprietary software and likely proprietary software will likely continue to make attempts regarding privacy or other unaccceptable behaviour on hopes it will nobody will discover, have time to discover or the proprietary software vendor may try to use the DMCA or copyright to prevent people discovering their unacceptable practices.
I tend to believe the FOSS/OSS code generally has better security as the code can be verified. Some of these FOSS/OSS programs are very secure as they are the basis of the key servers and software infrastructure that much traffic and dependance is on for the internet. That said, these are not the core pieces like average or us tend to use.
I do not believe I am confused about the FOSS/OSS model. Actually for the smaller projects their software quality and issue reporting process is generally more effective and attentive. Again, generally based on my experience. The reason of course is they are smaller projects. They have less people involved adn less people in any project is better timezone and geographical distances aside. I can say I have had excellent experiences with smaller projects and developers communication, interest, giving explanations where I need to be educated or why time will not permit. In most cases when a bug issue is found smaller projects do and will spend the time to invesigate and generally will find and fix the issue. My concern is with the major FOSS/OSS projects that are the basic building blocks most of us use and the basic model looks ok until one takes a closer look at the model vs project size and project importance. Yes the large FOSS/OSS projects have testers, but the issue is there is really no formal test plan and frankly speaking the test plan they may have is far from even reasonable scope of the functionality/complexityof the software. These projects depend it seems heavily on a Beta/RC level test phase to flush out issues. The problem with this approach is most users will stay away from Beta/RC software and the relative short times some of these phases in fact are. Those that do try to test the Beta/RC release may not have enough time, let alone skills to actually test the software. Often many use the Beta/RC more to have the extra functionality more than any interest in reporting any issues, let alone actually take time to do conscious testing. So what happens is we have the 80/20 rule where 20% of the code is used 80% of time and in general this translates to about 30% of the code tested 80% of the time. That is not a math error that I made. Many will no use the Beta/RC code until it is released as "stable". Then once the software "passes" beta or RC phase it is released as "stable" code. Users then think the code is stable and use it under that assumption. In this model this is not a reasonable assumption to make, but most assume this unaware of the shortfalls of this model. Then I would say about 40% of the functionality is used about 80% of time overall once released as "stable". Again no math error here. The 10%-20% delta of the code not really used in Beta/RC is now used and serious issues can arise, and have, just in that 10%-20% delta area, let alone the 60% of code rarely tested at all before the code was released. Therein lies the problem, but as you indicated FOSS/OSS is not chosen for it better quality.
Here is the core issue. These large major FOSS/OSS projects that are basically the building blocks of FOSS/OSS will make or break accpetance of the average user and businesses of FOSS/OSS solutions and hopefully as OS of choice. Let's skip the fact of using the "latest" vs most stable releases of code, where they exist. In some cases "stable" code has not existed for years or months at time depending on the FOSS/OSS project.
With respect to you last paragraph about time, skill level et al vs the serious nature of the issues/bugs. I believe I noted a couple factors why this was a problem - time, maturity, attitude, how familar with the code base. I believe in some cases the skill exists, but it is seems to be a matter of patience level and/or not as cool to work on such issues as it is to make new or cool new features. As I noted the adding on of features while ignoring such major issues can often bury the serious issue or futher compound it. Case in point was one project knew about the problems for few years, then when reported said were aware and addresing, but not for 5 years and security issues of no surprise are then flagged publically that the project really started to work on the issues and yet the core issue remains. During a about 6+ months the issue turned extremely worse, then that one matter seemed to be resolved, but the did not improve on the ongoing worsening issues prior, not for some time afterwards. This is likely a case where skill, familarity with the code base, changing developers often, attitudes clashing, lack of skilled QA resources (who tire of the ego, inmaturity and soap opera affairs of process) who could assist delivering the details and how to duplicate the issues so developers can then see and therefore focus on fixing he issue/bug. So while you do mention skill and time of developers, there is a big lack of skilled of QA resources that can prove and deliver the formula to duplicate issues. If the developer cannot see the issue they cannot fix it or may have to guess how to fix. That is true no matter if proprietary software or FOSS/OSS. That process of software development life cycle is the same for proprietary software and FOSS/OSS.
One other elements that may be not be obvious is with FOSS/OSS the development model for many projects, and certainly the major ones, is development colabaration via distance. For sure this has many positive qualities, but at same time the endearing quality of the model is a big hinderance development, and very much so to QA. There are communications gaps caused beyond he normal dynamics due to geographical/time zone differences that hinder any abilility to show the problem and for people to have the same hardware elements or spare test system to perform the test on. I know there are paid developers via verious sponsors or distributions and non-profit arangements of key project team members, teams and/or hardware for testing. The fact is the distance colabaration is also a hinderance as it takes greater skill for those reporting such problems to know how to package or report issues so developers can see the issue at hand.
Rememeber the issues I am discussing here are the major issues, not the simplier ones. It is the major issues that take alot more time, effort, skills and dedication that make all the other code and functionality less useful. Think of it as a car that has a mystry fuel line leak nobody can find, but the car will stall or run out of gas often at the most important times of need or use, even at times be danger if happens at the wrong time or place. So while I am aware code is sadly never perfect as much as I like it to be, if ther code has serious issues those issues can and do mask out all the wonderful productive features of the software or dependant software.
I hope my reply has clarified my posted comments thus far for you.
QA Anonymous
P.S. It is interesting to note someone about 6 months or more ago has a thesis about the various serious problems with OSS Quality and lack of process and conviction for. It was the subject of mainstream posting I will have to try to see if I can find the link(s) for.
Learn about Linux
Download Linux
Get Linux help
Re:Comparison is misplaced
Posted by: Anonymous Coward on March 15, 2007 11:09 PMThanks for your posted comments and thinking process behind them. I like to respond to your points so we are on the same page.
Thanks for confirming my general point "... suspect you are correct about the unaddressed, and serious, issues in many widely used programs<nobr> <wbr></nobr>...". I am happy to see I am not the only one to share this opinion.
I was not trying to suggest that OSS/FOSS has better security or quality due to the open nature of the code. My comparison to proprietary software was simply to point out a few basic points of differences or common themes that exist in software that transcend FOSS/OSS and proprietary software. Those points being:
1) Developers generally have the same attitude in both venues, proprietary software and FOSS/OSS, in that they often will say the problem cannot exist because they do not experience the issue, they know better what feature and how to implement the feature, or are unwilling to make the effort to validate/consider the issue.
2) The serious issues that I stated exist in FOSS/OSS as rule never happen with proprietary software as too much is at state. Of course there are proprietary software examples where clearly functionality was not thought out or changed even if not buggy in addition to some classic buggy releases or bug fixes that messed up more than fixed issues. Generally the serious nature of system crippling software behaviour, let alone going on over several releases and years of a proprietary software program do not happen. This was the basic point I was making.
3) FOSS/OSS really has no formal QA or testing plans. To highlight this more there are a number of key FOSS/OSS projects that are interrelated and there is no effort to QA these as a collective and their interactions/assumptions let alone the number with many intermediate releases. What happens often is alot of fingerpointing that problem is some other FOSS/OSS project by the FOSS/OSS project the issue is beign reported to.
4) The FOSS/OSS issues/security fixes are more open book in what they are about. The code fixed by implication means the exact nature of a fix is known. Security fixes are geneerally more responsive in time for FOSS/OSS than proprietary software. Proprietary software often only fixes the issue if the issue is publicly known or will be made made public.
5) One reason for these major FOSS/OSS issues is because it depends on developers having the free time to work on the issue and the extent of time it may take to work on the issue. This is nowithstanding a comment you make I will address a bit later in this reply.
You are 100% correct for one reason, at least for me, why I like FOSS/OSS. Open data formats, no data lock in, not being forced to re-enter data to use a different program, the code does only what you expect and can be inspected to confirm, et al. Whereas with proprietary software one can never be sure and as you know there have been many privacy issues uncovered with proprietary software and likely proprietary software will likely continue to make attempts regarding privacy or other unaccceptable behaviour on hopes it will nobody will discover, have time to discover or the proprietary software vendor may try to use the DMCA or copyright to prevent people discovering their unacceptable practices.
I tend to believe the FOSS/OSS code generally has better security as the code can be verified. Some of these FOSS/OSS programs are very secure as they are the basis of the key servers and software infrastructure that much traffic and dependance is on for the internet. That said, these are not the core pieces like average or us tend to use.
I do not believe I am confused about the FOSS/OSS model. Actually for the smaller projects their software quality and issue reporting process is generally more effective and attentive. Again, generally based on my experience. The reason of course is they are smaller projects. They have less people involved adn less people in any project is better timezone and geographical distances aside. I can say I have had excellent experiences with smaller projects and developers communication, interest, giving explanations where I need to be educated or why time will not permit. In most cases when a bug issue is found smaller projects do and will spend the time to invesigate and generally will find and fix the issue. My concern is with the major FOSS/OSS projects that are the basic building blocks most of us use and the basic model looks ok until one takes a closer look at the model vs project size and project importance. Yes the large FOSS/OSS projects have testers, but the issue is there is really no formal test plan and frankly speaking the test plan they may have is far from even reasonable scope of the functionality/complexityof the software. These projects depend it seems heavily on a Beta/RC level test phase to flush out issues. The problem with this approach is most users will stay away from Beta/RC software and the relative short times some of these phases in fact are. Those that do try to test the Beta/RC release may not have enough time, let alone skills to actually test the software. Often many use the Beta/RC more to have the extra functionality more than any interest in reporting any issues, let alone actually take time to do conscious testing. So what happens is we have the 80/20 rule where 20% of the code is used 80% of time and in general this translates to about 30% of the code tested 80% of the time. That is not a math error that I made. Many will no use the Beta/RC code until it is released as "stable". Then once the software "passes" beta or RC phase it is released as "stable" code. Users then think the code is stable and use it under that assumption. In this model this is not a reasonable assumption to make, but most assume this unaware of the shortfalls of this model. Then I would say about 40% of the functionality is used about 80% of time overall once released as "stable". Again no math error here. The 10%-20% delta of the code not really used in Beta/RC is now used and serious issues can arise, and have, just in that 10%-20% delta area, let alone the 60% of code rarely tested at all before the code was released. Therein lies the problem, but as you indicated FOSS/OSS is not chosen for it better quality.
Here is the core issue. These large major FOSS/OSS projects that are basically the building blocks of FOSS/OSS will make or break accpetance of the average user and businesses of FOSS/OSS solutions and hopefully as OS of choice. Let's skip the fact of using the "latest" vs most stable releases of code, where they exist. In some cases "stable" code has not existed for years or months at time depending on the FOSS/OSS project.
With respect to you last paragraph about time, skill level et al vs the serious nature of the issues/bugs. I believe I noted a couple factors why this was a problem - time, maturity, attitude, how familar with the code base. I believe in some cases the skill exists, but it is seems to be a matter of patience level and/or not as cool to work on such issues as it is to make new or cool new features. As I noted the adding on of features while ignoring such major issues can often bury the serious issue or futher compound it. Case in point was one project knew about the problems for few years, then when reported said were aware and addresing, but not for 5 years and security issues of no surprise are then flagged publically that the project really started to work on the issues and yet the core issue remains. During a about 6+ months the issue turned extremely worse, then that one matter seemed to be resolved, but the did not improve on the ongoing worsening issues prior, not for some time afterwards. This is likely a case where skill, familarity with the code base, changing developers often, attitudes clashing, lack of skilled QA resources (who tire of the ego, inmaturity and soap opera affairs of process) who could assist delivering the details and how to duplicate the issues so developers can then see and therefore focus on fixing he issue/bug. So while you do mention skill and time of developers, there is a big lack of skilled of QA resources that can prove and deliver the formula to duplicate issues. If the developer cannot see the issue they cannot fix it or may have to guess how to fix. That is true no matter if proprietary software or FOSS/OSS. That process of software development life cycle is the same for proprietary software and FOSS/OSS.
One other elements that may be not be obvious is with FOSS/OSS the development model for many projects, and certainly the major ones, is development colabaration via distance. For sure this has many positive qualities, but at same time the endearing quality of the model is a big hinderance development, and very much so to QA. There are communications gaps caused beyond he normal dynamics due to geographical/time zone differences that hinder any abilility to show the problem and for people to have the same hardware elements or spare test system to perform the test on. I know there are paid developers via verious sponsors or distributions and non-profit arangements of key project team members, teams and/or hardware for testing. The fact is the distance colabaration is also a hinderance as it takes greater skill for those reporting such problems to know how to package or report issues so developers can see the issue at hand.
Rememeber the issues I am discussing here are the major issues, not the simplier ones. It is the major issues that take alot more time, effort, skills and dedication that make all the other code and functionality less useful. Think of it as a car that has a mystry fuel line leak nobody can find, but the car will stall or run out of gas often at the most important times of need or use, even at times be danger if happens at the wrong time or place. So while I am aware code is sadly never perfect as much as I like it to be, if ther code has serious issues those issues can and do mask out all the wonderful productive features of the software or dependant software.
I hope my reply has clarified my posted comments thus far for you.
QA Anonymous
P.S. It is interesting to note someone about 6 months or more ago has a thesis about the various serious problems with OSS Quality and lack of process and conviction for. It was the subject of mainstream posting I will have to try to see if I can find the link(s) for.
#