How To Contribute To Mozilla Open Source

Open Source is great. It is a concept of software development where projects and its source code are accessible to the public, and is considered a way to grow software. Mozilla Open Source is a central place to find information about contributing to Mozilla open source projects. It highlights projects that need help and provides helpful resources for getting started. This in turn brings the users and contributors together, builds the community and makes Mozilla better for everyone.

It’s time to step up and take a role in Mozilla. Learn how you can contribute to the open source development of Mozilla. Whether you have time to code, test, or write – we can use your help. Contributors are the most important part of our community, and Mozilla would not be what it is today without them! Mozilla exists to promote choice and innovation on the Internet. To continue this mission, we need YOU!

Find a bug we’ve identified as a good fit for new contributors.

With more than a million bugs filed in Bugzilla, it can be hard to know where to start, so we’ve created these bug categories to make getting involved a little easier:

  • Codetribute – our site for finding bugs that are mentored, some are good first bugs, some are slightly harder. Your mentor will help guide you with the bug fix and through the submission and landing process.
  • Good First Bugs – are the best way to take your first steps into the Mozilla ecosystem. They’re all about small changes, sometimes as little as a few lines, but they’re a great way to learn about setting up your development environment, navigating Bugzilla, and making contributions to the Mozilla codebase.
  • Student Projects – are larger projects, such as might be suitable for a university student for credit. Of course, if you are not a student, feel free to fix one of these bugs. We maintain two lists: one for projects based on the existing codebase.

Why should I contribute to open-source?

Ever wonder if all these projects/software were single-handedly maintained by a single developer?
What would have been its impact on them and pretty much on us?

The software would not have had so many features and upgradations. This is where open source contribution comes in. Contributors from around the world help develop and improve the software for every one of us who use it. Being a contributor will give you the super-power to be a part of something that is impacting so many lives.

Apart from the impact that you get to create, it also helps you become a better developer and with time a good mentor, leader, and passionate team player.

Getting your code reviewed

Once you fix the bug, you can advance to having your code reviewed.

Mozilla uses Phabricator for code review.

Who is the right person to ask for a review?

  • If you have a mentored bug: ask your mentor. They will help, or can easily find out. It might be them!
  • Run hg blame on the file and look for the people who have touched the functions you’re working on. They too are good candidates. Running hg log and looking for regular reviewers might be a solution too.
  • The bug itself may contain a clear indication of the best person to ask for a review
  • Are there related bugs on similar topics? The reviewer in those bugs might be another good choice
  • We have an out of date list of modules, which lists peers and owners for the module. Some of these will be good reviewers. In a worst case scenario, set the module owner as the reviewer, asking them in the comments to pick someone more suitable

Learn a programming language

Since open-source contribution requires you to read/write code if you want to be involved in its development, you are required to learn a programming language to get started. You can get started with any language of your choice. You can easily learn another language at a later stage if a project requires it.

Many people help with documentation, translation, etc as well which does not require programming. If you do not want to contribute as a developer then you can skip this step.

Following up and responding

Once you’ve asked for a review, a reviewer will often respond within a day or two, reviewing the patch, or saying when they will be able to review it, perhaps due to a backlog. If you don’t hear back within this time, naturally reach out to them: add a comment to the bug saying ‘review ping?’, check the “Need more information from” box, and add the reviewer’s name. If they don’t respond within a day or two, you can ask for help on Matrix in the #introduction:mozilla.org or #developers:mozilla.org channels, or contact Mike Hoye directly.

Don’t hesitate to contact your mentor as well if this isn’t moving.

For most new contributors, and even for long-time Mozillians, the first review of your patch will be “Requested Changes” (or an “r-” in Bugzilla). This does not mean you’ve done bad work. There is more work to do before the code can be merged into the tree. Your patch may need some changes – perhaps minor, perhaps major – and your reviewer will give you some guidance on what needs to be done next.

This is an important process, so don’t be discouraged! With our long-lived codebase, and hundreds of millions of users, the care and attention helping contributors bring good patches is the cornerstone of the Mozilla project. Make any changes your reviewer seeks; if you’re unsure how, be sure to ask! Push your new patch up to Phabricator again and ask for a further review from the same reviewer. If they accept your changes, this means your patch can be landed into the tree!

Get Familiar with Version Control Systems (VCS)

When we are working on a big project, it is extremely important to store all the changes that are being made to recall it at a later stage. Version Control Systems are software tools that help with it. They keep track of all the modifications that happen over time in the source code as versions. They also allow us to go through older versions and revert to an old version if required.

You can read more about VCS here – What is version control?

There are many version control systems such as Git, Mercurial, CVS, and SVN. Git is the most popular and most widely used version control system in the industry.

Getting code into Firefox

Once your patch has been accepted, it is ready to go. Before it can be merged into the tree, your patch will need to complete a successful run through our try server, making sure there are no unexpected regressions. If you don’t have try server access already, your mentor, or the person who reviewed your patch, will be able to help.

Start contributing to Open-Source actively

  • Find projects or organizations that you are interested in contributing to.
  • Go to their GitHub repository, read the documentation, and search for first-timer issues as mentioned above.
  • Try to work on as many issues as you can either across projects or for a single project.
  • Join their IRC channel (Gitter/Discord/Slack, etc.). Introduce yourself and ask for help when stuck. You can find the link to the channels on their GitHub pages.
  • You can also create issues after running the application locally.
  • Once you are comfortable with contributing to open-source, start participating in open source programs.

Do it all again!

Thank you. You’ve fixed your very first bug, and the Open Web is stronger for it. But don’t stop now.

Go back to step 3, as there is plenty more to do. Your mentor might suggest a new bug for you to work on, or find one that interests you. Now that you’ve got your first bug fixed you should request level 1 access to the repository to push to the try server and get automated feedback about your changes on multiple platforms. After fixing a nontrivial number of bugs you should request level 3 access so you can land your own code after it has been reviewed.

Open-Source Programs/Contests you can participate in

There are many open-source coding programs that you can participate in.

  • Google Summer of Code (GSoC)
    GSoC is the Olympics of Open Source. It is a global program focused on encouraging more student developers to do open source software development.
    Students work with one of the selected open-source organizations for 3 months and get a handsome stipend on completing the project. Students need to propose changes that they want to work on to get selected.
    It is a good idea to start contributing to your favorite orgs/project much before GSoC.
  • HacktoberFest
    HacktoberFest is a month-long celebration of open source software carried out in October. You can sign up anytime between October 1 and October 31.
    It is open to everyone in the global community!
    One needs to complete a certain amount of quality PRs to get swags in return. The swag motivates many people to get started with open-source contributions through this program.
  • GirlScript Summer of Code
    GirlScript Summer of Code is a 3 month long Open Source program during summers conducted by GirlScript Foundation, started in 2018, to help beginners get started with Open Source Development while encouraging diversity.
    Note that it is open to everyone and not just girls as the program name might suggest.
  • Outreachy
    Outreachy (previously the Free and Open Source Software Outreach Program for Women) is a program that organizes three-month paid internships with free and open-source software projects.
    It is for people who are typically underrepresented in those projects.
    This is generally carried out biannual throughout the year.
  • Rails Girl Summer of Code
    Rails Girls Summer of Code is a global fellowship program aimed at bringing more diversity into Open Source.
    Successful applicants are paid a monthly stipend, from July-September, to work on Open Source projects of their choice.
  • MLH Fellowship
    The MLH Fellowship is an internship alternative for software engineers.
    Instead of working on a project for just one company, selected candidates contribute to Open Source projects that are used by companies around the world and are paid a competitive stipend during this tenure.

Conclusion

We’ve created this guide to help people considering contributing to project Mozilla. This is by no means a complete list of ways to contribute, but will hopefully get you started and lay the groundwork for a successful contribution. If you’re new to open source and/or Mozilla, check out How to Contribute To Open Source .

0 Comments

No Comment.