Slashdot Log In
Firefox Developer on Recruitment Policy
Posted by
michael
on Mon Jan 31, 2005 05:05 AM
from the cathedral-or-bazaar dept.
from the cathedral-or-bazaar dept.
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.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
obligatory link (Score:5, Informative)
Re:obligatory link (Score:5, Funny)
Technically, posting a mirror is informative redundancy.
Parent
Re:obligatory link (Score:5, Funny)
Parent
Re:obligatory link (Score:4, Insightful)
And so what if the author of the post gets a few karma points.
Parent
Re:obligatory link (Score:5, Funny)
What has Slashdot come to, when people will try to whore Karma by actually, you know, posting something useful?
Parent
Then what exactly is Open ? (Score:5, Interesting)
Hopefully firefox will not go into that Elitist arena which blocks out young developers...
All that said, I had to work for 3 months almost full time to get commit access on what I work on . But we've had a guy who would steam roll the patch database with useless patches and report all kinds of pedantic bugs to pester us into giving commit access (and for his notice, that doesn't get you anywhere).
A single strategy doesn't work for all types
Re:Then what exactly is Open ? (Score:5, Insightful)
that's what being open is about..
Parent
Re:Then what exactly is Open ? (Score:5, Funny)
Parent
Re:Then what exactly is Open ? (Score:5, Insightful)
Parent
Re:XFree is still at it? (Score:4, Interesting)
The Cygwin folks already had to fork XFree because of the orgainization's refusal to accept patches. And Cygwin was far from being the only ones annoyed with XFree. It was just easier for distros to stick with XFree instead of maintaining their own, and causing a political mess.
The license change was merely the last straw, and was very indicative of how XFree operated. By unilaterally changing the license, then refusing to work with the people who ship their product on fixing it, they showed an even higher level of elitism than before. By this time there was a large enough group X11 developers that were doing great work, but not part of XFree (mainly Keith Packard), that the distros had somewhere else to turn.
So it was more than a simple license change I'm afraid. They kept some of the best developers doing the most innovative work outside of the group, and alienated the very people who distributed their product. Their own elitism made them completely irrelivant in the development of X11, which was supposed to be the entire purpose for XFree's existance.
It is not impossible that this could happen to Firefox too, but right now they are the main drivers in the browser market, and generally are keeping their use base happy. No reason to worry quite yet.
Parent
Re:Then what exactly is Open ? (Score:5, Funny)
Hopefully firefox will not go into that Elitist arena which blocks out young developers...
You were NOT invited to make that comment, if we want to hear from you we'll call you and then you can speak, otherwise just keep reading and shut up, mkay?
Yours,
The FireTrucks Team,
Peak View,
CA 31337
Parent
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
Parent
They set themselves up in a Catch-22 (Score:5, Insightful)
Then they say that they want people to submit patches and pitch in to help develop the product. But how is anyone supposed to do that without being a member? Well, obviously you don't have to be on the team to work for the team. But who wants to work for someone that isn't going to treat them as part of the same team?
At this point, the Firefox team is pretty well entrenched and the product itself is doing fairly well (still can't parse Slash code for shit, but that's just a hurdle to be overcome soon). So for this particular project, a thorny attitude towards newbs is not going to hurt them very much.
However, the spirit of OSS (at least on the BSD side of the world) is one of openness and acceptance. Turning people away or accepting a new member only through invitation smacks of elitism. Unfortunately when you deal with human beings, you will inevitably end up dealing with some who think themselves elite and worthy of looking down upon others from the heights of their snoots.
Re:They set themselves up in a Catch-22 (Score:3, Interesting)
Well they're not gonna give every single person out there commit access to the repository, are they? If you want to be able to directly change a section of the code, you need to prove your abilities. Which is fair enough.
Re:They set themselves up in a Catch-22 (Score:5, Insightful)
However, the way they present it is that if you want to contribute, well, tough. You gotta be part of the team, and this is an invitation-only club. So someone comes along and says, "Hey, I'd like to have feature X work. How can I contribute?" And the website says "Fuck off, you're not wanted here." So he says, "Well, screw it. It probably wasn't a good idea in the first place." And then the project loses out on what might be a good feature.
They say "Members only" and "Please help us" simultaneously. Mixed signals, to say the least.
If it requires an article of that length to be written clarifying what really ought to be a straightforward issue, then the people who presented the it are at fault for clouding the issue.
Parent
Re:They set themselves up in a Catch-22 (Score:3, Funny)
Seems to me, if you're unsure of your abilities, you should start on a smaller project with less visibility than FireFox. If a certain 'elitist' attitude is needed to filter out the rotten apples (e.g. the Linux kernel moderation approach), then this might explain
Re:They set themselves up in a Catch-22 (Score:5, Insightful)
There's no reason not to try. Your fixes will either work or they won't. If they don't, you've bitten off more than you can chew, so you abandon them. Wasted a bit of time, but you know your limits. If they do work then you've pushed yourself, improved yourself and proven to yourself that you're that good. And helped the project along.
Parent
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.
Parent
Re:Other groups (Score:4, Interesting)
After all, not everyone in Debian are the smartest coder.
Firefox actually want the 'smartest coders' that work with their codebase.
While it is certainly elitist, it makes sure that only the elite (dedication plus skill) get to work on their branch of the browser. If that ends up making it work faster, more robustly and more efficiently, then all to the better.
A small team of highly skilled individuals can often achieve more than a large pool of medium skilled people, and usually far more than a huge team of mediocrely skilled people.
Everyone they compete with (corporate entities, such as MS and Opera) is pretty much guaranteed to be elitist (they'll hire the best coders and designers they can at interview), so why shouldn't the firefox team?
Of course, as has been noted, if you think you can do better with your choice of team recruitment, then fork the project, and see which one survives.
Parent
Re:They set themselves up in a Catch-22 (Score:5, Insightful)
You do realise that's a problem* with the Gecko rendering engine, not Firefox, right?
*To pedants: yeah, it's really a problem with Slashdot's implementation of Slash code. But at this point, I think it would be easier to fix Gecko than to fix Slashdot.
p
Parent
Re:They set themselves up in a Catch-22 (Score:5, Funny)
Parent
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.
Parent
Re:They set themselves up in a Catch-22 (Score:4, Insightful)
I'd rather see them stick to standards than implement hacks for every website's broken HTML.
Parent
Re:They set themselves up in a Catch-22 (Score:4, Interesting)
Openness, huh?
I always thought open source meant the source was free to be used, modified, imnproved and adapted. It does not, to my recollection, mean that those maintaining a given heap o' code have to take "all comers", or even have to have a formal mechanism in place to consider adding to their number.
I don't know what kinds of projects y'all work on, but where I come from, when someone comes up asking to join a project, or asks for collaboration, in the name of "The community", "the open source ideal", or other high-falutin' sounds, it usually boils down to one of a series of options:
A) Can you give me lessons?
B) Can you spend time working on my project?
C) Can I boost my own social position by claiming to work for you guys?
If you have the luxury of an abundance of people who want to work on your free project, you pick the ones who are most capable of doing work with the least amount of management. Going through a list of submitted applications is not the most efficient way to do this. You find who's doing good work, and talk them into working for you.
If someone has a brilliant vision for OSS, that person is usually better served realizing that vision in a dedicate project. Giants on the shoulders of dwarves.
Parent
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...
Parent
Re:They set themselves up in a Catch-22 (Score:4, Insightful)
Nothing in The Mythical Man-Month is "well proven fact", it's all anecdotal evidence regarding an ancient project. It's a great book, but it's not necessarily gospel truth, and it doesn't apply to every project ever conceived by man.
I think it mostly DOES apply in Mozilla's case, but people cite it a little too blindly, as if a small team could create a Saturn V or Windows NT or something if they were just REALLY SMART and put in a lot of overtime.
Parent
Volunteering sucks (Score:4, Insightful)
1. You don't get paid, that's why its called volunteering.
2. Nobody respects you. This is the worst problem, it's simple really. If an organization doesn't value your help, working for them will be much harder than if you were getting paid.
Case in point: Try to fix phone lines for a local nonprofit. I end up standing around for 30 minutes to talk to a decision maker, only to be passed by someone with no apparent contribution. If I was on the clock, they would have respected my time if not only to avoid high fees.
Parent
Re:They set themselves up in a Catch-22 (Score:5, Informative)
Parent
Re:They set themselves up in a Catch-22 (Score:4, Interesting)
Then the next bug I simply file the report, ask if its valid, and if so submit the patch to bugzilla again. Once this happens a few times it becomes more time consuming to manage my contributions than to let me contribute directly, and I usually get requested to commit directly to cvs. I actually prefer not to have that burdeon/responsibility
Parent
That's why open source is great! (Score:3, Insightful)
Re:That's why open source is great! (Score:4, Insightful)
In order for a fork of Firefox to be successful, you'd have to gather a team of developers, and actually find your own means to decide who gets access and who doesn't, but you'd also have to merge all the changes going into Firefox's own tree at the same time as you accept lots of contributions from your fork community (assuming you get enough press to be receiving any).
I think a further complication is that sometimes with these forks, the mindset of being more open lets contributors get patches through with less quality control, leading to a product which fails to offer the same degree of stability and code quality as the original project.
Xorg seems to be a decent example of a fork team that got these problems reasonably ironed out. Perhaps they're a good place to turn for advise for people serious about forking a major project.
Parent
Re:That's why open source is great! (Score:5, Insightful)
I know what point you are making but all that ends up being is a pissing contest and nothing real will get done.
if a developer is such a prick that refuses to submit a bugfix or patch to one of the top people of a project that have that access then his attitude and code really needs to go elsewhere.
Come on, is writing a Open source app a community development effort or is it a "you will not give me god access??? fine I'll go and fork the project!"
90% of all forks die without anyone knowing they existed, look on sourceforge, for every app that exists there are at least 60 forks that either never made it past their initial CVS commit or NEVER even had a CVS commit.
There is a reason to fork, Xfree86 was a reason to fork. But just because someone will not be granted CVS commit access is certianly not a reason.
Also, what is wrong with putting your patches on your own pages??
I use kernel patches that are not part of the main kernel tree, hell Linus would not accept the pretty boot screen for the linux kernel for years so many of us used one of the several projects that had their own patches.
Look what happened, a superior way of making the boot screen not horibly-scary to 90% of the world was born and accepted into the kernel.
People that control a project, espically a HUGE project need to say NO automatically to everything first. Because for every talented and good patch submitted, there are 30-50 piles of crap, blatent trojan attempts, and a couple of outright wrong submissions sent.
I understand your point, and I agree with you. But most fporks are not for a real reason, that is why they die without a whimper except for the pissing contest on the origional mailing list.
Parent
Why would they need to 'grow up'? (Score:5, Insightful)
Every development project I worked on, the developpers included some form of easter eggs or witty comments in the code. It's human nature to have fun, and it happens in OSS and at Microsoft.
I think perhaps the only differences are 1) FireFox code gets seen by the world, whereas non-OSS comments are hidden for the most part; and 2) Quality Control usually catches stuff like the 'cookie description' in time for public consumption.
Hey, it's great that FireFox was born in a fun environment, but I think it's just human nature to make 'work' as pleasant as possible. It's great in the case of FireFox that the 'community' gets to share in the fun.
Re:Why would they need to 'grow up'? (Score:5, Interesting)
Presentation is going well. Price points get a big eyebrow raise. Lead-in time is great. Non-proprietary is great. All good things.
Question and answer period goes all to shit. Made the mistake of referencing "GNU/Linux". My bad. What does the G-N-U stand for? GNU is Not Unix. What's that now? Huh? Ohh.. I see. What's this other acronym? KDE? Is that like CDE, which we use now? Ohh yes, but much better. Sure, let's take a look. Client clicks around on the laptop for a few seconds.. boom boom boom.. hits a panel that reports "Not finished yet. I'm too lazy
What a disaster. I was mortified. He picked apart all kinds of the typical Linux stuff.
In the end he went to another consultant and stuck straight to Windows. It was very embarrasing.
The bottom line is that in the real world, no one cares about having the source available. The investment is very small. If Firefox dies, what, are they going to hire a programmer to keep it alive so they dont have to switch? Lets get real. Trying to pitch anything but a polished product is, well, just asking for a beating.
Parent
The great thing about open source (Score:3, Interesting)
Only if the developers think you're good enough of course.
Re:The great thing about open source (Score:5, Insightful)
Parent
Clarifications (Score:5, Insightful)
why Firefox will never grow up --> from the article, "Firefox is growing and maturing--there's no question about it. But as long as we're around, it'll never fully grow up. So sit back, relax, and await the delicious delicacies that The Ocho will have to offer."
Website has gone down, so not sure how inflamatory the "controversial
Devs do not care for enterprise features (Score:4, Interesting)
Re:Devs do not care for enterprise features (Score:5, Interesting)
The extension system is integrated into Firefox and designed to be used. The real problem with the Kiosk mode is that that extension looks like it hasn't been kept up-to-date/has ceased development.
In the future (maybe 1.1), I think the Firefox developers will probably include the most popular extensions in the Firefox installer to make it even easier to do additional stuff like this.
Parent
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?
Parent
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
Open Source? (Score:5, Interesting)
Why then, after 5 (almost 6) years, is the outline property in CSS not supported? Why is there no one able to fully implement this? Yes, I know about -moz-outline, but it's -moz-outline because they don't trust their own code enough after 5 years.
https://bugzilla.mozilla.org/show_bug.cgi?id=6647
Re:Open Source? (Score:5, Insightful)
Parent
pet peeve (Score:5, Interesting)
It's bug 188285. Have a look if you're interested.
Re:pet peeve (Score:4, Funny)
On slashdot, if you say "When I'm driving around in my car, this buzzer won't turn off and it's really annoying." everyone will respond with "Well then just turn the car off."
Parent
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.
That kind of policy... (Score:4, Insightful)
In fact, I'd go so far as to say that if it really a meritocracy (or a project which really understood what free software is about), there wouldn't be such a clear distinction between developers and users, anyway. All that really can be observed HERE is a kind of "ivory tower" elitist attitude that will ultimately hinder rather than help; people seem to be afraid to actually have an open development process as soon as projects grow larger or get a larger (and, in particular, a larger non-geek) userbase, but I think Linus' success with Linux' development model shows that this is not a reasonable thing.
Ever wondered why Linux actually *is* more successful than the various BSDs, and why (for that matter) hundreds of Linux distros coexist in peace while the *BSD developers generally seem to be unable to even talk to each other? It's not just because the majority of people are more inclined to contribute to a project that not only is free but *stays* free; it's also because with Linux, when you scratch your itch, you have a good chance of it actually being picked up, used and included into their trees by others, ultimately even Linus, as long as you're willing to demonstrate you're actually willing to maintain your code for longer than a few weeks.
The Xfree86 vs. X.org schism is another good example: people used Xfree86 because there was no real alternative, but they weren't happy with it and with the fact that the developers cared so little for the users and instead chose to form an elitist club of their own, so when an alternative popped up, they started using that. Can you name a major Linux distro that still uses Xfree86 instead of X.org? There may be a few left, particularly those that are more conservative about these things (like Debian, although I haven't checked which implementation they use), but I think it's safe to say that the majority has already switched, and that this trend will only continue in the future unless the Xfree86 developers radically rethink their attitude.
As for Firefox (or Mozilla in general) again, I can't say I'm too surprised, though. They have had this attitude forever (if you ever reported a bug, you'll know what I mean; if you don't, check out bug 18574 [mozilla.org], for example), and I think it's reasonably safe to say that people are using Mozilla mostly because there's no real alternative (IE decidedly is not one, and it's windows-only, anyway; Opera is not free and has banner ads unless you pay for it, and Konqueror is integrated too much with KDE for some people's taste, not to mention that not running on windows means a good share of Mozilla users can't use it, anyway). As soon as a new, better browser project gains ground, Mozilla will find itself in the same situation that Xfree86 is in today. It may be less serious, since it's more easy to include two browsers with your distro than two X servers, but ultimately, it's adapt or die, and I think some Mozilla people (asa comes to mind, as do some others) will have to learn that the hard way.
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:What about plugins? (Score:5, Insightful)
I gave up on that dream. But at least I didn't waste anyone's time checking my dodgy patches.
Parent
Re:Not surprised by these California political gam (Score:4, Insightful)
If you limit the developers to people who actually like working together, and have simular ideas of how to behave and talk to other people, more can often be done than if you also invite all the socially dysfunct coders, who cannot take a rejection of patch as anything but a personal insult (or, for the true nutcase, some political game).
There are more than a couple of great coders out there with zero people skill. They can damage a project because, even though their own contributions are great, they lower the fun level and therefore productivity of everybody else.
Some of them make great solo projects...
Parent