Slashdot Mirror
Firefox Developer on Recruitment Policy
wikinerd writes "A Firefox developer talks about the project's controversial invitation-only developer recruitment policy and explains why Firefox will never grow up."
← Back to Stories (view on slashdot.org)
They say loudly that they are only willing to accept developers to the project that they have vetted themselves, no one need apply. And with this attitude in front of them, they drive away people who want to help but are unsure of their abilities.
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.
These anecdotes are funny, but what I wonder is... Are they different from any other development project?
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.
A Firefox developer --> actually, Blake Ross (yes, we've heard of him before, and writer of the Firefox guide book)
... developer recruitment philosophy" line is.
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
well.. if they get too elitst.. just start your own branch.
that's what being open is about..
world was created 5 seconds before this post as it is.
a project that would have stated that they accept _all_ contributions would end up as a wiki-fight rather quickly.
world was created 5 seconds before this post as it is.
The problem, of course, is that forkers often fork as an angry reaction to a rejection from the developer team without realizing what kind of commitment it is running a project. It gets worse if you try to parallel an existing project.
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.
I don't care, but don't let that stop you from trying to tell me anyway.
oh come on.
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.
Do not look at laser with remaining good eye.
It WILL show them if most users switch to your version. Which currently seems to happen with X.org vs. XFree86
C - the footgun of programming languages
Exactly... I thought "Yeah, that'd be great developing firefox." and to test out if it really was for me I decided to take the extension easy path. I wacked up the super unuseful Slashdot moderator extension then realised that even something so trival took a shit load of time.
I gave up on that dream. But at least I didn't waste anyone's time checking my dodgy patches.
Bollocks to outline, why the fucking hell can't somebody implement inline-block? It's been supported in ie for years, and it'd make the lives of every developer who's trying to stay standards compliant much, much easier.
Send lawyers, guns, and money!