Contributing to open source at GitHub

Finding a path into open source

In 2011, as a computer science graduate looking for a first job, Ariel Deitcher (@mntlty) read that contributing to open source could help build skills and industry connections. The idea was sound, but the execution stalled: choosing a project with the right size, language, and community felt overwhelming, and without enough confidence to push through, he set the goal aside. Open source contributions remained out of reach even as his private code accumulated.

The picture changed in 2021, while interviewing at GitHub. Reading Nadia Eghbal's Working in Public reframed his view of open source through the Stadium model, where a few maintainers work in front of a large user base. That framing made the prospect of contributing feel less intimidating, particularly with the support of a team and manager at GitHub.

Spinning a work problem into a contribution

Deitcher joined the team building Merge Queue (beta), a feature that coordinates merges to a protected branch, ensures changes are current, and waits for all required checks before auto-merging a pull request. Early on, he told his manager he wanted to contribute code to an open source project, and the GitHub CLI — a Go-based tool for interacting with GitHub from the command line — emerged as a candidate.

While testing scenarios against Merge Queue, Deitcher found that running gh pr merge failed in most cases once a Merge Queue was required. The CLI lacked support for the feature. He forked the repository, opened a Codespace, and studied the contributing guidelines and the merge command's code. He submitted a small pull request expecting the maintainers to lead the final implementation.

The review revealed the code had accumulated enough technical debt that his changes were hard to reason about. The maintainers asked him to split the work: first refactor the merge command, then follow up with the Merge Queue changes. With his manager's approval for the larger commitment, he began the refactor.

Refactoring first, feature second

Deitcher focused the refactor on simplicity, readability, and early returns instead of deeply nested conditionals. He worked through the existing test coverage, copied each section into separate files for reference, and documented his understanding of each removed block. Common Git and API operations were consolidated into well-named functions and variables, unreachable code paths were trimmed, and a MergeContext struct was introduced to encapsulate state. The Go code's explicit error returns gave the command a more linear structure.

The result was dramatic: the mergeRun function, the command's core, shrank from over 220 lines to 30:

func mergeRun(opts *MergeOptions) error {
    ctx, err := NewMergeContext(opts)
    if err != nil {
        return err
    }

    // no further action is possible when disabling auto merge
    if opts.AutoMergeDisable {
        return ctx.disableAutoMerge()
    }

    ctx.warnIfDiverged()

    if err := ctx.canMerge(); err != nil {
        return err
    }

    if err := ctx.merge(); err != nil {
        return err
    }

    if err := ctx.deleteLocalBranch(); err != nil {
        return err
    }

    if err := ctx.deleteRemoteBranch(); err != nil {
        return err
    }

    return nil
}

His pull request was met with a supportive review process. After several rounds of feedback, the refactor merged and shipped in the next release. Returning to the Merge Queue branch, he found most of the original code no longer existed on trunk — but having just rewritten the command, he implemented Merge Queue support and tests in a follow-up pull request quickly and confidently.

Don't search — align

Deitcher's takeaway is that hunting for the perfect open source project outside of work hours doesn't work well. The successful approach was finding a project his team already relied on, with accountability built into his day job. For others in a similar position, he suggests asking a manager for time to fix issues in open source software the team depends on.

Impostor syndrome doesn't disappear when contributing in public, he notes. A regression he introduced remains discoverable permanently. But he continues to pick up issues labeled "help wanted (contributions welcome)" in the CLI repository, accepting that imperfect commits are part of the process.