What Is Open Source, and How Did GitHub Grow and Make Money?

Open source is not simply about making source code public. It is a way of granting others the rights to use, study, modify, and redistribute software under a defined license. GitHub grew into a commercial platform by connecting this type of collaborative development into a single workflow for repositories, version control, code review, and automation.

GitHub's core business model is not to sell public open-source projects directly. It attracts a large base of free users, then charges for the private collaboration, access controls, security, compliance, automation, cloud development environments, and artificial intelligence features that businesses need.

Table of Contents

• The precise meaning of open source
• The background behind the open-source movement
• How open-source development works
• The differences between open source, Git, and GitHub
• GitHub's origins and growth
• GitHub's revenue model
• Why free open source creates economic value
• Limitations and evaluation criteria

What Exactly Is Open Source?

Open-source software is software for which the copyright holder grants users rights through a license, including the rights to run, study, modify, and redistribute it. The key issue is not merely whether the code can be seen, but which rights are legally permitted.

According to the Open Source Initiative (OSI) definition, an open-source license must permit free redistribution, provide source code, and allow the distribution of modifications and derived works. It must not discriminate against any person, group, or field of use. As a result, if restrictions such as “for non-commercial use only” or “may not be used in competing products” apply, the software is difficult to recognize as open source in the usual sense even if its source code is public. OSI의 Open Source Definition↗

This distinction is especially important for public repositories on GitHub. Even if a repository is publicly visible to everyone, default copyright law applies if it has no open-source license. Others may view or fork the repository within the GitHub service, but they do not automatically gain the right to freely copy, modify, and distribute the code. GitHub also explains that a license stating permissions for use is necessary for a project to be truly open source. GitHub의 저장소 라이선스 안내↗

The following three statements therefore mean different things:

• “You can view the code” describes whether the source is public.
• “You can use it for free” describes its price.
• “It is open source” describes the rights granted by its license.

Free software is not necessarily open source, and open-source software can also be sold.

What Background Led to the Open-Source Movement?

The practice of sharing software code and improving it collaboratively existed in early computer research communities. However, as software developed into an independent commercial product and copyright and usage restrictions became stronger, concern also grew around users' ability to study and fix software.

In the 1980s, Richard Stallman launched the GNU Project and the free software movement. In free software, “free” refers not to price, but to users' freedom to run, study, modify, and redistribute a program, either in its original or modified form. GNU의 자유 소프트웨어 정의↗

The name “open source” was created at a strategy meeting held shortly after Netscape announced plans to release its browser source code in 1998. That same year, Eric Raymond, Bruce Perens, and others established the OSI and organized the Open Source Definition based on the Debian Free Software Guidelines. The goal was to explain the practical advantages of collaborative development more clearly to businesses and the public. OSI 역사↗

Free software and open source largely overlap in the licenses they accept, but they differ in emphasis.

This difference does not mean that either side is always superior. It means that the same program can be explained from one perspective by focusing on users' rights, and from the other by focusing on the efficiency of transparent development and distributed collaboration.

How Does Open-Source Development Work?

Open source does not mean that “anyone can change the code however they want.” Participation may be open, but project maintainers and established procedures determine what is incorporated into an official version.

A typical development process works as follows:

1. A maintainer publishes the source code, license, usage instructions, and contribution rules.
2. A user clones or forks the repository to create an independent workspace.
3. Bug fixes or feature development are performed in a separate branch.
4. The contributor submits a Pull Request containing the changes and their rationale.
5. Maintainers review the code, test results, design direction, and security impact.
6. Only changes that meet the criteria are merged into the official repository.
7. A new version is released, and issues discovered afterward are tracked again.

Different roles exist in this process. Users use the software and report issues. Contributors submit code or documentation. Maintainers handle reviews and releases. A project steering committee or foundation may also manage trademarks, budgets, and decision-making rules.

In other words, the “openness” of open source does not mean there is no decision-making authority. Opportunities to participate and rights to use the code are open, while official projects have control structures for maintaining quality.

How Do Open-Source Licenses Differ?

Open-source licenses can broadly be understood as permissive licenses and copyleft licenses.

Permissive licenses

MIT, BSD, and Apache License 2.0 are common examples. As long as conditions such as retaining copyright notices and license text are met, these licenses generally allow modified code to be included in proprietary software.

This makes them easy for companies to integrate into commercial products, but there is no guarantee that improved code will return to the original community. Apache License 2.0 also includes explicit patent-related provisions, so its legal conditions are not identical to those of the MIT License.

Copyleft licenses

The GNU General Public License (GPL) is a representative example. When modified code is distributed, or when a derived work combined with that code is distributed, it can require source code to be provided under the same license.

Copyleft does not prohibit commercial use. Software may be sold commercially, but the source-disclosure obligations within the scope defined by the license must be followed. Variants such as the LGPL and AGPL are designed with different conditions for library linking and network services.

When choosing a license, it should not be selected simply because a well-known project uses it. You should examine the disclosure scope for derivative works, patent provisions, network service delivery, and compatibility with other licenses.

What Is the Difference Between Open Source, Git, and GitHub?

These three concepts often appear together, but they operate at different layers.

• Open source is a concept that describes software usage rights and a method of collaborative development.
• Git is an open-source version control program that manages the history of file changes in a distributed manner.
• GitHub is a commercial service that hosts Git repositories online and provides code review, issue management, automation, security, and collaboration features.

Git was created in 2005 after the relationship between the Linux kernel development community and the proprietary distributed version control tool BitKeeper ended. A tool was needed that could handle the speed, distributed work, and large number of parallel branches required by a project as large as Linux. Git 공식 역사↗

With Git, each developer can maintain a repository containing the complete change history without always being connected to a central server. However, command-line Git alone made it inconvenient to manage who proposed a change, why it was needed, who would review it, and when it would be merged. GitHub organized precisely this collaborative process through a web interface.

Git can be used without GitHub, and repositories can be run on GitLab, Bitbucket, or self-hosted servers. Conversely, GitHub contains not only open source but also private corporate code and public code without a license. GitHub and open source are not synonymous.

How Did GitHub Begin?

GitHub was developed around Tom Preston-Werner, Chris Wanstrath, and PJ Hyett, and it launched as a public service in 2008. Scott Chacon, a Git expert who later became known as the author of Pro Git, also joined the early team.

The first commit to GitHub's internal repository was made in October 2007, and the service launched in April 2008. Around its first anniversary, GitHub had more than 20,000 public repositories and four full-time employees, without having received any outside investment. GitHub의 첫해 기록↗

The problem GitHub aimed to solve was not simply file storage. It sought to create a collaborative environment that visualized changes across distributed Git repositories, helped developers discover one another's work, and made change proposals easy to review. The network graph GitHub released in 2008 was also an attempt to show the relationships among multiple users' branches and commits on a single screen. 초기 Network Graph 소개↗

This approach later came to be called “social coding.” Developers' profiles, activity histories, follows, forks, stars, issues, and pull requests became connected to code repositories, turning the development process itself into a network that could be searched and observed.

Why Did GitHub Grow So Quickly?

GitHub's growth cannot be explained solely by offering free Git storage. Technical timing, user experience, network effects, and an enterprise business model worked together.

It made Git's complex collaboration process understandable on the web

Branches, commits, and merges are powerful Git features, but they are not easy for beginners to understand through commands alone. GitHub brought code differences, discussions, review results, and test status together in the pull request interface.

Rather than circulating patch files by email, developers could share changes through a single link. Project maintainers could reduce review costs because the code and the discussion process were recorded together.

Public repositories created a developer network

When a project joins GitHub, that project's users and contributors are also more likely to create accounts. Those users then create other projects or participate in existing ones.

As the number of repositories increases, developers visit GitHub to find code. As the number of developers increases, project maintainers choose GitHub to attract contributors. This is a two-sided network effect.

Public activity histories also served as developer portfolios. Companies could review applicants' actual code and collaboration experience, while developers had an incentive to build activity histories for employment opportunities and reputation.

It grew open source and enterprise products at the same time

GitHub lowered the barrier to entry for public open-source repositories while charging for private repositories from its early days. In 2011, it launched GitHub Enterprise, which could run on internal company servers and addressed enterprise needs such as authentication, backups, and team management. GitHub Enterprise 출시 기록↗

This structure allowed individual developers to learn how to use GitHub through open-source projects, then use an enterprise version of the same workflow after joining a company. It enabled bottom-up adoption, with developers bringing the product into their organizations without separate sales efforts aimed at individuals.

GitHub stated that it had achieved profitability and growth through paid services without outside investment, and it raised its first outside investment in 2012. GitHub의 2012년 투자 발표↗

It expanded the free tier and reduced reasons to move to competing services

In 2019, GitHub began offering private repositories to free personal accounts. In 2020, it also removed collaborator limits for free private repositories and made core team features free. Advanced permission management, security, and support features needed by businesses remained paid offerings. GitHub Free 확대 발표↗

Expanding the free tier means giving up some subscription revenue in the short term. However, it keeps more individuals and small teams on the platform and creates opportunities to convert them to Team, Enterprise, security, and AI products as their organizations grow.

How Did Microsoft's Acquisition Affect GitHub's Growth?

Microsoft agreed to acquire GitHub in 2018 for $7.5 billion in Microsoft stock. At the time, GitHub reported more than 28 million users. Microsoft stated that GitHub would maintain independent operations and its developer-first character. Microsoft의 GitHub 인수 발표↗

The acquisition aligned strategic needs on both sides. GitHub could use global cloud infrastructure, an enterprise sales network, and security and compliance capabilities. Microsoft could move beyond its past image as a company centered on Windows and proprietary software and establish touchpoints with developers regardless of operating system or programming language. It also gained opportunities to connect Azure, Visual Studio, VS Code, and GitHub.

After the acquisition, GitHub expanded beyond repository hosting into a platform covering the full development lifecycle. GitHub Actions automates builds, tests, and deployments; Codespaces provides cloud development environments; Advanced Security products scan code, dependencies, and secrets; and Copilot provides AI-powered code writing and review features.

In October 2022, Microsoft announced that GitHub had reached $1 billion in annual recurring revenue (ARR) and had grown to more than 90 million users, three times the number at acquisition. Microsoft FY2023 1분기 실적 발표↗

GitHub announced that more than 100 million developers used the platform in 2023 and more than 180 million did so in 2025. In 2025, total projects reached 630 million, and GitHub counted about 81.5% of all contributions as occurring in private repositories. This shows that GitHub has become both an open-source space and large-scale enterprise development infrastructure. GitHub Octoverse 2025↗

However, these figures are platform metrics counted according to GitHub's own criteria. The number of registered developers should not be interpreted as equivalent to monthly active users or paying customers. Microsoft also does not disclose GitHub's current revenue and operating profit in detail every year as a standalone business unit, so the $1 billion ARR reported in 2022 should be viewed as a representative size metric disclosed at that time, not as current revenue.

Specifically, Where Does GitHub Make Money?

GitHub's revenue model can be summarized as a freemium model: it acquires users through a free public platform and charges for the control and productivity organizations need to operate.

Per-user seat subscriptions

The free plan enables individuals and small teams to use core repository features. The Team plan provides advanced collaboration features, while the Enterprise plan offers security, compliance, centralized administration, and deployment options.

According to the official pricing page checked in September 2026, Team starts at $4 per user per month and Enterprise starts at$21 per user per month. Actual amounts may differ based on contract term, region, taxes, and large-contract terms. GitHub 공식 가격표↗

Seat-based billing has the advantage that recurring revenue can grow as a company's headcount increases. Once code and work processes become established on the platform, switching costs also increase, making contracts more likely to be retained.

AI product subscriptions and usage-based billing

GitHub Copilot has paid plans for individuals and organizations. Companies buy seats for each user, and additional usage charges may apply when AI usage included in a plan is exceeded. Copilot is therefore developing into a model that combines traditional software subscriptions with billing for AI compute usage. GitHub Copilot 조직 청구 안내↗

Copilot not only adds a new revenue source for GitHub but also causes AI to be consumed within established workflows involving repositories, issues, pull requests, and code review. This makes it easier to cross-sell additional products to existing platform customers than it would be to sell a separate AI tool.

Security and compliance products

Large enterprises do not pay merely for a place to store code. They need account controls, audit logs, single sign-on, secret detection, code vulnerability analysis, supply chain management, and regulatory compliance.

As reliance on open-source dependencies grows, organizations must continuously scan for vulnerable packages and leaked credentials. The expansion of the free ecosystem paradoxically also increases the need for enterprise security products.

Compute, storage, and automation usage

Services such as GitHub Actions, Codespaces, and Packages include a certain amount of usage in a plan and charge for overages. An enterprise bill may include not only Enterprise licenses but also excess use of Actions or Codespaces and additional licenses for products such as Copilot and security tools. GitHub Enterprise 청구 구조↗

This model allows GitHub's revenue to grow as development activity increases. On the other hand, GitHub also bears the costs of execution servers, storage devices, networks, and AI models, so not all usage revenue is profit.

Marketplace transaction fees

Third-party developers can sell paid apps through GitHub Marketplace. GitHub provides payment and subscription management and retains a portion of transaction value as an operating fee. According to official documentation, the retained share applied to app transactions since 2021 is 5%. GitHub Marketplace 판매 대금 안내↗

Beyond direct Marketplace fees, it is also important that external tools become centered on GitHub. As more apps are used, more development tools must be replaced when leaving GitHub, strengthening the platform's staying power.

Why Does Free Open Source Have Economic Value for GitHub?

For GitHub, free public repositories are not simply a cost item. They are a core asset for user acquisition and ecosystem formation.

First, open-source projects bring in new users. Developers who want to use a specific library, report an issue, or submit a patch create GitHub accounts. GitHub can acquire these users without spending on advertising.

Second, open-source activity makes GitHub's way of working a de facto industry standard. Developers learn forks, issues, and pull requests at school or through personal projects, then prefer the same approach at work.

Third, the public ecosystem and private enterprise development depend on each other. Companies' private products also use countless public libraries and tools. In GitHub's 2025 data, most contribution activity occurred in private repositories, while public projects made up the majority by repository count. The free public ecosystem provides the foundation for paid enterprise work.

Fourth, more active public projects increase demand for security and automation. Dependency updates, malicious-package detection, license management, and large-scale testing and deployment all become necessary.

GitHub's support for free open source is therefore difficult to explain as only philanthropy or only commercial activity. It provides genuine value to the developer community while serving as a long-term distribution strategy leading to the paid enterprise market.

How Do Open-Source Companies Generally Make Money?

GitHub's business model is one of several revenue models that use open source. Open-source companies often charge not for the reproducible code itself, but for operational convenience, accountability, security, and expertise.

• Support and consulting: They provide software for free and charge for installation, incident response, training, and long-term support.
• Managed cloud: Alongside open source that customers can install themselves, they sell SaaS that operates it on the customer's behalf.
• Open core: They make core features public while providing enterprise management, security, and analytics features under proprietary licenses.
• Dual licensing: They offer the same code under both an open-source license and a commercial license, allowing users to choose based on their circumstances.
• Hosting and usage: They charge based on storage, network, computing, and automation execution usage.
• Sponsorships and donations: Individuals, companies, and foundations support maintainers or project operations.
• Certification and training: They earn revenue through official training, examinations, technical certifications, or partner programs.

These models work because software costs are not limited to the license price. Businesses consider total cost of ownership, including installation time, outage risk, security incidents, updates, regulatory compliance, and shortages of specialized personnel. Even if they can obtain the code for free, they may be willing to pay for reliable operational accountability.

What Are the Limitations of Open Source and GitHub?

Open source does not automatically become secure and sustainable software simply because it has many participants.

Maintenance burdens can be concentrated among a few people

Even a widely used library may depend on only a few maintainers for actual review and releases. As usage grows, the burden of issue reporting and security response increases, while maintainers' compensation may not grow with it.

Public review does not guarantee quality

The fact that source code is public is different from the fact that someone has reviewed it sufficiently. Supply chain risks include vulnerabilities, malicious contributions, compromised maintainer accounts, and tainted dependencies.

License obligations can be overlooked

Open source is not a copyright-free public good. Each license's conditions must be followed, including retaining copyright notices, providing source code, marking changes, and applying the same license. License compatibility must be reviewed especially in commercial products that combine many dependencies.

Platform concentration creates new dependencies

Because Git is distributed, repositories can be moved to other servers. However, fully migrating issues, pull request discussions, Actions workflows, access policies, Marketplace apps, and security records is much more difficult.

The more convenient GitHub becomes, the more development communities may depend on a single company's pricing, policies, incident response, and feature changes. It is necessary to clone code locally, back up releases and documentation, and understand dependencies on specific platform features.

What Are Common Misconceptions?

“It is public on GitHub, so it is open source”

Without a license, ordinary open-source usage rights do not arise. Visibility and licensing are separate settings.

“All open source is free”

There may be no copying cost, but operations, support, cloud services, training, and security features can have costs. Open-source licenses do not prohibit paid sales.

“Anyone can change the official code however they want”

The right for anyone to modify their own copy differs from the authority to incorporate changes into the official project. Maintainers and governance rules decide whether changes are officially included.

“GitHub itself is open source”

GitHub hosts open-source projects at scale and releases various open-source tools, but the entire GitHub service is not a single open-source product. GitHub is a commercial platform owned by Microsoft.

“Because GitHub has many users, most of them are paying users”

GitHub's reported developer counts include free accounts. Total registered developers, active developers, enterprise customers, and paid seats are different metrics.

“Microsoft operates GitHub for free”

Although free repositories are widely available, GitHub generates revenue from enterprise seats, AI, security, automation, compute, storage, and the Marketplace. Free users provide both potential conversion to paid customers and network value.

How Should You Evaluate an Open-Source Project?

When adopting open source in a real project, do not look only at star counts or GitHub rankings. Review the following items together:

• The LICENSE file and legal compatibility with your intended use
• The frequency of recent releases and security updates
• The number of core maintainers and dependence on specific individuals
• The review speed for issues and pull requests
• The existence of testing, automation, and vulnerability-reporting procedures
• The completeness of documentation and upgrade guidance
• The personnel and costs required for self-hosting
• Dependence on GitHub or a particular cloud service
• Available alternatives and migration feasibility if the project is discontinued

The same principles apply when selecting GitHub as a work platform. Rather than comparing only free prices, assess required permission management, auditing, security, automation usage, AI usage, data location, incident response, and migration costs together.

How Should the Relationship Between Open Source and GitHub Be Understood?

Open source is a set of rules that distributes rights to use and improve software collaboratively. Git is a tool for managing the history of those changes in a distributed way, and GitHub is a platform that intermediates Git-based collaboration at scale.

GitHub did not invent open source. Instead, it simplified the discovery, copying, discussion, review, and merging processes needed by open-source communities into a unified web workflow. Public projects created a developer network, and that network drew private enterprise development onto GitHub as well.

As a result, rather than charging admission for public code, GitHub built a model that charges for the control, security, automation, computing, and AI that businesses need to collaborate at scale. It began with an early model of “public is free and private is paid,” but it can now be understood as a development-platform business in which “basic collaboration is free and features that solve organizational complexity are paid.”