Re: Bug handling survey - 80:20 rule
Craig R. McClanahan wrote: On Fri, 4 Oct 2002, Danny Angus wrote: Date: Fri, 4 Oct 2002 17:45:48 +0100 From: Danny Angus [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: RE: Bug handling survey - 80:20 rule So, how come the commercial software can still compete with open source products. You're assuming, of course, that you can't have commercial software that *is* open source :-). Such models do exist -- so I'm assuming you are primarily talking about closed source commercial software. This is a very meaningful distinctions. IMO, the fundamental distinction here is that of Open vs Closed, not beer-free vs Commercial, where Open means Free-freedom (I don't want to go GPL vs BSD here) IMHO its because on the whole OpenSource contributors are not doing it to compete with commercial software, in fact many of us do this to provide an alternative to the daily pressures, restrictive working practices and profit driven project management of commercial IT. Having been (and still am) sitting on both sides of this fence, there is quite a bit of truth to this observation. We're either much less interested in producing a competitor for a commercial product than producing an intelligent, elegant and efficient solution to a particular problem, or we're here to collaborate on a product to use in our own commercial interests, not in competing in the market place. Commenting on Danny's sentence, you need to make a difference between We as in each one of us, and We as in the community. Even when each individual developer is interested in producing an intelligent, elegant and efficient solution to a particular problem, the community can still produce a competitor for a commercial product :-) There are a lot of colective behaviours going on here, enabled by the efficient communication means we are using, which completely make the difference. Knowing how to ride this wave is definitely part of the fun. I don't think you can generalize to *all* open source projects not being interested in competing with commercial packages, but this attitude is certainly common. IMHO, there are at least three major factors that means commercial software isn't going to go away any time soon, no matter what happens in the open source community: * SCHEDULE - we all know the standard (and usually pretty sarcastic) response that we open source developers give to the when's the next version going to be released. But this is a very very important issue for people who are planning projects that depend on that next release being completed. Yes, commercial software vendors sometimes miss their dates too, but at least they generally try to meet a predicatable schedule that can be communicated to customers. In my view, this means that succesful OS Product Manager will have lo learn to predict fairly accurately the response rate of the community for a given situation, and deliver the right expectations to customers. * CUSTOMER FOCUS - like any product, commercial software must meet the needs of customers in order to be viable. While there are certainly open source projects that try to do this, I'd bet that commercial software vendors are perceived as being more responsive in this regard generally -- it's their whole livelihood at stake, versus an open source project that is being done for fun or to collaborate on something interesting. In my view, this means that succesful OS Product Managers will have to learn to influence (with brute force money, persuasion or other means) the community to guide efforts in the required direction. * SERVICE/SUPPORT - While it is a myth that you can't get support for widely popular open source projects (check out the Resources pages for something as small as Struts, for example), it is *definitely* true for less popular projects, or projects where the developer community is fairly limited. In my view, this means that succesful OS Product Managers will have to learn to organize support networks for their products in different ways as in CS Product Companies. Individual open source projects can clearly choose to deal with the objective realities in each of these three areas, and the ones that do have no problem competing with commercial closed source software. But the general perceptions in these areas about the open source community, as a whole, are fairly accurate IMHO. On the other hand, the real world is also getting more complex in this regard, with companies choosing to build commercial products that are partially or (almost) completely constructed with open source software -- licenses like the Apache Software Foundation license make this trivially simple. I have some experience regarding this area, and I think this is an area with a lot of future. Most software integration effort will go this way in the next years. We have
Re: Bug handling survey - 80:20 rule
Santiago Gala [EMAIL PROTECTED] wrote: You're assuming, of course, that you can't have commercial software that *is* open source :-). Such models do exist -- so I'm assuming you are primarily talking about closed source commercial software. This is a very meaningful distinctions. IMO, the fundamental distinction here is that of Open vs Closed, not beer-free vs Commercial, where Open means Free-freedom (I don't want to go GPL vs BSD here) I agree wholeheartedly... We're planning to change our servlet container because we can't get the sources of the one we're using right now. (No, as of now I'm not a Tomcat user, and probably not even in the future). The one we use ATM is good, but comes in binary only and had already to decompile the classes TWO TIMES to figure out why some of our web applications were failing. No fun. On the other hand, I don't mind paying for a Servlet container which gives me full access to the source... I have some problem on live, if I have the sources, I can check it out and try to fix it... Having the sources is also beneficial if I want to have a support contract with my container: if I see a bug, they can tell me to modify and recompile the sources, apply some patches, we can work together to solve it, instead of being a blind process of receiving a jar file and putting it live... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Bug handling survey - 80:20 rule
Hi all contributors of Jakarta, As you might have heard, I am conducting a bug handling survey on: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html So far, we have received answers from the developers, testers, defects fixers, and project managers in KDE, GNOME, Apache, OpenOffice, Mozilla, and other projects/sub-projects. Even though, we have not asked any names or e-mails, some of you have left their contact information and expressed their willingness for further cooperation in this direction. Thanks for your interest so far. If you have not done so, we would appreciate it, if you could fill out this survey since statistically more and more meaningful interpretations can be made as your participation increases. It is a short survey which consists of three sections that can be filled at once or different sessions. Many of the questions in the survey were put there purposefully, and they will make you think about how they apply to Jakarta project. You will find them very interesting. One more time, this is a research project,which has many potential implications. This is NOT anything like a spam, it has no commercial nature and it is aiming to contribute to Jakarta just like any other e-mail. We are very dedicated to this research, whose only and only purpose is looking for ways of increasing the quality of open source products. We apologize in advance if you receive duplicates of this e-mail. 80:20 rule, which is the subject of this e-mail is a well observed phenomenon, in many of the large scale software products. These products were produced by IT, Telecom companies, even by NASA. They were developed following different methodologies, they were written in different languages, and the application domain or problems they solve were different. However, 80:20 rule was still observed. This means that you might be developing desktop applications, office software, compiler, kernel, http server, or whatever, most likely you will make a similar observation your project. I included two references at the bottom about it. Both of them are very easy to follow and informative. Also, they are very recent references. The numbers in 80:20 rule are percentages but not of the same quantity. 80% here represents 80% of the target risk, which might be defects, rework, effort, etc. So, you want to reduce them. 20% represents the contributor. You might want to name 20% as modules, component, packages, for the product if you will. A great deal of your goal in a project lies in this 80%. And the observations tell us that this 80% target risk stems from 20% of your modules, or components. If you could only identify this 20% part in what you develop, you would make substantial improvements in quality. The identification techniques could be a subject of another time. But, now, why is this important? Because, some projects never get to a desired level of quality, they can not meet their schedule. People code it, patch it, code it, patch it.. After some time users may loose trust, it may become something which is not manageable any more. So even though, the efforts are made by volunteer programmers, it is sad to see that potential is not used fully. Because these efforts could make even greater contribution to free software and they could end the software monopoly out there more quickly. I am one of those who observes the high amount of traffic in developers lists. This is huge. Everybody looks at one thing, sees it from a different point of view, designs are evaluated, code is tested, fixed, etc. Collaborating, sharing bring many advantages. There is big potential. I can easily tell that in many cases the communities are much larger than many software teams in the industry. So, how come the commercial software can still compete with open source products. One of the reasons is that they have been applying these techniques for years. Now think about the advantages of risk identification techniques and the advantages of open source development combined. Wouldn't it be great? This is where we see the tremendous opportunity. As concluding this e-mail, I repeat my invitation one more time. Please visit: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html today/this weekend and help us in this research. If you want to see or remember my previous invitations, they are at the same address. By the way, if you have already completed it and want to change your answers (some did ask this issue) please contact me, we need to identify your unique entry and change it, please do not complete it twice. Thanks for your support so far. Please contact me for any question you might have. Gunes References: 1) Barry Boehm, and Victor R. Basili, Software defect reduction: Top 10 list, IEEE Computer Magazine, Vol. 34, No.1, pp: 135-137, January 2001. 2) Jeff Tian, Risk identification techniques for defect reduction and quality improvement, Software Quality Professional, 2(2):32-41, Mar 2000. --
RE: Bug handling survey - 80:20 rule
So, how come the commercial software can still compete with open source products. IMHO its because on the whole OpenSource contributors are not doing it to compete with commercial software, in fact many of us do this to provide an alternative to the daily pressures, restrictive working practices and profit driven project management of commercial IT. We're either much less interested in producing a competitor for a commercial product than producing an intelligent, elegant and efficient solution to a particular problem, or we're here to collaborate on a product to use in our own commercial interests, not in competing in the market place. Yes? No? d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
