How GitHub Democratized Coding, Built a $2 Billion Business, and Found a New Home at Microsoft
When Tom Preston-Werner, Chris Wanstrath, and PJ Hyett got together in 2008 to collaborate on a project, the three friends fully intended for their side hustle to be just that—a weekend project, and nothing more. But it didn’t take long for them to realize that their idea was potentially much bigger than they’d realized. Their idea would become far more than a weekend project: It would transform how people write and share code.
That idea was GitHub.
In just 10 years, GitHub has transformed how people code. GitHub hasn’t just made coding easier—it has changed the way software developers think about programming.
GitHub achieved incredible growth and success by identifying a major problem that millions of people all over the world were wrestling with—how to collaborate on code—and devising an elegant solution that the market desperately needed. By building a SaaS service around Git, an open-source project, GitHub was able to deliver value to and monetize that open-source ecosystem. This is also what made GitHub such an attractive acquisition for Microsoft in early June 2018, despite Microsoft’s troubled history in the open-source community.
Let’s look at:
- How GitHub has grown and evolved from a version control system to a social utility for programmers, and finally to the place where code lives online
- Why GitHub’s freemium model works so well—and drives conversions so effectively
- How GitHub identified an urgent need in a vast potential market and created a product around that need that became practically indispensable.
To understand why GitHub was so significant, we have to examine what the software development landscape looked like way back in 2008—and what made GitHub such a brilliant idea, both then and now.
2007-2011: Code Gets Collaborative, Software Gets Social
Although luminaries like Bill Gates and Steve Jobs became household names by fundamentally reshaping personal computing, it’s hard to imagine technology without the contributions of Linus Torvalds, the Finnish software engineer who created the Linux operating system. Upon its release in 1991, Linux challenged the Windows/Mac dichotomy and offered users a remarkably flexible, lightweight, and secure open-source OS that quickly found favor among hardcore geeks and techies who wanted to exercise greater control over their systems.
Inventing an entirely new OS might have been enough for some people, but not Torvalds. In 2005, Torvalds unveiled his latest project—a new version control system called Git. Version control is crucial to the concept of collaborative programming. Version control systems track changes to computer files over time. Similar to the “snapshots” that computer backup systems use as restore points, version control systems allow programmers to work on the same project without stepping on each other’s changes by tracking each version of a project by “forking” or separating versions of that project into distinct “branches.” Once changes have been made to a branch, they can be uploaded back to and merged with the original project, in a process known as a “commit.” This system allows programmers to work independently on their own branches before merging their files back to the main project, which is known as a repository.
When Git was released in 2005, open-source was experiencing something of a renaissance. Interest in and adoption of Linux was strong. The first of the Web 2.0 applications had begun to emerge. Many companies were migrating their tech stacks to open-source servers. Although Git made collaborating on open-source projects practically effortless by introducing the concept of forking, there was something Git couldn’t do: help coders find those open-source projects. A lot of programmers were working on plenty of exciting open-source projects, but finding them was difficult.
GitHub would change all that.
When PJ Hyett and Chris Wanstrath began talking about what ultimately became GitHub in 2007, both men were working as programmers for tech website CNET. Both favored the Ruby on Rails development framework. As they worked on projects at CNET, Hyett and Wanstrath developed several improvements and suggestions to the codebase of Rails itself. However, getting anyone to actually look at their code was another matter.
As was typical of most open-source projects at that time, Rails’s codebase was managed by a small, tight-knit group of coders who managed contributions to the codebase manually. These coders served as de facto gatekeepers. Hyett and Wanstrath had to not only petition these gatekeepers to look at their code but also convince them that it was worth committing to the Rails project. Even if one of the project gatekeepers found code suggestions useful, actually merging patches wasn’t straightforward, either.
Essentially, contributing to the Rails project was about who you knew, not what you knew.
Git attempted to address some of these problems. Linus Torvalds’s version control system was as remarkable as the operating system he had built single-handedly just a few years before. Git allowed coders to collaborate without petitioning gatekeepers for access. Git was a crucial first step in the ultimate democratization of coding, particularly in the open-source community. But for all the ease Git promised, it lacked collaborative tools, and sharing code between two programmers was still clunky and difficult. It might be hard to imagine now, but picture software developers emailing patches back and forth and it becomes easier to see why GitHub was so sorely needed.
“People were starting to talk about Git at the Ruby meetups. About how awesome it was. But something was amiss. Git was supposed to be this amazing way to work on code in a distributed way, but what was the mechanism to securely share private code? Your only option was to set up user accounts on Unix machines and use that as an ad hoc solution. Not ideal.” — Tom Preston-Werner
Despite these shortcomings, Git’s potential gave Tom Preston-Werner, a Ruby programmer in the Bay Area, an idea. Preston-Werner was working on a project called Grit, a tool that allowed coders to access Git repositories in an object-oriented manner using Ruby on Rails. Preston-Werner first met Chris Wanstrath at Zeke’s, a sports bar in San Francisco, after a local meetup for programmers known as I Can Has Ruby. Wanstrath and Preston-Werner knew of each other from mutual acquaintances, and Preston-Werner told Wanstrath about Grit.
Preston-Werner and Wanstrath officially began working on the first version of GitHub on October 1, 2007. At 10:24 p.m. PST on Friday, October 19, 2007, just weeks after that fateful discussion over drinks in a San Francisco sports bar, Chris Wanstrath made the first-ever GitHub commit and changed programming forever.
When Preston-Werner and Wanstrath began working together in 2007, the idea was not to develop GitHub as a commercial tool and build a business around it. Wanstrath and Preston-Werner needed GitHub for their own work, and so they developed their tool out of necessity. The two men quickly identified a major problem in their work—forking code branches and collaborating on programming projects—and devised a solution that met their needs. What was brilliant about Wanstrath and Preston-Werner’s solution is that every software developer, regardless of programming language or operating system or job role, experienced these major problems. This represented an immense potential market for their future product.
Over the coming weeks, Wanstrath met with Preston-Werner on weekends to hack together the first iterations of GitHub. Preston-Werner handled design, and Wanstrath focused on implementing Preston-Werner’s features.
“For the next three months, Chris and I spent ridiculous hours planning and coding GitHub. I kept going with Grit and designed the UI. Chris built out the Rails app. We met in person every Saturday to make design decisions and try to figure out what the hell our pricing plan would look like.” — Tom Preston-Werner
In January 2008, after three months of weekend-long code sprints, napkin wireframes, and bleary-eyed all-nighters, Wanstrath and Preston-Werner were ready to unveil GitHub to the world. Just as Spotify did during its crucial early-development stages, GitHub first launched as a private beta. Wanstrath and Preston-Werner emailed their friends at startups across the Bay Area and beyond, inviting them to try the tool they’d been building. The response was immediately and powerfully positive. The following month, GitHub, Inc. was officially founded as a company, after changing its name from Logical Awesome.
Although the two men hadn’t set out to create a business, the commercial potential of their idea gained traction early on. In April 2008, just three months after GitHub launched in private beta and the same month GitHub launched its official website, Chris Wanstrath received a message from Geoffrey Grosenbach, founder of online learning site PeepCode, which had just migrated its code to GitHub. Grosenbach’s conscience had evidently gotten the better of him, and he told Wanstrath he wasn’t comfortable using GitHub to host his company’s codebase free of charge. Messages like this from active GitHub users were indicative of the value the company was providing. People wanted to pay for it even though the company wasn’t charging them.
“I’m hosting my company’s code here. I don’t feel comfortable not paying you guys. Can I just send a check?”— Geoffrey Grosenbach, founder, PeepCode
One of the single most important factors in GitHub’s growth is the simplicity and elegance of its business model. If you want to host your code publicly, GitHub is free to use, forever. If you want to work on private repositories or proprietary code, you pay. The two use cases are completely different, which eliminates the risk of GitHub cannibalizing its audience with a freemium product.
The company could have easily walled GitHub off behind a paywall or subscription model and probably made quite a lot of money in the process, but it didn’t. The other element of GitHub’s business model that’s so brilliant is that transitioning from the freemium product to a private paid repository is so seamless. If a programmer is hosting their open-source personal projects on GitHub and using the product regularly, there’s an excellent chance they’ll recommend using GitHub at their day job.
As straightforward and logical as GitHub’s business model is, it was the only possible way GitHub could have effectively commercialized open-source software development the way it did. If GitHub had attempted to monetize all repositories from the outset, GitHub probably never would have become so beloved by the open-source community. Without this grassroots support, the company would not have survived.
Another factor that necessitated a smart approach to pricing structures was the reality of operating GitHub as a web service. Being the place where open-source code lived on the web sounded great—but somebody had to pay for the bandwidth. Luckily for GitHub, Geoffrey Grosenbach wasn’t the only enthusiastic early adopter who wanted to give money to GitHub. Several companies had also offered to pay GitHub to host their code, which led the company’s founders to further speculate about the company’s potential as a for-profit business.
“At this point we realized GitHub could probably do more than just recoup costs. It could be a real business. We decided to continue to offer unlimited public repositories for free, but we’d charge for private repositories. In other words, we’d charge the people asking to be charged.” — Chris Wanstrath
PJ Hyett formally joined GitHub as its third co-founder in January 2008. Just a few months later, on April 10, 2008, GitHub launched officially.
By 2009, GitHub’s growth was accelerating rapidly. Speaking at the Yahoo Developer Talk in February 2009, Preston-Werner told the crowd that more than 46,000 public repositories were being hosted on GitHub—approximately 17,000 of which had joined in the previous month alone. By the time Preston-Werner gave his next Yahoo Developer talk in July 2009, GitHub had more than 100,000 users and was hosting over 90,000 public repositories—a 95% increase in just five months.
What’s most remarkable about this period of GitHub’s growth is that the nascent company managed to attract its first 100,000 users in just over a year by word-of-mouth among the software development community. GitHub as a product was already incredibly sticky, purely by virtue of the problems it solved. It wasn’t as if there were other Git-based collaboration tools out there. GitHub had effectively created its own market by building a new service on top of emerging, difficult-to-use technology.
GitHub’s binary business model and popularity in the programming community definitely helped the company grow quickly. One aspect of GitHub’s early years that many people overlook, however, is how solving the big, ambitious problems experienced by all software developers also drove the development of GitHub as a product. Collaboration was the key, and access was the growth vector. GitHub reduced friction by allowing users to fork a repository without permission. By solving a difficult technical problem—forking code branches and the associated permissions issues—GitHub had also solved the equally difficult yet frustratingly ambiguous human problem of how to effectively collaborate with other programmers.
The market’s urgent need for a product like GitHub and the stickiness of the product itself were not the only factors in GitHub’s rapid early growth. The social aspect of GitHub was also a powerful driver of growth. Before GitHub, programmers had few ways to prove their programming chops, beyond answering whiteboard hypotheticals in technical interviews. Now, coders could publicly host their projects’ codebases, actually show prospective employers their code, and get involved in the wider software development community, all in one place. GitHub didn’t just benefit individual programmers, either. Recruiters could browse public repositories and user profiles to identify prospective hires and see what kind of projects applicants had been working on, making GitHub a valuable recruitment tool.
On June 29, 2010, GitHub introduces its Organizations feature, a tool that allows corporate users to manage group-owned repositories from a single, centralized dashboard. Although the introduction of Organizations was partly a response to companies who were clamoring to try GitHub—and make adopting it as frictionless as possible—it also revealed the company’s future ambitions. By 2010, it was clear to the founders that the single most important vector of revenue growth would be the adoption of GitHub at the enterprise and organizational levels. It would be over a year before GitHub would launch GitHub Enterprise, but Organizations was a clear signal of where the company’s intentions.
GitHub continued to attract users at an incredible pace. By the end of 2011, GitHub was hosting more than 2M repositories and had surpassed SourceForge, Google Code, and Microsoft’s CodePlex in terms of both users and commits. Like Organizations before it, the release of GitHub Enterprise telegraphed the company’s intentions to become indispensable to huge tech companies as well as individual coders, a direction the company would pursue aggressively between 2012 and 2015.
2012-2015: From Rapid Growth to ‘GitHub Everywhere’
By 2012, GitHub had become incredibly popular. For many programmers, the question wasn’t whether they used GitHub, but what they used it for. Not only had GitHub steadily attracted a strong user base with virtually no advertising, promotion, or venture capital funding, but it had also grown the number of corporate teams using GitHub to host private repositories of proprietary code. What GitHub needed to do now was scale revenue by penetrating further into the enterprise. The first thing GitHub did to accomplish this was hire Brian Doll, who became GitHub’s VP of Marketing and Strategy in February 2012. The second was raise $100M as part of its Series A round led by Andreessen Horowitz.
“Specifically, there’s a strategy called ‘GitHub Everywhere.’ We want everyone in software to be using GitHub. Individuals by themselves, small teams, students, as well as big, massive enterprises.” — Tom Preston-Werner
GitHub’s Series A round allowed the growing company to pursue its vision of “GitHub Everywhere” more aggressively. By the time GitHub raised its Series A, it had more than 1.7M users and was hosting over 3M repositories. In addition, the company had been growing revenue by 300% annually since 2008. With its new funding, GitHub could build upon this organic growth and target the Fortune 500 companies that would drive much of GitHub’s revenue further down the road.
While many entrepreneurs and investors applauded GitHub’s new partnership with Andreessen Horowitz, some expressed skepticism about GitHub’s sudden influx of cash. A small but vocal contingent of the open-source community felt GitHub’s acceptance of VC funding was a betrayal of the company’s bootstrapped ethos and jeopardized future open-source development. The tension between GitHub’s origins in open-source and its apparent future as an enterprise tool had long been a careful balancing act for the growing company.
Accepting one of the largest Series A rounds in history gave GitHub much more freedom, but it also placed even more pressure on a company already wrestling with the duality of its identity.
By 2012, GitHub had grown impressively. The company had created a solid product that solved urgent problems and had built an entire company around an emerging technology. But it became evident that GitHub’s bootstrapped approach to growth could only take them so far. To maintain the impressive momentum the company had established and realize its bolder ambitions, it needed capital. It got this capital from Andreessen Horowitz, which was the sole investor in GitHub’s Series A round of $100M in July 2012. GitHub would use this funding to hire additional engineering talent and develop new products.
It’s important to note that although GitHub had been entirely bootstrapped prior to Andreessen Horowitz’s Series A round, this was not a matter of conflicting ideologies. Some people believed that GitHub’s origins in the open-source community put the company at odds with the proprietary walled-garden approach favored by investors. This was not the case. GitHub didn’t refuse VC funding out of principle; it refused VC funding because it didn’t need it. By the time GitHub began looking for external investment, the product was already clearly defined with a large user base. Best of all, GitHub had been profitable practically since Day 1. This freedom allowed GitHub to intentionally shape not only its product but also the culture of the entire organization, completely free of investor influence.
“We still believe that taking too much money too early can be bad for a company. Too much outside influence can be dangerous. We’re four and a half years old now, so we’ve had a chance to really define ourselves. We haven’t ever been anti-VC, we’ve only been [against] people compromising their product for the wrong reasons.” — Tom Preston-Werner
At this point, GitHub’s growth ambitions were becoming clearer. Having already achieved significant growth and amassing a legion of loyal programmer evangelists, GitHub wanted to expand its reach—and its potential revenues. What’s interesting about GitHub’s Series A round isn’t the investor or the total sum raised, or even that GitHub waited four years before accepting venture capital as an already profitable business. What’s most interesting about GitHub’s Series A is the language Preston-Werner used in the announcement.
“Our company has been profitable for years, is growing fast, and doesn’t need money. So why bother? Because we want to be better. We want to build the best products. We want to solve harder problems. We want to make life easier for more people. The experience and resources of Andreessen Horowitz can help us do that.” — Tom Preston-Werner
Preston-Werner’s post used a lot of connective language, but what he was really getting at were the problems with coding as a technical discipline that GitHub was working to solve. This is one of the most fundamental misunderstandings that many people have about GitHub as a company and as a product. There is no arguing that GitHub has made coders’ lives easier, but that wasn’t the founders’ intent. They didn’t want to make coding easier for programmers—they wanted to make coding easier, period.
In many cases, GitHub had solved big, ambitious problems with programming itself. What was particularly brilliant about GitHub was that it did so by creating a product that solved those problems that also created a vast potential market for that product. Wanstrath and his friends could have focused on smaller, specific technical problems. Instead, they went after problems that were so big and so fundamentally inherent to programming at that time that solving them created a vast potential market for their product.
This appeal reached far beyond open-source hobbyists and script kids hacking in their bedrooms. It was also powerfully attractive to large corporate interests. By 2013, most of the Valley’s biggest tech companies were using GitHub, from tiny skunkworks projects to major proprietary systems. Adobe, Dropbox, Facebook, Google, and Twitter all had private repositories on GitHub. Some firms, such as Mozilla, had several hundred repos and hosted virtually everything on GitHub. Others, such as Facebook, had far fewer repositories (just 102 compared to Mozilla’s 687) but significantly higher engagement, with more than 15,000 forks across Facebook’s 102 repositories.
GitHub’s popularity and market penetration were driving incredible growth. By the end of 2015, GitHub had 2.8M users and was hosting 4.6M repositories. However, although GitHub had now become inextricably interwoven into coding culture, the company’s sights were set even higher. The next period of GitHub’s growth would see the platform position itself as the largest hub for open-source software in the world, aggressively pursue international expansion, and seek to become “the Facebook for developers.”
GitHub wasn’t just slowly devouring Silicon Valley—it had traveled all the way to the corridors of power in the nation’s capital. On May 9, 2013, the White House drafted and released the official Open Data Policy of the United States on GitHub. It was the first time that federal legislative policy had been shared in such a manner. Although the files themselves were of limited utility compared to the code projects hosted in GitHub’s millions of repositories, it was hugely important symbolically. Hosting governmental policy documents externally on the servers of a private company was unheard of, as was the notion of allowing the public to fork and merge policy documents.
Today’s news marks the first time a government entity has published law as a living, collaborative document. We’re excited to see how the Open Data Policy evolves with the input of the community, and we hope this is just the first of many.” — Ben Balter, Product Manager, GitHub
The announcement was incredible free PR for GitHub, and it also hinted at other potential use cases for GitHub that open-data advocates and tech-savvy policy wonks had been talking about for years—even if those use cases would ultimately never materialize.
2015-Present: Global Expansion, GitHub Goes to Washington (State)
By 2015, GitHub was version control for many programmers. But it was far more than just that: It was a social hub where coders could learn from one another. It was a programmer portfolio site, social network, and professional networking hub. It was where much of the world’s code lived, from scrappy open-source projects run by lone programmers to enormous code libraries that powered some of the most advanced technology companies in the world.
Of course, the bigger you are, the bigger a target you become. On March 28, 2015, GitHub endured the largest cyberattack it had experienced since its launch. The attack—a standard distributed denial of service attack, or DDoS—was believed to have originated in China. But the attack was not an attempt to cripple an American company for the benefit of an Asian competitor. Instead, the attack was allegedly aimed at just two GitHub projects. The first was GreatFire, an organization that works to help Chinese internet users circumvent the country’s so-called “Great Firewall of China.” The second was the GitHub page for a Chinese mirror of The New York Times‘s website, which also helps Chinese users access the newspaper from behind China’s sprawling surveillance apparatus. Although the attack was ultimately thwarted, it highlighted the dangers of hosting so much of the world’s code in one place—particularly code intended to subvert state surveillance apparatus.
Four months after the Chinese DDoS attack, GitHub entered its Series B round of funding at $250M, led by Sequoia Capital. This placed GitHub’s valuation at more than $2B. Speaking about the funding, Chris Wanstrath told reporters the company planned to use its Series B funding to make significant investments, develop new products, and—most significantly— expand internationally.
GitHub’s first overseas office was in Tokyo. GitHub’s choice of Japan as its first overseas location was highly strategic. Not only is Japan the world’s third-largest economy by GDP, but it’s also renowned for its technological innovation, making it a logical destination for a site hoping to host the world’s code. It didn’t hurt that companies including Hitachi Systems and Japanese media conglomerate CyberAgent were among GitHub Japan’s first customers.
GitHub continued to expand. By July 2015, GitHub had more than 9M users and was hosting over 21M repositories, officially making GitHub the largest code repository in the world. Although user growth was steady, it was the company’s continued expansion into the enterprise that drove much of the organization’s revenue growth during this period. GitHub was being used by more than half of the largest, wealthiest corporations in the United States—a manifestation of Tom Preston-Werner’s prescient vision of “GitHub Everywhere” from years before.
However, although GitHub was still growing—at a rate of 10,000 new users per workday by September 2015—the pace of that growth was slowing. GitHub was facing heightened competition from both Bitbucket and GitLab, and user growth suffered as a result. Revenue, on the other hand, was increasing rapidly. In September 2015, GitHub’s annual recurring revenue (ARR) was approximately $90M. By August 2016, that figure had risen to $140M. In the 23-month period from September 2014 to August 2016, revenue from GitHub’s personal plans had stagnated — but revenue from its Organization plans had almost doubled. Revenues from GitHub Enterprise had tripled. In September 2014, around 35% of GitHub’s ARR came from GitHub Enterprise. By August 2016, GitHub Enterprise made up half of GitHub’s ARR.
By 2017, it was clear that GitHub’s future would be shaped by its applications in the enterprise. There was talk of an IPO, rumors of unlikely acquisitions, and conspiracy theories about even less likely mergers. Everyone had a theory on GitHub’s next move—but few people saw what came next. On the morning of June 4, 2018, the tech world awoke to the incredible news that Microsoft had acquired GitHub for $7.5B.
“From the largest corporations to the smallest startups, GitHub is the destination for developers to learn, share and work together to create software. It’s a destination for Microsoft, too. We are the most active organization on GitHub, with more than 2 million ‘commits,’ or updates, made to projects.”
Within hours, Hacker News, Reddit, and TechDirt were awash with angry users who felt betrayed by GitHub’s acquisition. Many people pledged to leave GitHub in protest. Some users posted that they were already in the process of migrating their repositories from GitHub to competing services GitLab or Bitbucket. People made nervous jokes about the security of their code. Others cracked wise about how Clippy would soon be helping developers deploy their projects to Azure. Still, others drew parallels between the deal and Oracle’s acquisition of MySQL when it bought Sun Microsystems in 2009.
Beneath the sarcasm and the outrage, there was a very real sense that GitHub’s future was no longer as bright as it once was. However, what many people failed to realize is that, at this point, Microsoft’s acquisition of GitHub will have very little tangible negative impact on GitHub as a product. GitHub has been the industry standard in collaborative software development for a decade. Bitbucket and GitLab will inevitably gain some of the users fleeing Microsoft’s GitHub, but GitHub’s position in the industry and the functionality of GitHub as a product itself practically guarantees GitHub’s continued relevance, survival, and growth.
In addition, Microsoft’s considerable enterprise experience could make GitHub a highly strategic asset for Microsoft, particularly as the company positions itself as a platform and marketplace for developers. For Microsoft, acquiring GitHub isn’t about gaining GitHub as a product—it’s about acquiring the ecosystem of developers that GitHub brings with it.
Much of the chatter online seems to revolve around whether Microsoft’s acquisition of GitHub was a smart purchase. The real question is whether Microsoft will use GitHub smartly. As Microsoft’s acquisitions of LinkedIn and Minecraft developer Mojang have shown, Microsoft may not necessarily radically reinvent what GitHub does—at least, not right away.
Where Could GitHub Go from Here?
Now that Microsoft is the proud new owner of the world’s largest and most popular code repository, GitHub’s future trajectory will be determined entirely by how Microsoft sees GitHub as part of its long-term growth strategies.
1. Integration with Visual Studio.
Although there are dozens of potential moves Microsoft could make, now that it owns GitHub, one that’s almost inevitable is GitHub’s integration with Visual Studio, Microsoft’s enormously popular suite of developer tools. This aligns with Microsoft’s broader plans to move away from proprietary sales of Windows, and toward its growing ecosystem of cloud-based services.
2. Even more developer tools.
Even now, coding as a discipline is plagued with problems and inefficiencies. One of the most logical moves GitHub could make is developing additional tools to help devs focus on solving problems such as error tracking and deploying apps to Microsoft Azure, and could even replace current QA workflows with AI-driven applications. GitHub has barely scratched the surface of what’s possible, and Microsoft’s renewed focus on its cloud-based developer ecosystem seems perfectly aligned with GitHub’s potential as a product.
3. Peripheral products/services that appeal to professionals beyond developers.
GitHub is already making inroads with professionals besides software engineers, such as with product managers. Another potential move for GitHub could be the introduction of additional features and functionality that appeal to these professionals, such as integrated project management tools. This seems especially likely, given Microsoft’s apparent desire to double down on enterprise applications and team-based collaboration tools.
3 Lessons We Can Learn from GitHub
GitHub may have found a new home in Redmond, but there are still plenty of lessons to be learned from GitHub.
1. Find a big problem to solve.
Making Git easier to use was a goal of GitHub, but it was never the ultimate goal. The true mission of GitHub was to make collaborating on and writing software easier. Every software developer in the world struggled with the problems that GitHub was trying to solve. This created an immense potential market that GitHub was ideally positioned to target.
Take a look at your current product and ask yourself the following questions:
- Does your product solve a highly specific problem experienced by a small group of people? Or does it solve a big, broad problem experienced by lots of people? Specialization can be a powerful differentiator, but tackling big, ambitious problems gives your product a much greater potential market.
- Do you (or would you) use your own product in your day-to-day work? Lots of companies talk a good game about “eating your own dog food,” but far fewer actually do it.
- If you’re not using your own product, why not? Is there a problem with your product, or are you not personally affected by the problem your product claims to solve? Both of these scenarios are serious problems. Not using your own product internally raises questions of whether there’s a genuine need for your product. If you’re not personally experiencing the problem your product solves, what makes you the right company to solve it?
2. Continuously solve painful problems, better and better.
Part of what drove such incredible growth for GitHub was the company’s relentless focus on solving not only big, ambitious problems, but also painful problems that all software developers experience. This created an enormous potential user base for GitHub and allowed the company to fundamentally reshape software development as we know it.
Think about your product and its place in the broader vertical your company operates in, then ask yourself:
- If you could somehow add a brand-new feature or function to your existing product, what would that feature be, and what problem would it solve?
- Why isn’t this feature already in your product, or in development? Is it too ambitious? Too difficult? Too broad? How could you overcome these obstacles to implement this feature?
- What makes the problem you’re trying to solve so painful? Is it a technical problem or a human problem?
GitHub succeeded because it solved a technical problem—the need for a better, more intuitive version control system—that had significant potential to solve a human problem, namely collaborating on software projects easily, securely, and remotely. Focusing on the technical problem also allowed GitHub to solve a human problem, which was an immensely important factor in GitHub’s success.
3. Cultivate your company culture early on.
Even in its early years, GitHub recognized the importance of culture. The company deliberately and proactively created its own culture, rather than allowing culture to develop. Contrary to conventional wisdom, culture isn’t solely an incidental by-product of behavior—it’s the result of considered, intentional action and purposeful decision-making.Culture is a crucial factor in the growth of any company, from scrappy three-person startups to multinational conglomerates.
Take a look around your company, and think about the following questions:
- How does your company’s culture reflect your organization’s values? Even in the early days, GitHub took great delight in poking fun at traditional notions of corporate success, from their relatively flat hierarchical structure to the faux-wood paneling and brandy decanters in the company’s mock boardroom. What values and brand attributes does your company’s culture say about you?
- To what extent do your employees shape your company’s culture? Put another way, how much of your company’s identity is dictated from the top down, and how much has emerged organically over time as a result of the hires you’ve made?
- How do you think your competitors perceive your company and your product? How much of this perception would be based on the culture of your organization?
Ready, Set, Git
GitHub achieved incredible success by doing two things: identifying a huge, painful problem to solve; and creating a popular, sticky product that made it easier for people to work together and share code. The biggest challenge facing GitHub now is to devise a way to further ingratiate itself into coding as a technical discipline while simultaneously appealing to professionals beyond software developers.
Microsoft might not be the most logical home for GitHub, given the company’s historic hostility toward the open-source community. That said, Microsoft’s considerable enterprise expertise and forward-thinking leadership could be a surprisingly good fit for the Githubbers who make their way north to Redmond from San Francisco. The question on everybody’s lips now is, just how does Microsoft plan to put its shiny new toy to work?
