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: Differences between Structs and Turbine ???
Since we're OT already, I have to interject a good Jamie Zawinski database quote: === It was a hard sell, since he's a database person, and as far as I've seen, once those database worms eat into your brain, it's hard to ever get anything practical done again. To a database person, every nail looks like a thumb. Or something like that. === tom -Original Message- From: Steve Downey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 8:52 PM To: Jakarta General List Subject: Re: Differences between Structs and Turbine ??? On Wednesday 09 October 2002 07:18 pm, Pier Fumagalli wrote: On 9/10/02 3:47, Berin Loritsch [EMAIL PROTECTED] wrote: Even when Quick and Dirty takes longer. I tried to convince my boss that a certain customization required so many fundamental changes that it would be quicker and easier to develop/maintain if we did it right. He told me that he would never be able to convince the CEO that was the right choice, so the Quick and Dirty route was the choice--taking me twice as long to get it done. I got out of the same tie today, but I won! :-) And it was about Objects in PL-SQL... That was a close one! :-) Objects in PL-SQL. I still have nightmares. SQLJ and Oracle's Object extensions were so seductive. shudder And I'm in the camp that thinks the ad going around with the snail/cheetah = Relational/Object just shows that most OO developers are ignorant regarding the relational model. Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Differences between Structs and Turbine ???
From Scott Adams Wally: I recommedend we build a tracking database. Dilbert: We could put it on the network! PHB: Wouldn't you like to know what the problem is first? Dilbert: We like databases. Databases get used in lots of wrongheaded ways. No argument. But OO people tend to fall into the other trap, treating the database as a 'persistance mechanism'. Then ending up with tons of objects with no behavior other than being able to persist and reify themselves from a datastore. And blaming the database because it's not great at that. On Thursday 10 October 2002 08:00 am, Tom Copeland wrote: Since we're OT already, I have to interject a good Jamie Zawinski database quote: === It was a hard sell, since he's a database person, and as far as I've seen, once those database worms eat into your brain, it's hard to ever get anything practical done again. To a database person, every nail looks like a thumb. Or something like that. === tom -Original Message- From: Steve Downey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 8:52 PM To: Jakarta General List Subject: Re: Differences between Structs and Turbine ??? On Wednesday 09 October 2002 07:18 pm, Pier Fumagalli wrote: On 9/10/02 3:47, Berin Loritsch [EMAIL PROTECTED] wrote: Even when Quick and Dirty takes longer. I tried to convince my boss that a certain customization required so many fundamental changes that it would be quicker and easier to develop/maintain if we did it right. He told me that he would never be able to convince the CEO that was the right choice, so the Quick and Dirty route was the choice--taking me twice as long to get it done. I got out of the same tie today, but I won! :-) And it was about Objects in PL-SQL... That was a close one! :-) Objects in PL-SQL. I still have nightmares. SQLJ and Oracle's Object extensions were so seductive. shudder And I'm in the camp that thinks the ad going around with the snail/cheetah = Relational/Object just shows that most OO developers are ignorant regarding the relational model. Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
About bug handling survey
Dear Andy, First of all, I would prefer to discuss these matters individually not on the list. However, because you are sending e-mails to the list I need to write it to the list too. I am also in this list and I don't see the number of surveys blooming. This is totally an incorrect statement. The e-mails I sent is related to the questions at the very heart of development. So, if they are unsolicited, unrequired, one can easily argue that non of the e-mails is required. Regarding to the second part of e-mail, I think everybody in this list is clever enough to see you are just trying to place some definitions or labels. I am 30 years old I think I have been in many projects, which allow me to talk about what I know precisely. There are people doing their Ph.D. in their 40s and 50s. So, would you call them kids too? You only judge or identify yourself with what you say. You can not identify others. I think, any person who gained true mastery in a field would not feel this need to do it anyways. Let people decide. I have been received over 110 answers. Let me ask you this. If there are people in this project interested in what I am writing, how can you feel comfortable trying to put down this communication. Do you think your friends do not have the ability to distinguish what is useful, what is relevant, what is not? As I conclude, I should say that I am truly inspired with what I am doing and would like to remind this I might disagree with what you have to say, but I'll defend to the death your right to say it. Voltaire To everybody, if the things I write in my e-mails make sense, please visit: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html and fill out my survey, if you haven't done yet. Regards A. Gunes Koru http://www.seas.smu.edu/~gkoru === I answered the first two or three of these that was sent to me (student studies)... But they seem to be blooming rapidly. One could hypothesize through the use of some kind of mathematical model that if one continues to participate they will increase exponentially and eventually one will answer surveys with all of the time they would spend actually participating in open source software projects. We should round these kids up and get them to maybe create a student survey information site. They could do it as their own opensource project and then collect the data they need from themselves ;-) -Andy = On Wed, 2002-10-09 at 10:38, Gunes Koru wrote: Hello Jakarta contributors, I am conducting a survey about the way bugs are handled in open source software projects. The survey includes questions that can be answered by developers,testers, bug fixers, project managers, and owners of defect databases. It is only and only for research purposes and it is very easy to fill out. It consists of three short sections which can be completed at once or in different sessions. Please fill it out if you haven't done yet. You will find the questions interesting since there is a reason behind each one one of them. They will make you think about how things work (or could work)in your project. The survey can be found in the address: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html The data in the bug databases can be used to identify the high risk areas in the software development. One of the ways of doing it is constructing tree-based models, which could be very useful in open source projects. If you would like to read about it, I prepared a web page for you: http://www.seas.smu.edu/~gkoru/surveys/tbdm1.html Please accept my apologies if you receive duplicates of this e-mail. This is a survey, which will give useful results for all of us. I will try to prepare and make some preliminary results on-line within the next two weeks. Since this is a survey, covering many important open source projects, it will be interesting for everybody to see what kind of quality assurance work is going on in the other projects. As always, we are very dedicated to this research. Please contact me for any question you might have. Thank you, A. Gunes Koru http://www.engr.smu.edu/~gkoru -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Differences between Structs and Turbine ???
Just goes to show you. A sad comment on software development: The only thing worse than our still crappy tools for doing things are our crappy methods of doing them. -Andy On Thu, 2002-10-10 at 10:38, Steve Downey wrote: From Scott Adams Wally: I recommedend we build a tracking database. Dilbert: We could put it on the network! PHB: Wouldn't you like to know what the problem is first? Dilbert: We like databases. Databases get used in lots of wrongheaded ways. No argument. But OO people tend to fall into the other trap, treating the database as a 'persistance mechanism'. Then ending up with tons of objects with no behavior other than being able to persist and reify themselves from a datastore. And blaming the database because it's not great at that. On Thursday 10 October 2002 08:00 am, Tom Copeland wrote: Since we're OT already, I have to interject a good Jamie Zawinski database quote: === It was a hard sell, since he's a database person, and as far as I've seen, once those database worms eat into your brain, it's hard to ever get anything practical done again. To a database person, every nail looks like a thumb. Or something like that. === tom -Original Message- From: Steve Downey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 8:52 PM To: Jakarta General List Subject: Re: Differences between Structs and Turbine ??? On Wednesday 09 October 2002 07:18 pm, Pier Fumagalli wrote: On 9/10/02 3:47, Berin Loritsch [EMAIL PROTECTED] wrote: Even when Quick and Dirty takes longer. I tried to convince my boss that a certain customization required so many fundamental changes that it would be quicker and easier to develop/maintain if we did it right. He told me that he would never be able to convince the CEO that was the right choice, so the Quick and Dirty route was the choice--taking me twice as long to get it done. I got out of the same tie today, but I won! :-) And it was about Objects in PL-SQL... That was a close one! :-) Objects in PL-SQL. I still have nightmares. SQLJ and Oracle's Object extensions were so seductive. shudder And I'm in the camp that thinks the ad going around with the snail/cheetah = Relational/Object just shows that most OO developers are ignorant regarding the relational model. Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: About bug handling survey
On Thu, 2002-10-10 at 10:39, A. Gunes Koru wrote: Dear Andy, First of all, I would prefer to discuss these matters individually not on the list. However, because you are sending e-mails to the list I need to write it to the list too. Then you might have taken my smartassed remarks personally... oh wait.. ;-) I am also in this list and I don't see the number of surveys blooming. This is totally an incorrect statement. The e-mails I sent is related to the questions at the very heart of development. So, if they are unsolicited, unrequired, one can easily argue that non of the e-mails is required. This is a circular argument... If my smartass remarks on your survey are unsolicited, unrequired then one can easily argue that any response to your survey ;-) Regarding to the second part of e-mail, I think everybody in this list is clever enough to see you are just trying to place some definitions or labels. I am 30 years old I think I have been in many projects, which allow me to talk about what I know precisely. There are people doing their Ph.D. in their 40s and 50s. So, would you call them kids too? You only judge or identify yourself with what you say. You can not identify others. I think, any person who gained true mastery in a field would not feel this need to do it anyways. It was a generalization based on the last few of these surveys I've gotten. There are always exceptions. Let people decide. I have been received over 110 answers. Let me ask you this. If there are people in this project interested in what I am writing, how can you feel comfortable trying to put down this communication. Do you think your friends do not have the ability to distinguish what is useful, what is relevant, what is not? Because its was my opinion. I've never gained any really useful information out of surveys, most especially on software development. As I conclude, I should say that I am truly inspired with what I am doing and would like to remind this To each their own. If Surveys inspire you...go for it. If making smartass remarks about how many surveys I get in a day inspires me...well I'll go for it ;-) You know what I hate most about surveys? Trying to characterize my answers into one of the choices. I am that dot you throw out because it falls outside of the acceptable range of deviation ;-) I might disagree with what you have to say, but I'll defend to the death your right to say it. Voltaire exactly ;-) -Andy To everybody, if the things I write in my e-mails make sense, please visit: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html and fill out my survey, if you haven't done yet. Regards A. Gunes Koru http://www.seas.smu.edu/~gkoru === I answered the first two or three of these that was sent to me (student studies)... But they seem to be blooming rapidly. One could hypothesize through the use of some kind of mathematical model that if one continues to participate they will increase exponentially and eventually one will answer surveys with all of the time they would spend actually participating in open source software projects. We should round these kids up and get them to maybe create a student survey information site. They could do it as their own opensource project and then collect the data they need from themselves ;-) -Andy = On Wed, 2002-10-09 at 10:38, Gunes Koru wrote: Hello Jakarta contributors, I am conducting a survey about the way bugs are handled in open source software projects. The survey includes questions that can be answered by developers,testers, bug fixers, project managers, and owners of defect databases. It is only and only for research purposes and it is very easy to fill out. It consists of three short sections which can be completed at once or in different sessions. Please fill it out if you haven't done yet. You will find the questions interesting since there is a reason behind each one one of them. They will make you think about how things work (or could work)in your project. The survey can be found in the address: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html The data in the bug databases can be used to identify the high risk areas in the software development. One of the ways of doing it is constructing tree-based models, which could be very useful in open source projects. If you would like to read about it, I prepared a web page for you: http://www.seas.smu.edu/~gkoru/surveys/tbdm1.html Please accept my apologies if you receive duplicates of this e-mail. This is a survey, which will give useful results for all of us. I will try to prepare and make some preliminary results on-line within the next two weeks. Since this is a survey, covering many important open source projects, it will be
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]
Re: About bug handling survey
On 10 Oct 2002, Andrew C. Oliver wrote: On Thu, 2002-10-10 at 10:39, A. Gunes Koru wrote: I am also in this list and I don't see the number of surveys blooming. This is totally an incorrect statement. The e-mails I sent is related to the questions at the very heart of development. So, if they are unsolicited, unrequired, one can easily argue that non of the e-mails is required. This is a circular argument... If my smartass remarks on your survey are unsolicited, unrequired then one can easily argue that any response to your survey ;-) No. First of all, 95% of the survey questions are about the facts. The rest are about the people's opinions. Your remarks are not related to the major part of the survey. So, your remarks are not answers to the many questions. In the comments part of the survey, nobody tried to exercise any control on how you fill it out, how you answer the questions. You are free to leave your comments on the survey form. Nobody told you that any answer or comment is irrelevant. You are the one who raises such an issue about the relevancy e-mails. Your point above that this is a circular argument does not make any sense at all. smartass remarks You think so. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Differences between Structs and Turbine ???
Daniel Rall wrote: Berin Loritsch [EMAIL PROTECTED] writes: Pier Fumagalli wrote: On 8/10/02 1:30 am, Jon Scott Stevens [EMAIL PROTECTED] wrote: on 2002/10/7 5:21 PM, Pier Fumagalli [EMAIL PROTECTED] wrote: JSPs are the root of all evil because HTMLers think to have the power (and obligation, after a while) to blatantly destroy your entire container in less than 2 minutes of uptime... To that respect, even ASP are better... It is so nice to hear you say that finally Pier. =) I still think that the optimal solution is a true SOC using XML, but the world is too stupid to understand that... All everyone wants is a quick and dirty solution... Even when Quick and Dirty takes longer. I tried to convince my boss that a certain customization required so many fundamental changes that it would be quicker and easier to develop/maintain if we did it right. He told me that he would never be able to convince the CEO that was the right choice, so the Quick and Dirty route was the choice--taking me twice as long to get it done. Depending on the situation, my response to something like that is my way or the highway. Funny, that was the tack that my manager gave me... ;P BTW, I took the highway and I need a job... (actually they went broke, but the result is the same). -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Differences between Structs and Turbine ???
Nick Chalko wrote: -Original Message- From: Rich Persaud [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 08, 2002 8:26 PM To: Jakarta General List Subject: re[2]: Differences between Structs and Turbine ??? Preferred pain is a known pain with an experience-based cap. New and improved pain may promise an average POI (Pain-on-Investment) that is 50% of the familiar pain, but will be assigned a risk profile with unknown maximum pain. If your previous experience confirms that max(NewPain) = max(OldPain), then go ahead and implement NewPain, but make it look like OldPain. If max(NewPain) turns out to be max(OldPain), you're on the hook. But you would have first hand experience to make the call, whereas your boss (and definitely his boss) would not (or they wouldn't object in the first place). One successful implementation of NewPain where max(NewPain) = max(OldPain), while delivering promised improvements, will set a precedent. But someone has to take the risk. And it won't be people twice-removed from the pain. ... in my (painful) experience. Here is the short answer. Always say Boss I think this will take a little refactoring of some code. I should be able to reuse the most of the code. I will only change what has to changed, and I will make sure that the changes are isolated. Then do you whatever it takes, including throwing out ALL THE OLD CODE. It's your reputation regardless. You will not be able to say My manager wouldn't let me do it right They will always say If you knew it was the wrong approach, you should have come to me so we can discuss it with your manager. Sure I can. They litterally can't afford change--not even the more painful way. I started doing it correctly, but I was instructed to stop. Can we say pointy haired boss? BTW, I have a reputation in the company for doing a good job of bringing order out of chaos. They just wanted to wallow in chaos. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
