I find it hard to believe you don't know that casually contributing to Firefox is ridiculously hard. The build system is borderline insane, building takes hours, and most importantly people who can approve your changes clearly have more important things to do and regularly fail to answer. I have tried contributing a couple of times. Thank you, no more.

I casually contribute to Firefox and it's not ridiculously hard. It is a somewhat steep learning curve if you contribute for the first time, primarily getting acquainted to the build system, the area of the code you're fixing, and then finding the right people to nag about reviews, but it is far from ridiculously hard.

It used to be ridiculously hard, back in the days of hq merge queues or even cvs, I give you that, but the general build stuff improved a lot since then.

The build system is hg clone/git clone + ./mach bootstrap + ./mach build... And there is a lot of docs for it too. I wouldn't call that "borderline insane".

Submitting a patch for review is a only moz-phab command away (after you set it up once, which took me under half an hour).

A full build on a slow machine can take hours indeed (on my 2015 macbook it takes about about 2 hours I think, but my beefy desktop finishes in under one hour). But you often do not even need a full build, but an artifact build[1], which brings it down to a few minutes and just a few seconds on rebuilds (./mach build faster).

>and most importantly people who can approve your changes clearly have more important things to do and regularly fail to answer.

Now that's actually a problem. It's usually not that they are too busy to respond, but that they do not read their bug mail (because they get thousands of emails a day). That's why you either have to actually request a review or need-info them on bugzilla. That usually draws their attention, simply because review requests are listed in a neat list and need-info-s are listed in another neat list, and if that still fails to grab attention, there is enough folks on the irc channels who can either help you directly or point you in the right direction.

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g...

PS: Here is a guide to the process of submitting a patch:

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g...

./mach bootstrap will usually help you set up your environment mostly automated after some confirmations, and will ask you if you want to do full builds or artifact builds, too

A general build guide is available too: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g...

Compared to other software of similar complexity I think standing up a Firefox build is actually pretty reasonable. The bootstrap instructions are not complicated (https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g...) and the build takes about an hour on my laptop. Chrome is certainly a lot harder and takes significantly longer (if you lack access to Google's internal build farm). Likewise the Linux kernel is also tricky and slow to build the first time.

I have found contributing to the linux kernel a significantly more pleasant experience than contributing to Firefox.

I have no trouble believing that contributing to Chrome is even harder, but then again I didn't hear someone from Google saying "If you think a bug is easy to fix, pleasez consider providing a patch."

> then again I didn't hear someone from Google saying ...

Is that a good thing?

I mean, Google doesn't even pretend to be open to community contributions. Pretty much every choice they make is tailored to googlers only, just look at their build systems. They're upfront about it which I think prevents me from complaining about how hard is to contribute.

I'll take Mozilla over Google every day, but if Mozilla presents itself as open to community, it also lends itself to criticism that Google avoids altogether.

It's actually documented that Firefox does have outside contributors, even people writing code: https://blog.mozilla.org/community/2019/04/30/firefox-67-new...

So yes, that happens, and if that's not as easy as we could have hoped, probably help is welcome with that as well.

Big and complex projects generally have higher standard of effort necessary to get the leg in. The comparison to Chrome was that it's a project comparable in complexity, and yet Firefox is easier and faster to build.

Yes.

I've submitted many browser bug reports to Google, Microsoft, Apple and Mozilla over many years. I only bother to submit issues for "important" bugs, I write clearly, I simplify, and I spend significant time ensuring that the bug report is useful to developers and relevant for users.

Google respects my efforts, and often fixes my reported issues, or at least explains why it can't be fixed (usually with well reasoned answers, usually the actual developer is communicating with me).

Microsoft/Apple/Mozilla waste my time, ignore my efforts, and generally that results in a poorer user experience in the browser.

The Chrome team is one of the most amazing software teams I have ever been tangentially involved with - and the product quality shines.

Thank you for outlining this.

Maybe someone from Mozilla's community outreach can comment and ultimately make some improvements.

Specific examples of said bug reports would probably help, though.

I suggest Mozilla look at the last 6 months of bugs submitted and do some analysis on them.

Ideally take a subsample and talk to the submitters, and see what they think.

If Mozilla agree that Google do a better job than Mozilla, then benchmark against them.

I eventually stopped reporting bugs to Mozilla, Microsoft and Apple unless I absolutely had to. I recently stopped working with browsers, so I no longer have much appetite for helping.

Personally, I've found it easier to contribute to Firefox than it is to contribute to, say, LLVM.

> Out of every 100 tickets, there is 50 people who believe theirs is the most important one

I would put the number more at 99 with a 1% error in that figure