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?
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!
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
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.
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)
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