RedHat to Invest in MozillaMonday November 29th, 1999Gerbil writes, "Our 'beloved' ZDnet has another Mozilla-related article, and it's actually positive this time! It states that Red Hat plans on investing money and resources in Mozilla. After all, Red Hat does use a version of Bugzilla for their bug tracking. Very interesting." We'd be remiss if we didn't mention Chris Blizzard of RedHat, whose contributions to the Mozilla project have been invaluable. Then Mozilla maybe can get rid of the AOL wet blanket. And yes, I hope they spend more money on a graphics engine without the depencies on gtk. The need for speed is important. If anyone is wondering what I meant with the last sentence. It's not a new ngLayout. Chris Blizzard works on a lowlevel interface directly based on Xlib. I hope they spend some time on that, because even if gtk is a thin layer above Xlib it is a layer and it will make Mozilla slower. Hopefully the infusion of help and money will help display that article correctly. Using Build 1999111520 and that article doesn't show up right at all. Thishas been entered as BugID 20252 .http://bugzilla.mozilla.org/show_bug.cgi?id=20252 Isn't it ZDnet's crappy HTML coding causing Mozilla to choke so much on the code that it can't render their pages correctly? <:3)~~ Handling bad HTML is a requirement for a good browser. That's great. But I'm wondering why there aren't more commercial vendors supporting Mozilla/Netscape development. I'm thinking specifically of IBM since they are investing so heavily in Java and Netscape is the only major browser developer committed to supporting Java. When you consider how many people they have working on Java related technologies (and how deep their pockets are) would it hurt for them to dedicate a dozen programmers to help speed up Mozilla browser development? And just about every other company that has a stake in the success of a non-Microsoft operating system or cross platform technology should be similarly motivated. Many small companies probably can't afford to do that, but many others could (and should). Your question about commercial support for Mozilla caused me to raise another related question - I thought I read something (earlier in the month & now I can't remember where) about Intel helping to code the browser cache system for Navigator 5. Does this sound true to anyone? I'm not really sure how accurate this is, but I found it interesting.
Rather than throwing money at Mozilla.org, many corporations are helping by paying their employers to work with the Mozilla code and submit patches etc. to Mozilla.org. Take for instance Citec, Sun, Intel , Nokia and what have you (I forget, there are so many... all those companies that are using the layout engine for example have probably contributed something and they have paid their developers to do so). THIS IS GREAT NEWS! A little corporate competition never hurt. This also means we can expect a second major distribution of Mozilla, which is awesome, cuz I wasn't looking forward to the AOL label. Hopefully though, they'll continue to work together so the add-on 'extras' are compatible. Man, this is GREAT! W I second that - I think that Red Hat fans should smile at this news, since closer Red Hat/Mozilla cooperation assures that the 5.0 version gets all the feature-rich goodies Linux users expect. Adam Oh, and yeah I know the "AOL label" can be peeled off with XUL. I'm just saying Red Hat has a long track record supporting/funding open source projects (GNOME, to name one) where as AOL doesn't. I just hope they don't step in and go "We've just come up with a new rendering engine we call Gecko II" :) W I think there's supposed to be a Netscape branded version and when AOL's contract with Microsoft runs out, an AOL branded version. I could be wrong though. more people like chris blizzard. he's doing a great job on Mozilla. -Seth A courtesy copy of my contribution to the ZDNet discussion follows. Mozilla bug status links: http://bugzilla.mozilla.org/reports.cgi?product=-All-&output=most_doomed&links=1&banner=1 http://bugzilla.mozilla.org/reports.cgi?product=-All-&output=show_chart&links=1&banner=1 Summary: Over five thousand bugs, with the number increasing all the time. Conclusion: To ship a product, the bug line must decrease. The Mozilla bug line has always increased, and the more work is done, the more bugs are generated. This is a project that cannot ship without some kind of radical change. Poscript: The Mozilla community is unwilling to engage even the fact that there is a problem, and refuses to discuss these facts on MozillaZine. It could also be argued that it's natural for the bug list to expand for a time (especially while the list of implemented features is still growing) but that after a time (hopefully soon, of course) it will contract. Yes, the buglist keeps growing because new features are still being implemented. After feature freeze expect a steady downhill slope for the bug counts. But... expect a jump up during the early months of beta release. The statistics have shown that while preparing for a milestone, 2.5 bugs have been resolved per day per developer. If that rate could be kept, fixing 5000 bugs with 200 people would take 10 days! That is not realistic, though, because resolving bugs for milestones also meant moving some of them to later milestones. Still, it shows that 5000 open bugs is not a catastrophe. You are fooling yourself if you think 5k open bugs isn't a Bad Thing(TM). It shows poor unit testing skills on the part of the developers, or poor design definition on the part of the designers, or both. -Chris A goodly number of the open "bugs" are requests for enhancements. And among those that are bugs, some can't be fixed until additional backend is in place. A lot of the bugs are dependent on other bugs that are dependent on other bugs. It's like a house of cards; take away the foundation and the rest fall. In any case, keep in mind that this is still pre-alpha. Lots of release projects have hundreds of open bugs that are legitimate bugs. That a pre-alpha project has bugs is to be expected. I'm sure the application developers just love the fact that the 50+ bugs they clear each week are being replaced with 50+ RFEs which they couldn't have been able to address because the enhancement wasn't addressed in the origional spec. They should do themselves and everyone else a favor and keep the RFEs seperate from the real bugs. Testers should be focusing on testing code, not asking themselves how they can make the mousetrap better. -Chris This is Echinacea Feldercarb again, the original bug links poster. I find it rather surprising that people would not consider a 5K bug load and a near-monotonic upward defect curve out of hand for an application at any stage of development. Logistically, managing a 5K bug database would exceed the capabilities of any quality or engineering organization I've worked with. Consider tasks like regression and duplicate screening. They grow linearly with the number of bugs, and are critical path items that control the performance of the whole quality effort. Size is no excuse. The risk of a bug increases as program complexity increases -- the only way to have a complex software system work together properly is if the modules are solid. Integrating flaky modules becomes harder and harder as the system grows, until finally integration cycles start to undergo major failures, and ultimately the project is canceled (see Copland). More complex systems demand better quality engineering from the start or their failure risk grows exponentially with their size. Development stage is no excuse. There's never an excuse for submitting a bug-ridden component. You can't produce quality software by just throwing code at the wall and seeing what sticks, even in the name of "adding critical features". Each bug in a component presents a risk that it will expose a major architectural problem in the component requiring it to be rewritten. If the component isn't solid, you don't know whether it can be made suitable for shipment later in the development cycle. For a single component of a large system to have hundreds of bugs makes it virtually certain that the component will need to be replaced. For the bugs not to get addressed until alpha or beta means that you will be replacing major components late in the development cycle, which is essentially resetting the software to a pre-alpha stage. This is a recipe for never shipping. Given that the problems with this bug load and the ever-escalating defect line are obvious to anyone who has been through the process of releasing large software products, the question is what can be done? I have some ideas but I'd prefer to hear others's first. I agree with you completely. As far as doing something about it, I think the people involved need to recognize that this is a very serious problem! I'm as shocked as you are that people are comfortable that 5k bugs is satisfactory, but it's kinda standard practice here to do a little pat on the back because the work here is all done for free (which I can appreicate, but let's call a spade a spade, ok?) Once people recognize that this really is a problem, then they will be open to the remedies that could be suggested. I'd be happy to give my thoughts, but I'm with you: I'll wait and hear what others have to say first. -Chris Well, here's my first rememdy to the diatribe(s) above - Please stop clouding the Alpha issue with the final shipping issue. It's not going to make Mozilla be released any faster crying about how large the Bugzilla list should/shouldn't be. I just think that that's a very "backseat driver" attitude that helps no one. The real problem is that many people are not willing to help but complain and complain. Searching through bugzilla to help find dup-bugs and find related or possibly related or dependent bugs, doesn't even require downloading Mozilla. TuHeads I'm not complaining, I'm just saying 5k bugs sucks, and I think other people agree. That's not a complaint, just an opinion that has strong foundations in fact. Other people can disagree with this, but those people usualy hind behind the shield of 'Go build your own distro' argument. I think that the people that are trying to point out the reality of the situation ARE helping the people that want to be helped. I don't think I'd be helping ANYONE if I said 5k bugs is an ok thing and the fact that it's increasing is ok too. -Chris Is it 5000 bugs, 5000 symptoms, or 5000 reports? Are they all really open, or just not verified to be closed? How many of them are really bugs, and how many are symptoms of not-yet-implemented functionality? How many of the bugs are for marginal plaforms or experimental code? I'm not even certain 5000 real, open bugs is a large number, given the size and stage of the project, that it is developed in such an open manner, and the variety of platforms supported. The much smaller projects I have been can easily reach 100 open bugs during the pre-alpha stage. With regard to the increasing number RFE's, thats just a sign of good design. A good design make people think of what else could be done in the current framework. So, when we take a more focused perspective of the various types of reports filed under Bugzilla (actual bugs that need to be fixed, someone's personal annoyance of a feature, etc.) then maybe this discussion should be more about how a report is catagorized in Bugzilla rather than keeping a daily score of how many bugs there are. Now when can we expect to see a build that has Java support implemented for linux??? There are some Java pages I would love to try out. ...still waiting :-( Java plugin support for linux is in Mozilla, but need someone to get a Java plugin/JVM for it. http://bugzilla.mozilla.org/show_bug.cgi?id=15071 TuHeads Chris, I am curious -- on what do you base this commentary that the increase in bugs in a bad thing? It would seem to me that, since it is a pre-Alpha product, with many new features being added, it would naturally produce many bugs. Seriously, from where does this idea come? If you have experience in this area, then mention it as an example. For instance, "When I did Similar Project X, we developed X bugs at ths stage, and X-Y bugs after that, with these goals and processes in place:..." and so on. As it is, It's diffcult to understand the problems they face, from your POV, becuase we've never seen them before. Thanks for listening. ----Woodrow Woodrow, Certainly. I've been involved in 2 projects in the past year. The first project was an intranet application that would allow different internal groups to talk to each other about project specfications. Anyways, the functionality is not that important, what is important is that there were 2 major sources of 'bugs' that were found in our application. The first source was from the testing group about actual bugs in the code modules that we were wrighting. To our development team's credit, the bug count was very low because the modules' functionality were clearly defined and thus easily tested during unit testing. However, the testers who seemed to have nothing to do because the code was nice and tight, had to fill their time up with trying to improve the system's design. They would file 20 RFEs for each bug they found in the system. Sometimes a weekly meeting would just be all RFEs. This, my friends, is what we call 'scope creep' when the testers come in and want to make a better mousetrap that goes beyond the origional conception of what the application was supposed to do. I am claiming that the increase in 'bug count' (which includes new RFEs) is a bad thing because it's indicitive of either bad unit testing (which I doubt, most coders will make sure that the code does the operation properly before checking it in to source control), or from bad design (which is likely the case, if people feel that they need to submit hoardes of RFEs to improve on the origional design). This increase in bugs/RFEs is certainly a bad thing for getting the browser out the door if they haven't even FROZEN the codebase from future enhancements! There is no WAY they are going to be getting the browser out the door by 1q2000 if they haven't frozen the features from the browser by now! In anycase, my most recent project has taken extra care on designing the application components very carefully to reduce the likelyhood of RFEs, and also clearly defining modules' functionality makes it easy to test them. This is just my experience. Tell me, what has your experience been in projects that have a open functionality baselines? Did you find that you could never seem to please your client because they always wanted something different from day to day? I have, and my recommendation is that you get the needs and requirements from them completely agreed apon (signed off on) before you even begin writing software design specs. It may take longer to even begin the design phase, but it will save time in the long run. Consider this: What would have been the result if the Mozilla team took an extra 2 to 3 months evaluating what it is going to take to use the old code base instead of spendinig 12 months working with the old code base? My feeing is that after 3 months of evaluation, the would have come to the same conclusion that they did after 12 months of physical labor: They had to start over from scratch. Moral: look before you leap, even if it means looking for a long long time. -Chris Why don't you grab the source and make your own distro? Do a better job than Mozilla.org and I bet the Moz cummunity will use your distro instead. ...it's common to see these sorts of responses when you have nothing better to say about my points. Since you don't say anything to the contrary, I guess I'll take that as you agree with everything I am saying. -Chris but I don't see how your compliant is going to solve anything. As I said before, it's not a complaint. Anyways, already there has been a few in-depth responses on how the situation can be avoided. These are very thoughtful responses that address all sorts of issues. These issues wouldn't have been addressed if someone hadn't pointed them out in the first place. I think if your only contribution is to quell 'complaints' then you are certainly not helping anyone but yourself. if you don't like the 'complaints' you don't need to read them. -Chris
So, to begin the discussion of remedies for this defect problem: 1. The first step toward solving any problem is to acknowledge it. Unfortunately in software this can be the hardest step. Alcoholics are often more rational than programmers. Nuff said. 2. Cut back on the project scope. This is the no-brainer "easy answer." No one likes cutting features but it's always necessary when a project goes out of bounds. In this case, Mozilla includes side projects of questionable importance to the main browser goal, such as an HTML editor and a mail/news reader. Focusing on the main goal would displease those engineers who are working on side projects, and probably cause attrition, but even if fifty percent of them left that would still make the project more manageable logistically and give a resource boost to core components. 3. Lock out new features. Really a subset of 2. This requires management and technical leadership to be able to put their feet down when programmers follow their natural proclivity to write new, cool code instead of fixing the boring old bugs in the existing code. 4. Bug fix incentives. Bug fix bonus programs are easier to do wrong than right; I always think of Dilbert's Wally announcing "I'm gonna code me up a station wagon!" when the PHB announced a simple per-fix payment program. The best way I've seen to structure such a reward is to base the total in the general bonus pool on downward motion of the overall defect line, then incent individual contributors based on their contribution to that downward trend, weighted by severity. 5. Root cause analysis. Find out where the bugs are coming from. What components have what rate of bounced bug fixes, that is, either reported "fixes" that don't work or "fixes" that generate new problems? These components have architectural problems. Concentrate senior technical resources on analyzing those components and on seeing whether their structural problems can be fixed or whether they need to be replaced. Those are my ideas for ways to address the problem. Others? Hoping to see Mozilla ship some day, your humble servant, Echinacea Feldercarb A start to #1 would be to demonstrate that 5000 entries in the bug/rfe db is a lot for a project of this size, by comparing to other openly developed projects. I found this at Debian: http://master.debian.org/~ajt/graph.png I remember Solaris as having a similar number of open bugs for the released versions of their OS, but haven't access to it anymore. |