Could you please tell me more about your experience?
The core Firefox / Gecko repos can be a bit conservative and slow to accept patches, but subprojects like Firefox Accounts / Sync, Devtools, Rust / Servo, browser.html, TestPilot, etc. tend have much lower friction while still affecting the direction of Firefox.
As an example, we recently replaced the JavaScript debugger with one written in HTML instead of XUL, using React, etc. All on GitHub and super accessible to outside contributions: https://github.com/devtools-html/debugger.html
I mean, just look at the recent "3rd Generation bug" story here on HN, a bug which was originally reported by a man who is deceased, and is now affecting his grandchildren. There are plenty of 10-15 year-old bugs on Bugzilla. And we all know how Mozilla is fond of pulling the "advocacy" card and locking bug reports. "To the forums with you!" they say--where discussions can be ignored and deleted even more easily.
On the recent discussion here about the Session Saver code, one Mozilla dev said that it needs rearchitecting, but that the issue is "manpower." I don't understand how a company that rakes in hundreds of millions of dollars per year can't afford to rewrite a problematic component--they had the manpower to write the bad design in the first place. Can they not afford to hire another programmer or two? Even now that they've cancelled FxOS? Where is the money going?
And generally Mozilla is taking Firefox in a direction that loyal users--who have used Firefox for nearly two decades now!--do not want. Mozilla is chasing Chrome users, rather than maintaining Firefox's useful, unique features. They just don't get it: if people wanted to use Chrome, they'd use Chrome. If they turn Firefox into Chrome, there'll be no reason to use Firefox instead of Chrome.
The handwriting is on the wall. Mozilla is no longer focused on making the best, most user-empowering browser. They are chasing ghosts, and when the money runs out...
Sorry, I think you missed my point. Mozilla often does not handle bug reports well. This discourages users from participating. "Contribution" encompasses more than just submitting patches.
People who loved Phoenix/Firebird/Firefox lost their browser when 2.0 came out. I still trusted the project then, but in hindsight it's clear that was the turning point. They got too feature-hungry and changed too much at once, adding tons of bloat in the process. There's no well-supported multi-platform lightweight open-source browser now. Just doesn't exist. I'm hoping Servo's allowed to fill that niche at least for a while, but I'm not holding my breath.
> There are plenty of 10-15 year-old bugs on Bugzilla
How does this make it hard to contribute to Firefox? It just means that there's no guarantee that your bug will get fixed immediately?
Which ... is true for basically any open source product out there. And many closed source ones too.
I mean, yeah, it's disheartening to see your bug not get fixed. And as someone who is contributing by filing bugs and triaging, that isn't any fun. But, again, this is pretty standard for many open source projects.
> they had the manpower to write the bad design in the first place
That's not how software works. Software evolves over time, and requirements themselves change, leading to bad architecture. The session save stuff used to be json based probably because folks didn't/couldn't have that many tabs open for it to matter, but it does now.
> On the recent discussion here about the Session Saver code, one Mozilla dev said that it needs rearchitecting, but that the issue is "manpower."
This, again, has nothing to do with contributing? If anything the dev offered to mentor someone who wanted to work on it. There's activity on that bug, too, which shouldn't discourage contribution.
Bugs don't exist in a vacuum. There are priorities. And there are people who know enough to tackle the bug, who may have different priorities; you can't just randomly assign someone to a bug.
If you listened to everyone who said "you should make X your highest priority", nothing would get done.
> rather than maintaining Firefox's useful, unique features.
Example of this? I suppose you're talking about extensions here (that's the only example I can think of). There's a reason behind the direction Firefox is taking with extensions; the old extension model sucked. There was no API there, addons just reached in and tinkered with Firefox code. This means that improving Firefox by rearchitecting things was hard, for example addons were a big pain point for the electrolysis project that made firefox multiprocess. You were complaining about bad design before, this is an incredibly bad design (may have made sense at the time, but doesn't now). Fixing this involves replacing it with an API. The best direction to go in here is probably to have a standardised base for the API, which is Web Extensions. Firefox isn't planning on sticking to Chrome's feature set; it intends to make the API handle many of the needs of existing extensions. So Firefox still intends to maintain this unique feature, just in a different way.
I worked on Mozilla related tech for about eight years, mostly niche open source browsers. I couldn't even get patches that fixed known bugs that lost Firefox user data accepted. Important decisions seemed to take place in closed meetings, on closed wikis, on private IRC networks. Eventually I gave up. The Mozilla culture was insular rather than open. The further I've been from MoCo the happier I've been.
It's been a few years now, perhaps things are better? I'm not interested in returning to that world to find out.
The core Firefox / Gecko repos can be a bit conservative and slow to accept patches, but subprojects like Firefox Accounts / Sync, Devtools, Rust / Servo, browser.html, TestPilot, etc. tend have much lower friction while still affecting the direction of Firefox.
As an example, we recently replaced the JavaScript debugger with one written in HTML instead of XUL, using React, etc. All on GitHub and super accessible to outside contributions: https://github.com/devtools-html/debugger.html