Before social code hosting, contributing to an open-source project was a high-friction act. A would-be contributor typically had to subscribe to a mailing list, learn the project’s conventions, generate a patch file with a diff tool, and email it in, then wait for a maintainer to apply it by hand. The barrier was technical and social at once, and it kept casual contribution rare.
GitHub’s fork-and-pull-request model collapsed that friction. Anyone could fork a project, which created their own full copy of the repository, make a change, and open a pull request asking the maintainers to merge it. The proposal arrived as a structured, reviewable object rather than a loose patch in someone’s inbox. GitHub framed pull requests as “living discussions about the code you want merged,” combining the proposed change, line-by-line review comments, follow-up commits, and automated checks in one place.
That small change in workflow had an outsized cultural effect. Because forking and proposing were just a few clicks, the cost of a first contribution dropped close to zero, and review happened in the open where others could read and learn from it. Collaboration became visible and social: pull requests were, in GitHub’s description, “visible, linkable, archived,” each with a permanent URL that anyone could find and reference.
The result was open-source participation at a scale the patch-by-email era never reached. GitHub describes the pull request as its foundational collaboration feature, the place where proposing, discussing, reviewing, and merging changes all come together. By making the act of contributing easy and public, the pull request turned open source from something maintained by small, tight-knit groups into a genuinely mass activity.