Open Source Contributions as Proof of Work for Remote Roles

If you want a remote role at an organisation that builds software in the open, a merged contribution to a public project is evidence anyone can check with one click. This guide shows how to pick a project that fits the jobs you are aiming for, find a first task, follow the project's contributing guide, make a small but useful change (code or not), handle the public conversation around it, and then point employers to the work. It can't promise a job. It will help you build proof that holds up when a reviewer opens the link.

Why do public contributions carry weight in remote hiring?

For a remote team, much of the job is written, asynchronous collaboration, and an open-source contribution shows exactly that. GitHub's Open Source Guides point out that open-source work is public by nature, so each accepted change becomes an example you can take anywhere. GitLab's contributor page goes a step further and suggests highlighting your contributions on your résumé. A reviewer sees more than the final change: they see how you asked questions, took feedback and followed someone else's conventions.

TrueJobs lists remote roles from open-source organisations such as Canonical (the company behind Ubuntu), GitLab, Mozilla, Grafana Labs and the Wikimedia Foundation. Several of them publish pages inviting outside help: Ubuntu asks for writers and testers, GitLab says you don't need to write code to contribute, Mozilla looks for translators, and Wikimedia's New Developers page lists projects with named mentors. Be realistic, though. A contribution is evidence of skill and teamwork, not a shortcut around the normal application, and maintainers owe you nothing beyond a fair review.

How do you choose a project that matches the jobs you want?

Start from the listings, not from a list of popular repositories. Save five or six remote roles you would genuinely apply for and note the languages, tools and products they mention. The strongest choice is a project those employers build or rely on, or one that uses the same stack, because the skills and vocabulary carry straight into your application.

• For example, a backend developer whose saved roles mention Go and monitoring tools could look at the open-source projects those companies maintain or depend on.
• A technical writer aiming at developer-tools companies might start with a project's documentation, where small fixes are quick to review.
• A support or QA candidate could reproduce bugs other users have raised and confirm which versions are affected.
• Someone fluent in Hindi, Tamil, Bengali or another language could join a project's translation effort.

Then check that the project is alive and friendly before you invest time. The Open Source Guides offer a short checklist, and GitHub's Insights tab includes a Pulse view that summarises recent activity in a repository.

• A licence file in the root of the repository; without one, the project isn't open source.
• Commits and merged pull requests from the last few weeks, not the last few years.
• Maintainers who reply to new issues and pull requests and thank contributors.
• Discussions that stay civil, even when people disagree.
• A CONTRIBUTING file and a code of conduct, which signal that newcomers are expected.

Where do you find a good first issue?

Many projects tag beginner-friendly work. On GitHub the usual labels are good first issue and help wanted, and GitHub's documentation explains that projects use them so newcomers can find something to start on. The Open Source Guides add a shortcut: put /contribute at the end of a repository's GitHub address to see its beginner-friendly issues in one place.

Larger organisations have their own conventions. GitLab's development guide recommends starting with issues labelled quick win::first-time contributor, and you can ask for a merge request coach by commenting @gitlab-bot help on the issue. Wikimedia lists projects that offer mentors and warns that its general newcomer tasks may have no mentor and slower reviews. If you need guidance, a project with named mentors is a better first stop.

Before you start, read the whole thread. If someone has already said they're working on it, or a recent fix is waiting for review, pick another issue or ask whether they would like help.

What should you read before making a change?

Three files tell you how a project wants to be approached. The README explains what it does. The CONTRIBUTING file describes the kinds of help wanted and how the process works, and GitHub links to it automatically whenever someone opens an issue or pull request. The code of conduct sets expectations for behaviour, and GitLab's guide lists reading it as the very first step.

Look in the CONTRIBUTING file for practical details: how to set the project up locally, how to name branches, whether tests are expected, the commit message style, and whether you need to sign anything. GitLab, for example, accepts merge requests and issues only in English, and says all contributions come under a Developer Certificate of Origin (DCO) or a contributor licence agreement (CLA), which are short legal statements confirming you have the right to submit the work.

Which small contributions are actually useful?

You don't have to start with code. The Open Source Guides describe documentation, translation, tidying up issues and answering questions as work that projects often neglect, and these are good ways for writers, support staff and testers to build a record too.

• Documentation: fix a confusing step you hit while installing the project, or add a missing example. Ubuntu's contribute page says its community always needs people to write guides and update tutorials.
• Translation: Mozilla invites volunteers to translate its products and websites into their own language, and Ubuntu and GitLab run translation efforts as well.
• Testing: try an open pull request on your own machine and comment with what happened; GitHub's documentation counts this as a contribution in its own right.
• Triage: reproduce a bug someone has raised and add exact steps, link duplicate issues, or ask the person who opened it a clarifying question.
• Code: a small bug fix or a missing test, ideally on an issue a maintainer has already agreed is worth doing.

Keep your first change small. The Open Source Guides advise opening an issue to ask before working on anything substantial, so you don't spend a fortnight on a feature the maintainers never wanted.

The fork and pull request flow in brief

If you can't push to a repository directly, GitHub's tutorial describes making your own copy (a fork), changing it, and proposing those changes back to the original project. It also stresses explaining why you're making the pull request, so the owner can judge whether the change helps everyone.

1. Fork the repository and clone your fork to your computer.
2. Create a new branch for this one change.
3. Make the change, run the project's tests, and commit with a clear message.
4. Push the branch and open a pull request that links the issue and explains the reason for the change.
5. Answer review comments by pushing further commits to the same branch.

How should you communicate in public issue threads?

Open-source discussions are public and searchable, so your comments become part of your work sample. A few habits make a big difference to how they read.

• Say you're picking up an issue before you start, so nobody duplicates the work.
• Give context: what you tried, what happened, and the exact commands and output. Wikimedia asks newcomers to paste commands and output rather than paraphrase them.
• Keep questions in the public thread. The Open Source Guides advise against messaging maintainers privately unless the matter is sensitive, such as a security problem.
• Be patient. If a week passes with no reply, one short, polite follow-up in the same thread is fair; Wikimedia asks contributors not to chase reviews in separate messages.
• When a reviewer asks for changes, thank them, make the changes, and say briefly what you changed.

How do you point employers to your contributions?

Once a contribution is merged, or at least reviewed, turn it into something a hiring manager can check in a minute. Link to the specific pull request, merge request or issue rather than your whole profile, and describe your part accurately. You contributed to a project; you didn't work for the organisation that runs it.

• For example, a developer's CV line: fixed a date-parsing bug in a Python input-validation library and added regression tests, merged after two rounds of review, with a link.
• For example, a writer's line: rewrote the Windows installation steps for a command-line tool after reproducing the setup errors new users kept hitting.
• For example, a QA or support line: reproduced a dozen open bugs in a desktop app with step-by-step notes that maintainers used to fix several of them.

In an application message, mention a contribution when it relates to the job, and especially when it's to the employer's own project. One or two sentences and a link are enough. Our guides on writing a résumé for remote jobs, writing an application message and building a portfolio of work samples cover how to present it alongside everything else.

Your first contribution, week by week

1. Week one: list the tools named in five remote roles you want, then shortlist two projects that use them and pass the health checklist.
2. Week two: read each project's README, CONTRIBUTING file and code of conduct, set one up locally, and watch its issue tracker.
3. Week three: claim one small labelled issue or documentation fix, say so in the thread, and open a pull request with a clear explanation.
4. Week four: respond to review, and once the change is merged, add a line and a link to your CV.
5. After that: keep going with the same project. A run of related contributions says more than scattered one-off fixes.