Mozilla is an Open Source Project. That means that the source code is publicly available and everyone can read it and see what is happening under the hood. (Searchfox is a great way to navigate the hundred of thousands of files by letting you do a full text search on the Mozilla codebase if you want to give it a try).
Open source software stands in contrast to proprietary software, where the source code is hidden and you can only download a compiled file and have to trust that the code does what it is supposed to do.
But on top of everyone being able to read the Mozilla code, everyone can contribute to the Mozilla code.
And it still works!
That is absolutely amazing if you think about it. One very important step in making sure that nothing breaks is code reviews. So everyone can contribute but you need others to check your code before changes get merged into the actual codebase. If you want to make a change to the codebase you can upload your patch to phabricator (the code review tool used by Mozilla). This tool automatically flags all module owners (the people responsible for specific parts of the code) whose code you are touching. So if you for example change a CSS file, someone from UX has to give their ok. But not only the people who are tagged automatically can comment on your patch, again everyone (with an account) can. You don’t need the ok from everyone, but from every tagged module owner before you can land your code (that is, make it become part of the next Firefox update).
Since this is my first experience with open source, I did not know what to expect. At first it felt scary to upload my code to phabricator. What if it is very bad? And now it is online for everyone to judge. But of course that is not how this works at all. Everyone is interested in making the code better. So I got comments ranging from “you forgot the empty line at the end”, “can you make your variable names more descriptive” to “hey you should try this and that since it would work even better”. And most important of all: people flagging potential security problems I overlooked. I have to confess that at first this felt irritating. I felt like I was almost done with my patch and now I had to restructure everything – again. But after taking a deep breath and planning out how to do that I was really grateful. Obviously I don’t want to introduce security problems in a secure browser feature. And I am very new to this codebase so of course I don’t see all the possible problems. And that is exactly why more experienced people do check my code. To make sure everything is as good as it can be.
And with every iteration my code becomes better and I get to know new parts of the codebase and come in contact with new concepts. And even though I of course try to not make any mistakes, it’s not just on me but I can rely on others to double, triple and quadruple check my code so my updates won’t introduce any problems but just be awesome.
In Summary: Even though coding in the open feels terrifying in the beginning – it soon gets very rewarding and I can highly recommend it to everyone. Who doesn’t want to make a difference and help creating the web (browser) we want?