Slashdot Mirror
Problems With the Firefox Development Process
An anonymous reader writes "Mike
Connor, one of the core Firefox
developers, is raising a flag concerning the Mozilla Firefox
methodology of development. From his blog: "In nearly three years, we haven't built up a community of hackers around Firefox, for a myriad of reasons, and now I think were in
trouble. Of the six people who can actually review in Firefox, four are AWOL, and one doesn't do a lot of reviews." In an earlier
entry, he raised concrete concerns about the community involvement. Asa Dotzler
recently elaborated
on the process, as previously covered on Slashdot."
Seriously. Mozilla's obsessive-compulsive disorder when it comes to their trademarks is above and beyond any other open source project's, and I think it's probably turning a lot of people off toward helping them.
That's strange...
From what I read on the last Slashdot Mozilla/Firefox article, people thought that there were too many coders in Firefox, thus creating bloated code...
I guess that's a myth, eh? Community misconception?
The grandparent post (even though moderated as Troll) is somewhat correct. Firefox uses Mozilla (Gecko^H^H^H^H^HNGT) layout engine and network code, so FireFox is mostly a stripped down version of the Mozilla suite.
You can't handle the truth.
OSS projects are like any other, attracting a critical mass of developers during certain periods of time, experiencing famine during others. One of the concerns is momentum. Even when famine turns to feast, it'll still be months before major bugs have patches simply due to the familiarity curve.
If an OSS project is underfed long enough, the project becomes stale, and other projects pick up where it left off. For example, the full Mozilla suite has excellent startup time -- how long before someone realizes that revamping the GUI of the trunk (with slight repackaging) is much more sustainable than reinventing the wheel? (I know, Ff uses Gecko, but there's enough code outside of Gecko to create plenty of duplication of effort.)
it because firefox is mostly a win32 project?
yes, ther is port for many platformes but it
targeting IE replacement for windows users.
Replacing microsoft sh!t code probaly dont apprear
very exciting.
Perhaps you missed this story here, where it was found that Mozilla is actually faster than Firefox.
I think right now what is needed is a strong branding for Firefox that will create a reputation among the "tech-oriented" masses that get their information from magazines and cursory reading of pop-tech articles. How else will they truly gain ground against what many people perceive as the ONLY way to get online?
I think it's important to realize some people synonymize "The Internet" with Internet Explorer, because of IE auto-dialing, and auto connecting, as well as broad-band connections always being on and using it as default browser with windows.
Anything you do mainstream (particularly in the US) is already being done branding first and content second. Just take a look at TV.
We're dealing here with the WWW, possibly the most impressive achievement to date in terms of communication and information sharing. It's going to take some power to muddle through the masses, and you're not going to do it by sticking exclusively to principles at the expense of reaching the clueless.
The infrastructure, particularly the end-user "filter" of that information, is of critical importance. Idealism about open-source initiatives has to play tug-of-war with practical ways to get a broad following.
We are one consciousness experiencing itself subjectively. Back to you with the weather, Bob!
Didn't I read something just a little while ago about how firefox developers were intentionally keeping people out of the development inner circle?
Well, I'm contributing $10/month to the Mozilla Foundation via Paypal. You can too.
His problem seems to be with the development process of Firefox itself, not with stuff that happening in the main Mozilla trunk. For example, the following projects he doesn't have problems with: XTF, SVG, XForms, E4X, and xulrunner (lifted from the comments).
What I gather this means is that Firefox 1.1 will get some cool new backend features but that its front end stuff will remain mostly the same (excepting the preferences dialog). Is this really a bad thing?
Yes, technically they are a new code base on top of NGT, but honestly speaking it is a stripped down version of Mozilla, it runs on the same core. It is just that Mozilla is more than a stand-alone browser.
You can't handle the truth.
From the article:
Of the six people who can actually review in Firefox, four are AWOL, and one doesn't do a lot of reviews. And I'm on the verge of just walking away indefinitely, since it feels like I'm the only person who cares enough to make it an issue.
What good is people submitting patches if no one is there to review the code prior to commit? Indeed, I submitted a very trivial usability enhancement to Firefox, and it was quickly swept under the rug. Perhaps it should simply be made into a plug-in, I don't know. Just thought I would share it as first-hand experience.
- shadowmatter
Duplication. Check the bug report I mentioned - it seems to me as if vCard handling is actually pretty much there in Thunderbird but simply has no UI, so I wanted to re-use the existing code rather than create my own vCard library which would be out of sync with the rest of the code and probably would be rejected as duplicated work anyway.
Cheers,
Ian
The source code is out there. If development completely stalls on this project, maybe they should just GPL the thing and let some other group of developers take over. I'm sure there are holes in this suggestion, but it seems a sensible thing to if things really grind to a halt.
Yeah, and? The point of the question was, "Why didn't you go ahead and do what you wanted to do, rather than file a bug and wait for permission?" In cases like this (and in many things in life), it's easier to ask forgiveness than permission. If you are willing to write the code it takes to do what you want, there's a much higher chance of your bug getting noticed if it's accompanied by a patch. The patch doesn't have to be perfect code. It could be as simple as a proof of concept (though if you're going to do it, you may as well do it right). But a bug saying, "Hey, Project X needs feature Y. I'm willing to write the code. What say you?" is easily ignorable, while a bug saying, "Hey, Project X needs feature Y. Here's a patch with an implementation. Please give me feedback, and if you feel the feature is appropriate for Project X, check it into the tree," is hard to ignore. You've suggested a feature and provided an implementation all at once. The implementation may need tweaking, but the work is pretty much done, making it an easy feature request to approve.
From the bug, it seems that you got stuck on a few points and need some clarification. That's fine, but I wonder if asking that type of question within a bug is the right place to do it? Doesn't Mozilla have an IRC channel for development questions, or mailing lists for the various components? In short, that you didn't try to find the information you need elsewhere (assuming you didn't, from your posts here and in the bug) makes one question whether your commmitment to code the feature was genuine.
Fundamentally misunderstood. I'm not asking for permission, I'm trying to do the work within the existing framework. Saves everyone time, guarantees consistency in vCard import.
As for the remainder, yes - the defect tracking system is absolutely the correct place to keep discussions about the defect. IRC? Who logs that, and what if I'm hit by a bus and someone wants to finish what I'd stared? Nope, that's the entire point of bugzilla and similar systems - to keep information most local to where it's needed. A fine programming principle...
In short, that you didn't try to find the information you need elsewhere (assuming you didn't, from your posts here and in the bug) makes one question whether your commmitment to code the feature was genuine.
Well, I wasn't about to buy it an engagement ring that's for sure. How 'genuine' would be enough for you? A tattoo on my forearm? A declaration of undying commitment before a gathering of my peers? A nice romantic dinner, just me and the bug?
Or perhaps I should stick to talking about code enhancements in the enhancement/defect tracking system.
Enjoy the remainder of your aggression. Remember the point of this Slashdot thread? About how Mozilla was failing to build a community...?
Cheers,
Ian
That's so true, especially that Firefox isn't even the best browser choice on anything but Windows. There's a plethora of Gecko-based browsers available for Linux: such as Galeon or Epiphany for Gnome, or actually Konqueror for KDE, which I hear can use Gecko as a rendering engine. All these use native toolkits for displaying their user interfaces, thusly they're much faster and more look-and-feel-comformant than Firefox can ever hope to be.
(As a personal opinion: honestly, I can't see why one would want to use Firefox under Linux at all.)
we discovered a new way to think.
One maintainer for Firefox would be fine, if it were a little more modular. The problem is the same one Linus had, fairly early on. People don't scale as easily as lines of code. Basically, the Firefox code needs to be ripped into managable parcels, such that the maintenance that is done can concentrate on one parcel, rather than ALL interactions in ALL parts of the code.
Monolithic code is problematic, because for N lines of code, there are potentially !N interactions that can occur. !N gets big, very very quickly. When you use procedures wisely, then N is the number of procedures, rather than the number of lines, but it is still a VERY big number, far too big for ANY finite number of maintainers to handle sensibly.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I agree. One of the more glaringly obvious problems is using critical FOSS resources to do Microsoft's jobs for them. It's beyond crazy. Here you have a pitifully underfunded and obviously understaffed project, supposedly for free and open source software, yet devoting the lions share of effort to helping make Windows better and therefore microsoft more money. A company that could snap it's fingers and hire 500 extra full time devs tomorrow.
To anyone who is outside looking in this situation, this is just insane, this is a duh moment, but the devs and foundation on the inside refuse to see it. They refuse to see it, or maybe it's a worse situation than that, that they do see it and that's the plan, it's certainly been looking like it for a couple years now.
Who's getting bought anyway?
I've heard the arguments "well, getting people to switch browsers and office suites will lead to acceptance of....in the mysterious future". B & S. That's crap. It's pure crap. They the 99% rest of the planet "they" are still running Microsoft because they are. Look at the numbers. This is 2005. Numbers don't lie. Just because people are running FF is not meaning they are going to switch OS. You haven't gotten ONE major computer vendor to offer parity of OS platform at the retail level. There's your proof staring you in the face. This is called "failure". You've merely made it easier for Microsoft to keep being a dominant monopolist. Done it for free, too. Or it's worse than that. So what if you win a temporary browser battle if you are still tactically losing the entire computing war on the desktop? Or maybe that's been some scheme all along, a delaying tactic to let a certain billionaire catch back up? Hmm?
The FF and Moz people need to fish or cut bait, if they want a Windows browser,fine, then develop and sell a windows browser, say that outloud and be done with it. There's your money and more devs either way. It's called actually making up your mind, making a decision. If they really are concerned with open source, they will start to actually work with the true open source community and stop propping up the closed source and expensive monopoly "community" of the wonderful world of Windows. Fish or cut bait. If moz et all decide to really fish only in the open source pond they would get a lot more support, but this half way measure is ridiculous. I know I won't donate a dime as long as they keep working on the Windows versions. Let Bill Gates and the Windows users pay their meal tickets then.
Sounds to me like there is a community of hackers waiting in the wings (just have a look at the large numbers of extensions available for firefox) - its just that they haven't allowed any of them to get past the first steps and into more involved hacking
my $0.02
One of the bug posts ... was handled in an angry way....This is an extremely common phenomenon among Open Source authors.
Three words: Not enough sleep.
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
Mozilla used to be able to change themes without a restart. You'd click to change theme, and it'd change theme. However, one of the themes supplied with Mozilla used to have some kind of XUL screw up when changing over, and display two location bars. Rather than fix the problem, they simply disabled the ability of the browser to change themes on-the-fly. So to this day, you need to restart Firefox and Mozilla because they didn't want to fix a minor bug.
So yes, the themes-on-the-fly issue appears to have been swept under the rug too? Although their might've been some good technical reason for disabling instant theme-changing, I don't think it's likely.
They went for a Java model with no graphical layout tool instead of building in a VB-style GUI/code editor. I cannot hack a firefox extension easily, and I have a Ph.D in comp sci. No surprise that only the 3133T kiddies are doing it?
This reminds me of the famous Microsoft Halloween document on Linux: The MS guy *wrote a device driver * in a weekend for Linux, and then mailed his bosses that there is no such thing as a weekend device driver in NT. Well folks, for once the shoe is on the other foot !
This is not a signature.
Well it used to be, back in the Phoenix days.
Now it is bloated. ^_^ Rather ironic really.
Need help treating your acne? Come here!
Ok, what about the ad campaign funding???
.part appened, yet deleted a file w/o it.
Oh, you mean about software improvements?
Here's a serious one:
when downloading and the isp drops your dialup connection, firefox still thinks it is DL'ing, even hours later.
On a 90meg file (over 9 hours of dl'ing with earthlinks advertised 56k, 28.8 at the very best) gettng a dropped carrier at 60% reall sucks, having no resume, especially considering there is existing wget -c that simply should be called to handle such large files.
But here is the kicker:
after resuming the DL via wget -c and getting it, I then needed to dl an unrar program, upon which I found firefox still acting like it was dl'ing teh file, so I canceled it and guess what? The 90meg file vanished.
Icing on this issue:
firefox was dling a file with
IS this what is ment by community support?
Maybe not in the future.
TrollTech claims that the next version of QT will have a free Windows version. If so a Windows version of it could be available. If you get enough of the Safari improvements it could be a very good Browser.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
but built on xul, which is sort of cool XML interface, and has a lot of media coverage. Maybe the most known one outside OSS world, more than Linux.
You know, the traffic man and the weather guy from our local radio station are talking firefox.
There is a spark in every single flame bait point.
But Mozilla's problem is that they're under-manned. Where are they supposed to find spare people to hand-hold Ian ? If this RFE was a high priority someone would have already fixed it rather than waiting for Ian to slowly pick his way through the code.
.980401040150.13172A-100000%40escher.ties.org
Why is Mozilla under-manned? Because they don't help to bring new developers into the fold. The attitude seems to be "figure it out for yourself, don't bother us until you know all the basics." Not exactly welcoming. If they bothered to find someone to hand-hold Ian for a while, they might now have a new developer who would probably be happy to help hand-hold other new developers.
If manpower is an issue, turning away new developers for lack of manpower is penny wise, pound foolish, isn't it?
Mozilla's attitude problem in this respect is nothing new. This has literally been a problem since day one. Less than 24 hours after Mozilla's initial release (almost 7 years ago now), I wanted to implement an integrated, cross-platform TELNET client for Mozilla (having already implemented the TELNET protocol from scratch before), so I posted an inquiry about it:
http://groups.google.com/groups?selm=Pine.LNX.3. 96
Silence. No response whatsoever! I believe I even tried contacting existing developers using IRC as well, but nobody was interested in helping me get started working with the codebase, so I gave up. I simply did not have the time to read through 1,000,000 lines of code to figure out how to get started. Discouraged, I wandered away and found other things to do with my time.
A couple months later, I decided to try it anyway. I checked out all the code over CVS and tried to build it. All I remember is that the build took many hours on my (admittedly slow) computer, and many megabytes as well. Again, the code was too large and unwieldy to work with, and I gave up again.
Later, still wanting to help, I started reporting some bugs to Bugzilla. Over the years, I've participated in 3 dozen bugs, and originated over a dozen myself. The first bug I reported was bug #7617, "apprunner reformats during mouse click on or tabbing to link", reported June 4, 1999. This bug was later resolved as a "duplicate" of a newer bug, #28212, "{table-reflow} Clicking on URL dynamically resizes table cells", reported February 17, 2000.
Since well over 6 months had passed without the bug being fixed, in early 2000, I decided to try again to dig into the massive volume of Mozilla code, reasoning that tracking down a specific bug would allow me to ignore most of the code and focus on the part where the bug was being caused.
Unfortunately, the bug I chose (the first one I had reported) turned out to be incredibly difficult to track down, because the problem was buried in the incremental reflow code for HTML tables, and the rendering engine was extremely complex and little documented. Nevertheless, I spent countless hours tracking down this bug, and was actually getting close to understanding the source of the problem when I ran out of time to work on it. I returned to the problem a month or two later, but by that time, the bug had been closed as WORKSFORME, and the new nightly build wasn't exhibiting the behavior anymore.
Most likely, the bug wasn't actually fixed, but rather masked by the fix for bug #28522, "Clicking or tabbing to link causes incremental reflow". This is probably why the original bug was closed as WORKSFORME -- because nobody actually found and fixed the bug. This means that the incremental reflow bug probably still existed, and just wasn't obvious anymore. That bug may still exist today!
I wanted to go back and verify whether the bug was really fixed or not, but I never found the time and energy to expend on such an effort, when the bug was no longer being manifested as it once was. Regardless, this experience convinced me that Mozilla was too fast-m
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Indeed. The perceived barriers to entry are so steep that no one is willing to even try.
In my personal experience, the very first thing to do is to go out and poll the extension developers - people like Cusser, rue, MonkeeSage, Torisugari, Jesse Ruderman, the maintainers of XULPlanet, etc. and immediately empower them to review and check in patches in their respective fields.
The second thing to do is to make somebody sit down and create a Mozilla Janitors group - information on _small_, _simple_ bugs in Mozilla and Firefox that can be fixed with a minimum of effort.
The third thing to do is to allow the folks mentioned above to check in said "janitorial" patches.
After that, the MoFo folks can see if anything has improved.
SCREW THE ADS! http://adblock.mozdev.org/ Proud user of teh Fox of Fire - Registered Linux User #289618
The way people have got plugged into the development process in the past is to step up and write the big features, to prove themselves and to a good job.
Yes, I think I'm pretty good at what I do - that's mostly because of my focus on user interaction and attention to detail.
There are two models of application development when it comes to building UI:
- have a user interface design team and have the engineers be subordinate to them (this is the way most companies work)
- have engineers that are good at UI (this is the way Firefox has worked).
As I said - finding engineers to drive the latter is tough. And Mozilla is a project that likes to award a lot of power to its module owners. So yes, I am not very eager to break up Firefox into pieces and assign to people of unproven ability, because of the risk that the overall quality of the application will suffer.
Whether or not I am eager to do so, I imagine I will be breaking Firefox into chunks anyway in the coming months since my mode of implementing most of the application services for each release myself is not sustainable. How this will be managed I am not yet sure, but I will not be making a change in the structure of the project until I can be sure that the quality will be maitnained and improved.
Ben Goodger
Lead Engineer, Mozilla Firefox.