
Contributing to the Mozilla code base - new_here
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction
======
userbinator
Several years ago I did want to fix something in Firefox, and it was far
easier to just patch a few bytes in the binary (I think it might've been a
string constant) than go through the whole build process with all the
resources that takes, including trying to find where in the original source to
actually make the change, and then still have a totally different binary than
the one you wanted to fix, with other (bug-causing) changes you _didn 't_ want
due to the different environment you built it in.

Of course, if you try to fix/revert something that was purposely broken or
removed for some Mozilla reason, it is not going to accept your changes
either.

One of the ideals of open-source was to make it easy to modify and share
software. For a lot of the larger projects, I feel like that has missed the
mark. I write (mostly small and always portable) software, yet the "build
bloat" is a huge turn-off. On the other hand, I've had good experience with
the smaller open-source projects, those that need a minimal amount of tooling
and resources to build. Some examples I can think of include libpng, zlib, and
even OpenSSL.

~~~
gwbas1c
Honestly, this shows why projects of major complexity need professional full-
time developers.

I think it also shows a very minor flaw in the open source / pull request
process: Expecting _casual_ and _amateur_ contributors to work at the same
level as a professional who works with a given codebase on a daily basis is
unreasonable.

In my day-to-day job, sometimes I can fix a bug in an hour, but then I need
the rest of the day to update tests, avoid regressions, and think through my
fix to make sure it's long-term maintainable / readable / performant. Even
more important, if I'm working with code that I don't usually touch, I have to
make sure I follow the expected conventions that everyone else expects; and I
have to be much more careful about assumptions that I haven't learned yet.

So, a 1-hour fix easily balloons into 5-15 hours!

Perhaps the easiest way to encourage new contributors, who are assumed to be
casual, is to encourage incomplete and partial fixes that the main team
completes?

~~~
Crinus
> Honestly, this shows why projects of major complexity need professional
> full-time developers.

I think the opposite, it shows why projects that care about the practical side
of open source and free software should always have in mind their
"hackability" from regular developers.

I remember a case where RMS didn't want to make some change in a project (i
think it was Emacs) because it would make the project harder for people who
didn't work on it to understand it.

And it makes sense, if you believe that what makes FLOSS good is that anyone
could change and/or improve it, then it follows that you should try to
maximize the pool of that "anyone".

~~~
levythe
You could easily make an argument that the same philosophy will benefit
rapidly growing projects for full time devs. The less "arcane" knowledge
needed to work effectively in the code base, the faster new engineers can
onboard, the faster old code can have small changes made without breaking
something else unexpectedly, and the list goes on.

~~~
hrktb
Wouldn’t it be inversely proportional to the complexity allowed in the project
?

I imagine for instance a situation where for instance the project starts with
a clear REST approach where GET requests are purely idempotent with no side
effects whatsoever.

Then people start adding internal side effects (e.g. tracking, behavior
scoring, suggestion building, and so on).

It’s harder to explain to a new dev that from some angle these requests are
read only and nothing changes, and from another angle they change a lot of
things.

But it would be counter productive to give up on features because it makes
things less simple and brings a learning curve.

------
bovine3dom
Some shameless begging: if anyone picked up
[https://github.com/tridactyl/keyboard-
api](https://github.com/tridactyl/keyboard-api), it would make Vimperator-
style WebExtensions much better as we'd be able to respond to user input
everywhere in Firefox. We haven't been able to find the time to work on it.
I'd be delighted to help anyone who was interested get started.

~~~
imvetri
Same here [https://github.com/imvetri/ui-
editor](https://github.com/imvetri/ui-editor)

------
piotrkubisa
Is this article a bit outdated? I have noticed some projects not only switched
their repositories but also programming languages i.e.:

> If you know Python, you can contribute to our web services, including
> Firefox Sync, or Firefox Accounts

Not quite recently (about 6-7 months ago), the syncserver got rewritten to
Rust [0], while the Python codebase it's a bit stalled [1]. I guess Mozilla is
going to switch to syncserver-rs soon, because they started implementation of
Google Cloud Spanner and this looks like a green-light for future deployment.

> If you know Java, you can contribute to Firefox on Android, Firefox Focus
> for Android and Firefox for Fire TV.

There is new Firefox Preview on Android, which might disrupt the mobile
browser market share soon (if it gets addons support). Some mozillian also
worked on projects like Lockwise [2] or Firefox Notes [3] which are written in
Kotlin, not Java.

Please, do update this article.

[0]: [https://github.com/mozilla-services/syncstorage-
rs/commits/m...](https://github.com/mozilla-services/syncstorage-
rs/commits/master)

[1]: [https://github.com/mozilla-
services/syncserver/commits/maste...](https://github.com/mozilla-
services/syncserver/commits/master)

[2]: [https://lockwise.firefox.com/](https://lockwise.firefox.com/)

[3]: [https://addons.mozilla.org/en-US/firefox/addon/notes-by-
fire...](https://addons.mozilla.org/en-US/firefox/addon/notes-by-firefox/)

~~~
abbe98
The article is maintained by volunteers and there is a large edit button that
anyone can click.

------
kentrado
I got interested in contributing to Firefox in the hopes that it would lead to
a job.

My thought was since obviously I could do the job, then they would hire me
without having to go through the usual interviewing steps.

Every time I have applied, I never got pass the recruiter. Never got a call to
talk about my patches, just a generic rejection response.

Then I realized that I was spending too much effort on a single company, so I
stopped contributing and applying. Seems leetcode grinding would be a higher
reward for the effort.

~~~
rvz
Depending on how significant your patches are (No hello-world-123/typo/style
fixes) putting 'Contributed to the Firefox Browser' on your CV/Cover letter
and I find your email in the source code or AUTHORS file is a instant on-site
from me. You don't need to show me that you can program/write tests or use
version control. This saves me lots of time on finding candidates that are
experienced, rather than throwing a leetcode/hackerrank puzzle which can be
easily cheated or plagiarized.

I think I might have said this before on another HN thread, but of course as
an interviewer, I sometimes double-check the CVs and candidates to look for
'hidden qualities' such as open-source contributions. If one recruiter
overlooks a candidate, I really ask them why and if the candidate DOES have
significant and relevant patches, I actually bypass their decision and I bring
them in onsite.

I find these technical programming tests useless for finding qualified
candidates unless you are preparing for a programming olympiad or some other
competitive programming competition. But open-source contributions allows me
to find the patches you made on code reviewing tickets and see it in the open.

It would be better if more companies used open-source contributions as
acceptable evidence of relevant experience these days.

~~~
GrigoriyMikh
Unfortunately, that's not how big company recruitment processes work:
[https://twitter.com/mxcl/status/608682016205344768?lang=en](https://twitter.com/mxcl/status/608682016205344768?lang=en)

~~~
martius
(disclamer: I'm a noogler, and I failed google on-site once).

I think that citing this example every time "hiring at Google/Big tech" is
discussed on HN is useless.

We know that there are a lot of false negative and and lot of chance in the
hiring process (so many things can fail in a process involving so many steps
and people).

There are also legitimate rejections, like hm, bold statements ("90% of your
engineers use my software"), fingerpointing or not being able to seek for
assistance when you don't know something.

I discussed interviews with many people, and I'm convinced that solving the
problem with the theoretically-optimal solution is not the only way to get a
positive review. Being open about things I didn't know helped me: for instance
"Hm, I'm not sure about how to do this exact thing, I'll use the function
do_this_thing() and implement it later if I still have time, if that's OK for
you" buys you time and allows to keep the discussion focused on the main
problem.

~~~
joenot443
I don't think his statement, while bold, is at all unfounded. If he truly was
rejected for not being able to invert a binary tree on a whiteboard, but has a
proven track record of writing excellent software, I would agree with him that
there are some serious issues with the Google/Leetcode/2nd-year-CS-trivia
style of interviews.

~~~
BeetleB
>I would agree with him that there are some serious issues with the
Google/Leetcode/2nd-year-CS-trivia style of interviews.

I think both you and your parent are in violent agreement.

It's not as if many people who were in FAANG haven't admitted there are
serious issues with the interview process. Even advocates of the process are
open about it.

No one has found an interview process that lacks serious issues. Hiring people
solely on the basis of major contributions to software has its own serious
issues.

------
brainlessdev
Definitely recommend contributing to their codebase. It's a great experience.
I wrote about my experience contributing to Servo here:
[https://brainlessdeveloper.com/2017/08/12/my-experience-
cont...](https://brainlessdeveloper.com/2017/08/12/my-experience-contributing-
to-servo/)

~~~
GrigoriyMikh
But did it helped your carrier)?

~~~
brainlessdev
I haven't changed jobs since I started contributing two years ago. So it
hasn't, really, but I learned a lot. It probably will help in the future.

------
obelix150
One great resource for those interested in contributing to Mozilla, is
mikeconley's live coding sessions[0], which are cataloged here[1]. These can
be used to help understand internals.

[0]
[https://www.youtube.com/playlist?list=PLmaFLMwlbk8wKMvfEEzp9...](https://www.youtube.com/playlist?list=PLmaFLMwlbk8wKMvfEEzp9Hfdlid8VYpL5)

[1] [https://mikeconley.github.io/joy-of-coding-episode-
guide/](https://mikeconley.github.io/joy-of-coding-episode-guide/)

------
new_here
Chrome is a dangerously slick browser, I found it takes a determined effort to
switch and eventually get comfortable with Firefox as your primary browser.
But we should support Firefox and give efforts and user feedback where we can
to get it to the same competitve level.

~~~
camone
Can you elaborate on what you found most unconfortable or difficult to adapt
to?

I switched to Firefox ~1.5 years ago and it does everything I need, actually
never picked chrome up again. The android version is very good as well, but I
just switched to iOS and it's not a very smooth experience there.

~~~
new_here
To be fair, Firefox actually has a lot of good stuff and you can get its UI to
match the Chrome experience quite easily. The Developer Tools are also quite
good.

Biggest issue for me is not being able to import passwords from Chrome. I have
to switch back to Chrome if I need to access some web services quickly, so
building up saved passwords in a browser makes it more sticky. There's
probably a reason for not being able to do this though.

It also starts to get a bit sluggish when you have a couple (6-7) heavy JS/DOM
tabs open.

File download UI could be better. Skip the confirmation dialog, show file and
progress at the bottom of the browser window.

~~~
romantomjak
Firefox developer tools are awesome and they get better with every release!
Lots of cool stuff recently added for debugging CSS related issues.

JS sluggishness might be because of a recent Firefox Pioneer study. I've
experienced it for the past week and in the end I uninstalled Firefox Pioneeer
completely because of it.

imho, file downloads are actually great. When you have active or recent
downloads - you'll get a nice litle icon on the right from the URL bar. For
active downloads it'll show the total progress for all downloads. Once
clicked, it will open a small menu with your downloads. When you don't have
any recent/active downloads it just gets out of our way. Much better than that
ugly bar at the bottom of the window.

~~~
new_here
I didn't know about that download icon. I must have removed it when
customising the UI. Thanks!

------
pragmaticlurker
I'd really like to work for Mozilla on Mozilla products, but somehow the
interview process is broken.

I've managed to go through 3 interviews (2 technical, one with the team-
coordinator) but then was rejected because they've found some other with more
years of relevant (?) experience on the topic for the position.

Now they write this. So my question is: why don't you open more positions,
letting people be hired (and paid) to work on products, instead of looking for
charitable work from volunteers?

~~~
rehemiau
Because hiring more people costs money and volunteers are free?

~~~
mister_hn
yeah but then don't bother us with missing contributors.

Somehow someone has to live and code for food. Not everybody has the luxury of
working as volunteer.

~~~
lonelappde
No company has the luxury of paying employees with money they don't have.

------
acidburnNSA
> Mozilla uses Phabricator for code review. Either use Mozilla's Phabricator
> instance (preferred) or attach a patch as an attachment to Bugzilla.

Oh neat, they're using Phabricator, the self-hostable open-source
github/gitlab-like repo host/code review system spun out of Facebook. I use
this in the office and everybody loves it.

Example review:
[https://phabricator.services.mozilla.com/D40365](https://phabricator.services.mozilla.com/D40365)

------
zoobab
Where is built-in support for all the decentralized protocols, such as
torrent://, magnet://, dat:// ipfs:// etc?

~~~
Cthulhu_
Have you searched the bug tracker for proposals to implement this? Have you
submitted these requests? Did you review any guidelines or outlines of
features that Firefox should support?

Leaving a comment on HN to (what seems to me) complain is easy; actually going
to the issue tracker and mailing lists would be a lot more productive.

I suspect you'll find that it has been proposed but rejected. I suspect it's
because support can be easily added via addons, keeping the core more
lightweight and extensible.

~~~
kuschku
> keeping the core more lightweight and extensible

I’m not sure if that’s sarcasm or not, considering the countless issues with
CliqZ and Pocket

~~~
dao-
> CliqZ and Pocket

Cliqz made their own browser based on Firefox, and a Firefox extension. Pocket
started as a Firefox extension and even when it got integrated into Firefox it
was technically still an extension. If anything these cases seem to indicate
that the core is lightweight and extensible. What's your point?

------
aasasd
> _If you know JavaScript or HTML /CSS, you can contribute to the front-end of
> Firefox_

Huh? I'm interested in that, but I'd think most of the GUI's behavior is in
C++ and hopefully threaded for responsiveness? And only the top ‘fluff’ layer
is styleable, possibly being made with XUL.

Alas, links in that post don't seem to lead to architectural overviews of the
components.

~~~
zbraniecki
That's not true. Majority of the front end is in html+js+css these days. Most
of it is /browser and /toolkit directories. The rest is Gecko engine and it's
written in a mix of Rust, C++ and JS. We're moving more to Rust with the back
end but staying with JS on the front end.

You can develop almost any feature of Firefox without ever leaving JS.

~~~
aasasd
Interesting, thanks! Will try poking things in there. Though this might
explain why parts of the GUI sometimes get held up by each other...

Is there, by any chance, an intro to the moving parts in the GUI code, for
newcomers?

------
bluedino
Wasn't the story of Stuart Parmenter being flown out to California to help
with the browser based on his open-source contributions from his parents house
in some midwstern town?

Was that Mozilla or Netscape at the time?

~~~
jwatt
It was Netscape in 1999 he got flown out. Documented in Code Rush, which is an
awesome documentary for anyone interested in the history of the Web:

[https://youtu.be/4Q7FTjhvZ7Y?t=3037](https://youtu.be/4Q7FTjhvZ7Y?t=3037)

