The GitHub Generation

Your Resume is a Contribution Graph

Somewhere around two thousand fourteen, a strange new anxiety crept into the software industry. It had nothing to do with deadlines or deployments. It was about a grid of colored squares on a website. Your GitHub contribution graph, a heat map of every commit, every pull request, every issue you touched over the past year, had quietly become your professional identity. Hiring managers glanced at it before reading your resume. Recruiters filtered candidates by it. A solid wall of green meant you were productive, dedicated, a real engineer. Gaps meant you were lazy, or worse, that you had nothing to show.

Nobody voted on this. No industry body declared that a free website's activity tracker should determine who gets hired. It just happened, the way conventions always happen, one company copying another until the practice felt inevitable. By two thousand fifteen, not having a GitHub profile made you look suspect as a developer. Your unpaid hobby projects had become your professional resume. Code was now performative. You programmed in public, for an audience.

But here is what the green squares did not show. They did not show the developer who spent four hours debugging a production issue at work and was too tired to commit anything personal that evening. They did not show the mother who coded brilliantly at her job but had no time for side projects after her children went to bed. They did not show the developer whose employer used GitLab, or Bitbucket, or an internal server, and whose daily work was invisible to GitHub entirely. They did not show the developer who spent a Saturday reading documentation, sketching architecture, thinking deeply about a problem, and had nothing to commit because thinking does not generate green squares.

The contribution graph measured one thing: activity on GitHub. The industry treated it as a measure of something else entirely: competence, dedication, passion. And the gap between those two things was where the damage happened.

Worse, the graph was trivially easy to fake. A five-minute script running as a scheduled task could generate a commit every day, filling in the green squares with meaningless changes to a throwaway repository. If the hiring signal could be fooled by automation, it was measuring nothing meaningful. But the pressure to perform was real, and so developers performed, committing small changes, maintaining streaks, treating their GitHub profiles like social media accounts that needed constant feeding.

This was the GitHub generation. A cohort of developers whose relationship with code had been fundamentally altered by a platform. Not just how they shared code or collaborated on projects, but how they thought about their own worth as engineers. And the contribution graph was only the beginning.

The Meritocracy Myth

GitHub's founding mythology was seductive. Code speaks for itself. The best work rises to the top. It does not matter who you are, where you went to school, what you look like, what language you speak at home. Push good code, and the community will recognize it. A pure meritocracy, finally, enabled by technology.

In two thousand seventeen, a team of researchers at North Carolina State University and Cal Poly put this myth to a rigorous test. They analyzed more than three million pull requests from roughly three hundred and thirty thousand GitHub users, about twenty-one thousand of whom were women. The results were uncomfortable.

Overall, women's pull requests were accepted at a higher rate than men's, seventy-eight point seven percent compared to seventy-four point six percent. That looked like good news. But the researchers dug deeper, separating users whose gender was identifiable from their profile, a name like "Jennifer" or a profile photo, from users with gender-neutral profiles. And that is where the data turned.

When gender was identifiable, women's acceptance rate dropped to fifty-eight percent. Men with identifiable gender profiles sat at sixty-one percent. But women with gender-neutral profiles had the highest acceptance rate of any group, seventy percent, compared to sixty-five percent for gender-neutral men.

Our results suggest that although women on GitHub may be more competent overall, bias against them exists nonetheless. When women's gender is identifiable, they are treated differently.

The researchers' conclusion was stark. Read that again. Women whose code was reviewed anonymously had the highest acceptance rate on the platform. Women whose code was reviewed with their gender visible had one of the lowest. The code was the same. The only variable was whether the reviewer knew the contributor was a woman.

This was not GitHub's fault in the sense that GitHub created bias. Bias existed long before GitHub. But GitHub amplified it by making contribution visible, social, and public. The same transparency that was supposed to enable meritocracy also enabled prejudice. When your pull request comes with your name, your photo, and your entire contribution history attached, the reviewer is not just evaluating code. They are evaluating a person. And people carry biases, conscious or not, that a "meritocratic" platform cannot erase by simply making code visible.

The study made waves. It was covered by major outlets, debated on forums, challenged on methodology. Some argued the gender inference method was imprecise. Others pointed out that insider versus outsider status, not gender alone, drove much of the difference. But the central finding stuck: anonymous contributions were judged differently than identified ones. The meritocracy was not as pure as its believers claimed.

Fork and PR Culture

Last episode, we talked about how GitHub invented the fork button and pull requests. Episode ten covered the mechanics. This episode is about the consequences.

Before GitHub, contributing to an open source project was an initiation ritual. You lurked on mailing lists. You read the contributor guidelines. You submitted patches by email and waited for a response that might take weeks. The barrier to entry was high, and that was the point. Maintainers controlled access. They decided who could contribute, and their gatekeeping, while sometimes frustrating, kept the signal-to-noise ratio manageable.

GitHub blew the gates open. Anyone could fork any public repository with a single click. Anyone could open a pull request. The default shifted from "prove yourself before contributing" to "contribute first, ask questions later." This was a genuine democratization. People who would never have navigated a mailing list workflow could now contribute to projects they used and cared about. Students, hobbyists, developers in countries where the open source mailing list culture had never taken root, they all poured in.

The fork-and-pull-request workflow also reshaped how projects governed themselves. In the old model, project leadership was defined by who had commit access. In the GitHub model, anyone could propose changes, and the maintainer's role shifted from gatekeeper to curator. The command to connect your fork back to the original project, git remote add upstream, followed by git fetch upstream to pull in the latest changes, became the standard ritual. Every contributor maintained two remotes: origin, their own fork, and upstream, the project they were contributing to. It was a small technical detail with enormous social implications. You did not need permission to start. You only needed acceptance to finish.

But every revolution has unintended consequences. The same low barrier that let talented newcomers contribute also let anyone with a GitHub account open a pull request. And "anyone" turned out to include people who had not read the documentation, had not tested their changes, had not understood the project's conventions, and sometimes had not even understood the problem they were trying to solve.

Maintainers of popular projects found themselves drowning. Not in code, but in notifications. Pull requests that changed one variable name. Issues filed as feature requests with no context. Bug reports that were actually misconfigurations. Duplicate issues. Questions that belonged on Stack Overflow. And the social pressure to respond to all of it, because ignoring a contribution felt rude, and being rude on a public platform had professional consequences.

The fork button democratized contribution. It also democratized noise.

Maintainers Under Siege

In two thousand sixteen, a writer and researcher named Nadia Eghbal published a report for the Ford Foundation called Roads and Bridges. The subtitle said it all: The Unseen Labor Behind Our Digital Infrastructure. Eghbal had spent months interviewing open source maintainers, and what she found was an industry built on the unpaid work of individuals who were quietly falling apart.

Four years later, she expanded the research into a book called Working in Public. The picture it painted was bleak. The overwhelming majority of open source projects were maintained by one or two people. Critical software, the kind that runs on hundreds of millions of devices, often depended on someone's free time. And the more successful a project became, the worse the maintainer's life got.

In the absence of additional reputational or financial benefits, she wrote, maintaining code for general public use quickly becomes an unpaid job you cannot quit.

The cycle Eghbal described was brutal in its simplicity. A developer writes something useful and publishes it. The project gets popular. Users file issues, request features, open pull requests. The maintainer responds, reviews, merges, fixes, documents. The work grows. The rewards do not. The maintainer burns out. And then one of two things happens: the project slowly dies, or the maintainer hands it to someone else and walks away.

In two thousand eighteen, both scenarios played out in public.

Dominic Tarr maintained event-stream, a Node.js library with nearly two million weekly downloads. He had written it years earlier and moved on to other things. But the downloads kept climbing, the issues kept arriving, and the guilt of neglecting a project that millions of people depended on weighed on him. When a stranger offered to take over maintenance, Tarr said yes.

I have long mass ignored issues on these repos. I do not get anything from maintaining this module.

The stranger injected code that stole cryptocurrency wallet credentials from a specific application called Copay. The attack was discovered in November two thousand eighteen. Tarr's exhaustion had become a security vulnerability. The open source supply chain was only as strong as its most burned-out maintainer.

The same year, Denis Pushkarev, the sole maintainer of core-js, a JavaScript library used on more than half of the world's most visited websites, published a desperate plea. His donations amounted to fifty-seven dollars a month. Western financial sanctions had cut off many of his payment channels because he was based in Russia. When he added a donation link to the library's installation output, a standard practice for struggling open source projects, the response was not sympathy. It was hate.

I considered my options. Appropriate financial backing. Being hired by a company to maintain it. Making it closed source. Or a slow death.

Pushkarev laid it out like a list of exits, none of them good. A Tidelift survey in two thousand twenty found that forty-six percent of professional open source maintainers had experienced burnout. For maintainers of widely-used projects, the number was fifty-eight percent. More than half of the people holding up the infrastructure were cracking under the weight.

Eghbal identified the core paradox. The problem was not that people were using too much open source code. The problem was that too many people were demanding the maintainer's attention.

It is not the excessive consumption of code, Eghbal argued, but the excessive participation from users vying for a maintainer's attention that has made the work untenable.

GitHub had made contributing frictionless. But it had not made maintaining frictionless. The asymmetry was devastating. Opening a pull request took minutes. Reviewing one took hours. Filing an issue took seconds. Triaging one took expertise and patience. The platform optimized for the contributor's experience. The maintainer's experience was an afterthought.

From Tool to Platform to Infrastructure

While maintainers struggled, GitHub kept growing. And growing meant adding features. Lots of features.

Issue tracking came early, replacing external bug trackers. Then project boards for planning. Then GitHub Pages for documentation. Then GitHub Actions for continuous integration and deployment, replacing external services like Travis CI and CircleCI for many teams. Then Dependabot for automated dependency updates. Then a package registry for hosting your own packages. Then Codespaces for cloud-based development environments.

Each feature was individually useful. Collectively, they represented something else: a platform play. GitHub was no longer just where you hosted code. It was where you planned work, tested code, deployed software, managed dependencies, hosted packages, and ran development environments. The entire software development lifecycle, from idea to production, could happen inside one company's walls.

And then, in June two thousand twenty-one, GitHub launched Copilot.

Copilot was an AI pair programmer, built on OpenAI's Codex model, that could suggest code as you typed. It was impressive. It was also trained on the public code hosted on GitHub, code that developers had published under open source licenses like MIT, GPL, and Apache.

The irony was exquisite. Developers had published their code on GitHub under licenses that required attribution, or that mandated derivative works remain open source. GitHub had trained an AI on all of it. And now GitHub was selling access to that AI for ten dollars a month. The code generated by Copilot included no attribution, no copyright notices, no license references. The terms of the original licenses, the ones developers had carefully chosen, were simply absent.

In November two thousand twenty-two, a lawyer and programmer named Matthew Butterick filed a class-action lawsuit against GitHub, Microsoft, and OpenAI.

By training their AI systems on public repositories, the defendants violated the legal rights of a vast number of creators who posted code under open-source licenses on GitHub.

The lawsuit alleged that Copilot violated the terms of open source licenses by using the code without adhering to their requirements. In May two thousand twenty-three, a federal court dismissed the copyright infringement claims for lack of specific examples of copied code, but allowed the breach of contract and Digital Millennium Copyright Act claims to proceed. The case is still working its way through the courts.

But the legal outcome almost does not matter. The philosophical damage was done. The platform that had become the home of open source, that had built its early growth on the free labor of open source developers, had trained a commercial AI product on that labor without asking. Regardless of what the courts decided, developers now understood something about the power dynamics of their relationship with GitHub. They were not customers. They were not partners. They were the product.

Who Owns Developer Identity

Step back for a moment and look at what GitHub had become by the mid-twenty twenties. It hosted over three hundred million repositories. It had more than a hundred million developers. It owned npm, the JavaScript package registry. It ran the AI that was reshaping how code gets written. It was where most of the world's open source projects lived, where developers built their professional identities, where companies recruited, where code got reviewed, where software got deployed, and where an AI was being trained on all of it.

That is an extraordinary concentration of power. And it all sits inside Microsoft, one of the largest companies in the history of the world.

Is this dangerous? The optimists point to Microsoft's track record since the acquisition. Private repositories became free. GitHub Sponsors launched to help fund open source maintainers. Actions, Codespaces, and Copilot brought genuine innovation. Microsoft invested in the platform rather than strip-mining it.

The pessimists point to something else. GitHub is a single point of failure for developer identity. If your GitHub account is suspended, you do not just lose access to your repositories, though that is bad enough. You lose your professional history. Your contribution graph. Your reputation. The profile that hiring managers Google before deciding whether to interview you. Your identity as a developer, the one that the industry taught you to cultivate on GitHub, can be erased by one company's moderation decision.

Git itself was built to prevent exactly this kind of centralization. Every clone is complete. There is no central server in Git's design. Linus made that choice deliberately, because he had learned what happens when you depend on someone else's platform. The BitKeeper crisis, the one we covered in episode three, happened precisely because a centralized authority could revoke access at will.

And yet here we are. The tool that was designed to be distributed, the tool where every copy is a complete backup, has become synonymous with a single centralized platform. We use Git, but we live on GitHub. Our code is distributed. Our identity is not.

This is the deepest tension in the Git story, the thread that runs through every act of this series. Episode six described how every clone is a kingdom. Episode ten showed how GitHub re-centralized the social layer. Episode eleven covered the Microsoft acquisition. And this episode completes the picture. GitHub did not just centralize code hosting. It centralized what it means to be a developer. Your contribution graph, your pull request history, your followers, your stars, your green squares, these are not just features of a website. For a generation of developers, they are the record of a career.

The GitHub generation learned to code in public, to build portfolios of open source work, to cultivate professional identities through commits and pull requests. They learned that meritocracy was real, until research showed it was not. They learned that open source was a community, until maintainer burnout revealed it was often one exhausted person propping up critical infrastructure. They learned that their code was their own, until an AI trained on it and sold the output back to them.

The last episode covered Microsoft buying GitHub. This episode is about what GitHub bought from all of us, and what we got in return. The answer to both questions is complicated, and the GitHub generation is still living inside that complication, one green square at a time.

git remote. The command that manages your bookmarks to the outside world. Most developers never look past origin, the default name for wherever they cloned from. But git remote tells you something the platform never will: your code does not belong to any server. Origin is a name you can change, delete, or replace. You can have five remotes pointing to five different hosting services. The code is yours. The remote is just an address. In a world where one platform holds most of the green squares, that is worth remembering.