You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Gunes Koru <gk...@engr.smu.edu> on 2002/10/04 17:48:04 UTC
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.
--
***************************************************************************
A. Gunes Koru
Research Assistant, Ph.D. Student
Southern Methodist University
Computer Science and Engineering Department
6425 North Ownby Drive
Science and Information Building Room 317
Dallas, TX 75205
Home: 214 691 5633
Work: 214 768 2005
Cell: 214 893 7311
http://www.seas.smu.edu/~gkoru
Email: gkoru@engr.smu.edu
***************************************************************************
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Bug handling survey - 80:20 rule
Posted by "A. Gunes Koru" <gk...@engr.smu.edu>.
>
> The loose association of people who make up the Open Source phenomenon couldn't change the world,
>there isn't enough organisation and there would never be agreement.
>A commercial enterprise can pay people to change the world (or to try
>to).
>The best OS can do is to influence individual people, one at a time.
Well. I guess the world "has" changed. Measuring how much it changed is
not easy may be, but Linux is a reality. If the loose association above
could do it, more guided efforts could even do better. I am very
optimistic about it. Simply think about this, is bugzilla not an effort
of organizing things? How about versioning? Mailing lists? All these
things came first because they were immediate needs.
I have a close friend here who contributes her four hours every Saturday
for helping kids who have AIDS. One week, she fills out some paper work,
the other week, she organizes some boxes, stuff.. There "might" be
planning, guidance, task division in volunteer work too. As long as people
know that they are guided (not managed or bossed around) and they know why
things work in a certain way, they will understand you.
As Craig said, the commercial software will be there because of obvious
schedule reasons. However, operating systems, servers, office software,
desktops can replace the commercial ones. So, i am thinking more about
general purpose software. For special purposes, commercial software might
be there in the future too.
Gunes
http://www.seas.smu.edu/~gkoru
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Bug handling survey - 80:20 rule
Posted by Danny Angus <da...@apache.org>.
> Another point, I would like to express is that, in my previous
> correspondence. I said that "commercial software competes" with open
> source software. The subject of that sentence was "commercial software". I
> did not imply otherwise. It is a true statement if you look at the
> efforts in the past to make OSS less successful. I am a true believer
> about turning in and doing as best as you can.
I understood your point, my argument was that while commercial software competes on their own terms with OS software, OS software is often (not always, thanks Craig) pursuing different goals than sucess as measured by market share, and is not strictly competing.
Craig also made the important point that OS software is increasing being used in commercial products, and companies such as my own make our business work through the competitive margins provided by the use of OS software over our competitors who use expensive licensed software to deliver the same results, OS is not seperate from commercial IT, just different.
The loose association of people who make up the Open Source phenomenon couldn't change the world, there isn't enough organisation and there would never be agreement. A commercial enterprise can pay people to change the world (or to try to). The best OS can do is to influence individual people, one at a time.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Bug handling survey - 80:20 rule
Posted by "A. Gunes Koru" <gk...@engr.smu.edu>.
Hi Danny and eveyone. Thanks for your response. Yes I would agree with
many good points. But how many of you are happy with the software monopoly
out there? I am not. "Some companies" are charging hundreds of dollars per
license (for just copying sw), which is, may be the kitchen expenses of a
family for a year in many other countries. The fact that this money is
spent in some of the developed countries does not change the reality for
me. I am not happy with what's going on. I think many of the open source
developers also have this in their heart. I agree that it is fun,
relaxing, etc. but if there is anything we can do for open source software
to be even more successfull, why not do it? Just like people designed web
sites, e-mail lists, bug databases, for better communication.. Why not
employ better risk identification techniques. If there is opportunity, why
not do it.
Another point, I would like to express is that, in my previous
correspondence. I said that "commercial software competes" with open
source software. The subject of that sentence was "commercial software". I
did not imply otherwise. It is a true statement if you look at the
efforts in the past to make OSS less successful. I am a true believer
about turning in and doing as best as you can.
On the other hand, I see your points too. What i think is, it is supposed
to be fun, relaxing in the future too. We, together, should create a
model, in which each contributor can make him/herself useful as much as he
wishes. The important thing is philosophy, willingness to participate,
willingness to share. For example, in my e-mails, I share what I know with
you. Some other will participate in documentation, some other will do
coding, some for example Chinese friends (just example) will help in
translation, some will do testing. Everybody and everything has a special
place.
Once more, thanks for exchanging ideas.
Regards,
Gunes
On Fri, 4 Oct 2002, Danny Angus wrote:
>
> > 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
***************************************************************************
A. Gunes Koru
Research Assistant, Ph.D. Student
Southern Methodist University
Computer Science and Engineering Department
6425 North Ownby Drive
Science and Information Building Room 317
Dallas, TX 75205
Home: 214 691 5633
Work: 214 768 2005
Cell: 214 893 7311
http://www.seas.smu.edu/~gkoru
Email: gkoru@engr.smu.edu
***************************************************************************
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bug handling survey - 80:20 rule
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Santiago Gala" <sg...@hisitech.com> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bug handling survey - 80:20 rule
Posted by Santiago Gala <sg...@hisitech.com>.
Craig R. McClanahan wrote:
>On Fri, 4 Oct 2002, Danny Angus wrote:
>
>
>
>>Date: Fri, 4 Oct 2002 17:45:48 +0100
>>From: Danny Angus <da...@apache.org>
>>Reply-To: Jakarta General List <ge...@jakarta.apache.org>
>>To: Jakarta General List <ge...@jakarta.apache.org>
>>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 started with things like packaging (linux
distributions), bundling (tomcat in iPlanet or Apache in Websphere) or
embedding complete OS products in hardware, but there are a lot of
promises when you apply this methodology to, for instance, building a
ERP platform using OS pieces.
>If a company chooses to leverage an open source product (such as, for
>example, what IBM does with the Apache httpd server by building Websphere
>around it), do you count that as an open source success, or as a failure?
>How about all the hardware products that embed Tomcat to provide a web
>based configuration interface? Or commercial application development
>frameworks and IDEs that support things like Struts?
>
>Don't forget that many companies leveraging open source packages in this
>way *also* fund some of their developers to work on contributing changes
>and improvements back to the open source community, too ...
>
>
Yes, for the scheme to work it should be a win-win. At the very least,
companies leveraging OS packages should aim to improve in the three
problem areas you pointed (SCHEDULE, CUSTOMER FOCUS, SERVICE/SUPPORT)
>
>
>>Yes? No?
>>
>>
>>
>
>Ah, if only life were that simple! :-)
>
>
I think that it is not a yes-no question, but a when-how question.
Internet communications and Open Source is changing all the software
engineering processes, like the press changed th intellectual production
processes a while ago. Pure in-house or contracted developments are
disapearing from the market, and integration on top of Open Source is
leading/will lead the way in the future.
Depending on the nature of the projects, this can go from simple uses of
OS packages (much like a VB programmer assumes that Visual Basic "is
required" for her program to run, you can assume that tomcat or struts
"will be installed there") to minor changes/extensions (writing filters
for catalina, services for turbine, tag libraries, etc.) to crucial
enhancements (can you imagine a java VM which would run on top of a
distributed machine like MOSIX? I would like one of these beasties :-) ,
a good replicating free DataBase would be another of these "killers" )
Once you get used to the fact that you "can" understand the inner
working of your base tools and modify and debug them (more or less)
freely, you will never want to use a non-free equivalent again. And I'm
speaking as a system integrator here.
I catch it very late, but I'm finishing my ApacheCon materials right
now. Curiously enough, my session is called "Developing Commercial
Products on top of OS Software", and is a case study covering the
development of a portal tool using Jetspeed as the base software package.
Regards,
Santiago
>
>
>>d.
>>
>>
>>
>
>Craig McClanahan
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Bug handling survey - 80:20 rule
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 4 Oct 2002, Danny Angus wrote:
> Date: Fri, 4 Oct 2002 17:45:48 +0100
> From: Danny Angus <da...@apache.org>
> Reply-To: Jakarta General List <ge...@jakarta.apache.org>
> To: Jakarta General List <ge...@jakarta.apache.org>
> 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.
>
> 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.
>
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.
* 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.
* 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.
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.
If a company chooses to leverage an open source product (such as, for
example, what IBM does with the Apache httpd server by building Websphere
around it), do you count that as an open source success, or as a failure?
How about all the hardware products that embed Tomcat to provide a web
based configuration interface? Or commercial application development
frameworks and IDEs that support things like Struts?
Don't forget that many companies leveraging open source packages in this
way *also* fund some of their developers to work on contributing changes
and improvements back to the open source community, too ...
> Yes? No?
>
Ah, if only life were that simple! :-)
> d.
>
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Bug handling survey - 80:20 rule
Posted by Danny Angus <da...@apache.org>.
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>