Firefox Developer on Recruitment Policy 300
wikinerd writes "A Firefox developer talks about the project's controversial invitation-only developer recruitment policy and explains why Firefox will never grow up."
This discussion has been archived.
No new comments can be posted.
Firefox Developer on Recruitment Policy
Related Links Top of the: day, week, month.
New York... when civilization falls apart, remember, we were way ahead of you. - David Letterman
obligatory link (Score:5, Informative)
Re:They set themselves up in a Catch-22 (Score:3, Informative)
Fixed already, just not present in Firefox 1.0
Article two, anon karma whoring (Score:5, Informative)
Give me another project that touches the lives of millions of people worldwide and still has public codenames like "The Ocho" which get published in the media. ("The Ocho" is the name of the fictitious ESPN 8 station in Dodgeball; kudos to Ben for the flash of v1.5 naming brilliance). The best part of Firefox is that even as it's skyrocketed to the top, it's never really grown out of its humble roots as a skunkworks project that was by and large coordinated on caffeine highs at Denny's. It has, in short, never quite grown up.
Of course, it never quite dawned on us in the beginning that everything we were doing would someday be so scrutinized by the public eye. When I added "Cookies are delicious delicacies" as the tongue-in-cheek description of site cookies in our Options window, I did so because describing something so complicated in such a small space was quite frankly the last thing I wanted to worry about after rewriting the cookie manager. I didn't realize it would be archived for posterity in online encyclopedias, computer science lectures, privacy policies (for Virgin no less), magazine articles, developer documents, and even in print in an O'Reilly book called Google: The Missing Manual. I didn't realize I had singlehandedly created a cult legend that others would scramble to recreate as soon as we finally removed it right before shipping 1.0. And most of all, I never realized that one day it would inspire someone to give birth to hemp cookies. Because I assure you that had I realized any of this, I would have tried to actually create something funny. And maybe even signed my name.
This is, of course, but one case study in a project that has never taken itself seriously. What most people seemed to miss about Asa's original Firefox (then called Phoenix) roadmap was that the seemingly arbitrary milestone chart was actually a roadmap. (It does say "the trip" at top, y'know.) And if you superimposed it on top of a real map--say, around the West coast--you found that it made for a pretty clean trip from Mountain View, California to "Phoenix," Arizona. It just so happened that Netscape was based in Mountain View. It just so happened that we called it "Phoenix" because it was reborn from the ashes of a certain product. It just so happened that that product was...well, you get the picture.
Certain entrepreneurs have even tried to capitalize on Firefox's energetic demeanor. People bothered by constantly broken builds had one of two recourses depending on who broke it: violence if was me or complete public embarrassment if it was hyatt. For the young Mozilla contributor, MozillaZine offers the stylish Mozilla bib, and for his prostitute mother (or father), the thong.
Speaking of families, certain buttons began to crop up around the web urging people to download Firefox (or Firebird, as it was called then) as part of the effort to save Seth's kids. More recently, little Timmy and Jimmy Spitzer were spotted as donators to our New York Times Ad campaign. And yet, Seth claims he has no kids! Why, Seth? Why are you so ashamed?
It would be nice to claim that the silliness ends where the work begins. But it infects every part of the project, right down to our bug tracking database. Mixed among those little showstopper things like "Firefox crashes on startup" or "Firefox emailed my addressbook and attached my hard drive" are the real important issues, like Vending machine prices raised by $0.05 (as Sebastian astutely points out, that's actually not a regression but inflation), or the fact that our drag and drop code is British, or that (perhaps most famously) our core UI technology kills babies and should therefore be removed. Then there are the "oops" moments that plague every major software project: our "RSS" button looks like it says "ASS", our download manager seems to be flipping our users off, and naturally, our alternate stylesheet icon looks like the all-too-common soybean sp
Re:That's why open source is great! (Score:1, Informative)
Other groups (Score:5, Informative)
http://www.apache.org/foundation/how-it-works.htm
I think it's a pretty sensible way of doing things.
Compare this with the rather more beaurocratic Debian procedure for adding new maintainers:
http://www.debian.org/devel/join/newmaint [debian.org]
All three are certainly different projects, that require different kinds of talent and abilities, so it's likely that what works for one may not work for the others, but I think it's instructive to compare and contrast.
As far as openness, the 'meritocracy' system works fairly well if those on the inside are inclined to add others. Nothing prevents J Random Hacker from making patches or writing code. Do that successfully for a time, and you will be invited to participate.
Is it the Devs who should worry about it? (Score:5, Informative)
Keeping the file size down will not only attract those who still use dial-up, but also those who use dial-up, in most cases, have slower computers who do not have the extra RAM to spare for the extra features they don't want.
The Extensions Mirror (at http://extensionsmirror.nl/ [extensionsmirror.nl]) has over 400 extensions for Firefox 1.0 compared to the 184 that Mozilla Update hosts, as well as themes and also extensions for Thunderbird.
Every extension you could probably desire for Firefox are out there; you just need to know where to look.
With the (what seems to be) ease of creating, and the popularity of extensions for Firefox, is it really the developer's responsibility to create and implement all of the features and extras that are desired, or wouldn't it be more pertinent to have the main developers focusing on the core of the browser, its security, or other related aspects and leave the rest to the enthusiastic aspiring coders out there?
Re:They set themselves up in a Catch-22 (Score:5, Informative)
I don't think this is "elitist", I think it's practical. With every new developer on board, the task of managing the project grows. See: "The Mythical Man-Month" or any text ever written on the subject, ever.
It's a well-proven fact that adding too many developers to a project has negative effects on productivity due to the added overheads of communication, familiarization, duplication of effort, etc etc.
And it's not like the Firefox team is really shutting anybody out entirely- the source is open, after all. You're allowed to download the source and start hacking away. In fact, in a world where thousands of developers want to be part of Firefox, that might be one of the surest ways to get noticed...
Google mirror with BOTH articles (Score:3, Informative)
Re:They set themselves up in a Catch-22 (Score:2, Informative)
The problem is fixed in them (and has been for ages).
It's only the "stable" versions that have problems.
Re:They set themselves up in a Catch-22 (Score:3, Informative)
Re:They set themselves up in a Catch-22 (Score:5, Informative)
Re:obligatory link (Score:3, Informative)
Re:They set themselves up in a Catch-22 (Score:3, Informative)
It was fixed in 2004-05 on the trunk and is now in Firefox builds.
Re:They set themselves up in a Catch-22 (Score:5, Informative)
Since there seem to be people confused: it's purely a bug with Gecko. It's not a bug with Slashdot's HTML. Slashdot's HTML is fine[1].
The problem is hard to demonstrate, because it's a timing issue. In order for it to trigger, you need to have downloaded enough of the page to have received only the left column, but not the content column, when the browser does an initial layout. Gecko lays out the column and makes it as wide as the page, because that's what the HTML to that point says to do.[2]
After that, it starts getting the content. Depending on exactly how you trigger the bug, two things can happen. One; it can not resize the left column's width properly, making the column take up the entire page. (Strangely enough, it gets the scrolling information correct, so you can't scroll horizontally to see the content you're missing.) Two; it can layout the column so that the width it uses when laying out the content column is too narrow, making the two overlap in the final rendering.
Basically, it's a real bug in Gecko. It happens to be triggered by Slashdot's crappy HTML, but it really is a bug in the incremental layout engine.
[1] Well, no, it isn't - it's written in such a way that it triggers the bug. But it's fine in the sense that what's wrong with it shouldn't cause the problem. Slashdot's HTML is bad enough that Slashdot 403s connections from the W3C HTML validator.
[2] It's this "column resizes wildly during incremental layout" that sort of makes this Slashdot's problem. If they specified the width exactly instead of relying on the browser to implicitly shrink the column to the width you're used to, you wouldn't see this bug.
About Firefox and Mozilla (Score:5, Informative)
From day one, Firefox was l33t. For many, the developers that went off on their own were impatient and unwilling to follow the rules. During the time just before (and during) the breakup, there were many questionable checkins that did not go through proper channels. At mozilla, decisions are made by the community, or at least the part of the community that has seniority in that area of the code. When a bunch of people in a code area all have relatively the same seniority, drastic changes are often met with negativity. This was especially the case with UI and the related XUL stuff. Perhaps it also has something to do with Netscape, who used to have a stranglehold on the UI, but I'm rather unclear on that aspect.
When the Firefox people split off on their own, I personally was a bit relieved to get rid of the "too good for rules" people. It certainly created a divide in the community. The lean, l33t Firefox developers were on a power orgie, doing all the changes they, for so long, wanted to do. Most of them were awesome ideas, as everyone can see by what Firefox is today. Some of the stuff has even creeped back into mozilla, after it was matured enough in Firefox, that is.
Which brings us to another issue that divided the two sides -- the Firefox team, at least at the beggining, was more of a "Do a half job, commit it to CVS, then fix it up in stages" team. I do not know what they do present day. The mozilla team is a "make sure the patch does a specific task, is correct and complete before commiting", which requires a lot more time, a lot more reviews, and a much bigger delay before the public sees your 'kewl new change/fix'. There are many projects that follow either type of philosophy. Neither is incorrect (both philosophies can and do work), but a project obviously can't follow both philosophies.
As many slashdotters love to say, the great thing about open source is that if you don't like what the developers are doing, or you don't like the developers, or you don't like the atmosphere, etc, you can take the source and make your own branch. This is exactly what Firefox did, and good for them. The difference between them and a normal 'branch-and-do-your-own-thing' is that the l33t developers were also high up mozilla developers/PR/etc. This created a unique situation where the two projects had to stick together. Even to this day, the relationship between Mozilla and Firefox is an issue to avoid discussing in public with developers (because, out of politeness, they won't talk about it).
Ever since Firefox has become popular, I hear people occasionally say, "is this the last release of mozilla?" The answer is _NO_. Mozilla is the heart of Firefox. The people who are developing for mozilla are dedicated and have no plans of leaving. For some, bitterness about the invite-only and l33t feel of Firefox only invigorates them to do more for mozilla.
Also, I see a lot of posts on this thread saying "Maybe if Firefox wasn't soo l33t with its developers, blahblah bug would be fixed, or blahblah would be supported!" You couldn't be more wrong. 99% of the time, the proper place to add/fix 'blahblah' is in Mozilla, not Firefox. If anything, you should be blaming the bureaucracy of mozilla, not the l33t Firefox developers.
If you want to call the Firefox developers 'rebels', that might be a good term too. I think of them more as 'l33t immature, arrogant developers who got tired of the bureaucracy of mozilla'. We can all be immature and arrogant on occasion, so I try not to hold it against them.
I encourage any other Firefox/Mozilla developers to clarify and/or correct what I've said.
Controversial? (Score:5, Informative)
Why exactly is this controversial? Gentoo does exactly this. Just because you have an invitation-only developer recruitment policy doesn't mean that you won't accept patches from others. With Gentoo, we receive patches all the time that make it into the distribution. That doesn't make the patch submitter a developer, but at the same time we don't deny patches simply because the person is not a developer. After the person has shown their worth, they are recruited by a more senior developer on the project and trained in proper Gentoo development policy. Why would it be controversial at all to only allow people whom have shown compitence to have write access to your CVS tree? As I've said, we receive patches from people all the time. Some of them are even first time Linux users who know little to nothing about development, but if the patch is correct, we accept it without passing judgement on the person submitting the patch. I'm not sure where the idea comes from that only accepting good patches is elitist, but how would doing anything contrary make the slightest bit of sense.
Re:Open Source? (Score:3, Informative)
A quick Googling suggest that inline-block is actually a W3C suggestion. It has not been accepted as a standard yet, and as usual IE has its own ideas of how to implement it.
So while it might be handy to have inline-block, you can't slam Firefox as non-standard for not implementing it yet.
Re:Debian (Score:2, Informative)
I think it was a technical reason not completing NM process which requires rigourous packaging skill demonstration. Neither had time or interests to do that kind of technical work. (I am sure they had more interesting works for them. Many aspects of the packaging may not be interesting for upstream author. But we need to have some consistency here.)
I think we still have packages with NW and RMS as the upstream and they are helping us a lot.
I was sad to hear Norm Walsh decided not to join Debian but please do not twist the story and spread *untruth*.
NM process is the best compromise we found now. With diverse members across the world, it is not easy to make quck decision on the membership for whom we give full root access to everyone's box through packaging tools.
ciao.
No elitisim - even the lead does patches! (Score:3, Informative)
EVERYONE, including the project lead, pulls source from CVS, creates patches, uploads them to Bugzilla, has them reviewed by another (trusted) team member, and then approved by the person responsible for a branch. At that point, someone with CVS access is permitted to commit them to CVS.
If you do not have CVS commit access yourself, you follow the exact same procedure as someone who does right up to the point of doing the commit itself. After having done a few of these, you just have to have someone in the project vouch for you AND SIGN AN AGREEMENT and you can get CVS commit access.
This is not a barrier at all.
Re:Then what exactly is Open ? (Score:4, Informative)
Linus should run some form of shared access, where he has lots of people who can commit code directly the the Linux source tree without Linus having to see it.
Presumable a more "FreeBSD" or Debian like system. FreeBSD is a lot closer to a meritocracy then Linux's "Benevolent dictator" system. FreeBSD has a core group of whom several (5-10) people can get access to the actual source repository. Supposedly FreeBSD is fairly elitiest and tight knit (think XFree86, they have roughly the same governance model as FreeBSD, but XFree86 sounds like a lot more of an old boys club them FreeBSD is).
Debian has a system where they are fairly democratic, and have a process where by you can initiate referendums to vote on a change you feel is important enough (generally never done over source code, but has been done over which version of the Linux kernel to ship, and what types of stuff has to be stripped from the Linux kernel before it meets Debian's definition of "Free").
Linus is a dictator of the stock Linux kernel. However, there are so many forks out there of different trees, where lots of people have access to those trees that it's relatively silly to discuss. The other interesting aspect, is I get the distinct impression that in lots of areas of the kernel, Linus does implicitly let people just randomly apply patches. If you are one of the people he trusts working on an area he feels you know best about, he just applies your patches with minimal if any review. You don't get access to his primary sources to do the patch yourself, but you get a relatively unfettered access to the areas you know about. Which is sorta nice, as well, you don't see the kinds of spats that spawned OpenBSD (CVS revision wars, where people undo others work because they disagree, and they have access). When there is a single arbitor of what gets access, it never seems like there are people of two minds in control of the source.
It's like the age old argument, that a Monarchy is the best form of government assuming you have a good and fair king. It's also the worst kind of government if you have a despot. Unfortunatly hereditary monarchies generate a lot more bad kings then good ones.
Kirby
Re:obligatory link (Score:3, Informative)
Now it seems (and I can't verify this) that the number to unlock features is no longer 45. I think it's been lowered, and therefore the problem is less of a problem than it used to be.
But don't make the mistake of assuming that people complaining about unfair karma tracking are always complaining about popularity. Sometimes they are complaining about being locked out of features.