Open Source on GitHub: Sponsors, Marketplace, InnerSource, Forks and Discovery (GH-900)

Open source software is code published under a license that lets anyone read, use, modify and share it within the license's terms. On GitHub that usually means a public repository with a LICENSE file, a README and contribution guidelines.

The benefits come from many people being able to see and build on the same code:

• Transparency and review: anyone can read the code, so more people spot defects and security problems and report or fix them through issues and pull requests.
• Reuse: other projects can use the code under its license instead of writing the same thing again.
• Shared improvement: features and fixes arrive from users with different needs, and the project's skills and reputation grow with its community.
• Learning and hiring: public work is a visible record that developers and companies can point to.

Open source is about who may use the code, not who may change the original. Outsiders contribute by forking the repository and opening pull requests, and the maintainers stay in control: they decide what to merge and remain responsible for the project's upkeep, with GitHub acting as the host. The license is what grants others the right to copy and reuse the code.

GitHub Sponsors is GitHub's program for paying developers and organizations who build and maintain open source work. A sponsored account joins the program, sets up a Sponsors profile and defines tiers; sponsors then pick a tier and pay from their own personal or organization account.

• Tiers are set by the sponsored account and can be monthly (recurring) or one-time, each with its own amount and optional rewards.
• Who can be sponsored: individual developers and organizations that contribute to open source.
• Who can sponsor: personal accounts and organization accounts.

Fees depend on who pays, not who receives:

Sponsors is about money for people. It is not where you buy software (that is the Marketplace), and showing interest through stars or watching transfers nothing to a maintainer.

A repository shows a Sponsor button when it has a FUNDING.yml file in its .github folder on the default branch. The file lists where people can fund the project, and the button opens those links. (The maintainer also enables Sponsorships under the repository's Settings > Features.)

# .github/FUNDING.yml
github: [octo-maintainer]          # GitHub Sponsors usernames
open_collective: date-parser       # an external funding platform
custom: ["https://example.org/donate"]  # your own funding links

Keys cover GitHub Sponsors usernames, supported external platforms (such as Open Collective, Patreon, Ko-fi, Liberapay and Tidelift) and custom URLs. An organization can put a default FUNDING.yml in its .github repository so that every repository without its own file shows the same button.

FUNDING.yml only displays funding links; it moves no money by itself, and the links only help if they point at the people or platforms that actually receive the funds. GitHub looks for this one file name in this one place: the button comes from FUNDING.yml on the default branch and from nothing else in the repository.

GitHub supports open source by making public projects cheap to host, build and maintain, and by funding the people who run them. The programs to know:

• Free public repositories with issues, pull requests, Discussions, Projects and wikis, plus security features such as Dependabot alerts, code scanning and secret scanning available for public repositories.
• Free GitHub Actions for public repositories on standard GitHub-hosted runners. Self-hosted runners are free with Actions in any repository: you supply and pay for the machine, GitHub charges nothing for the minutes. Larger runners (GitHub-hosted machines with more CPU and memory) are always billed, even for public repositories, and you cannot register your own hardware as one.
• Free Copilot Pro for maintainers of popular open source repositories, with eligibility reviewed regularly by GitHub (verified students and teachers have a separate free offer).
• GitHub Sponsors, with no fee on sponsorships from personal accounts.
• Discovery: Explore, trending repositories, topics and the good first issue label help newcomers find projects to use and contribute to.

These programs lower the cost of running a public project; they do not change who owns it or what other products cost. Paid plans and third-party tools keep their own pricing, and maintainers keep responsibility for their projects.

To see what a person or organization does across GitHub, follow them; to get notifications about one repository, watch it; to bookmark a repository, star it. These three are easy to confuse and are tested as near-twins.

Watch settings decide how much a repository notifies you:

• Participating and @mentions (the default): only threads you take part in or where you are @mentioned.
• All Activity: every issue, pull request, discussion and release.
• Custom: pick event types, for example only Releases, or only issues and pull requests.
• Ignore: mutes the repository's notifications; it saves no bookmark.

Following a person or organization is not membership: an organization's public activity reaches your dashboard without joining it. Following organizations is labelled public preview in GitHub's documentation. Watching every repository a person owns is not the same as following them: it floods you with notifications and still does not show what they star or create elsewhere.

GitHub Marketplace is GitHub's catalog of GitHub Actions and apps (GitHub Apps and OAuth apps) built by GitHub and third parties to extend your workflows: CI steps, code quality and security checks, project tools, chat integrations and more. You find an action there and reference it in a workflow, or install an app on your account or organization.

• Free listings: anyone can publish an action, and developers can list free apps.
• Paid plans are only for apps (not actions), the app must be owned by an organization, and that organization must complete publisher verification before it can publish paid plans. Source code does not have to be public.
• Paid plans are bought by the customer through the listing; GitHub handles billing for them.

Keep the neighbours apart: Sponsors funds people, Packages hosts software packages (npm, container images and so on), and Explore helps you discover repositories and topics. Only Marketplace is the place to find and add actions and apps.

InnerSource is the use of open source practices (transparency, open contribution through pull requests, public discussion and shared documentation) for code that stays inside one organization. Teams can read, reuse and improve each other's work, but nobody outside the company sees it. It is not open source, which publishes code to everyone, and it is not a branching model such as GitHub flow.

On GitHub, InnerSource is usually built on internal repositories:

Internal visibility is available to organizations owned by an enterprise account (GitHub Enterprise Cloud or Enterprise Server). Visibility alone does not make InnerSource work. The practices that do:

• A clear README and a CONTRIBUTING.md explaining how other teams propose changes.
• Trusted committers: named maintainers who welcome, review and mentor contributions from other teams, so pull requests don't wait for weeks.
• Pull requests with owner review, often enforced with CODEOWNERS and branch protection, rather than giving every team direct write access to the main branch.
• Changes that flow back into the shared repository, not ones left to drift in private copies.

Use a fork when someone wants to contribute changes back to a repository; use a template when someone wants to start a new, independent project from it.

Someone without write access cannot push a branch to the original repository; the standard open source path is fork → commit in the fork → pull request to upstream. A repository becomes a template when its owner ticks Template repository in its settings; users then choose Use this template. How templates are configured is covered in the repository management lesson; here the question is which one promotes the collaboration you want.

A repository is discoverable when the right people can see it and find it by subject. On GitHub that comes down to three things:

• Visibility: public repositories are visible to anyone; internal ones only within the enterprise; private ones only to people granted access.
• Topics: subject tags in the repository's About settings (for example terraform, kubernetes). Clicking a topic opens GitHub's page for that subject, listing other repositories tagged with it. Topics are short lowercase tags chosen by the repository's maintainers.
• A clear description, README and community files, so a visitor understands the project and how to use or contribute to it.

Topics are the repository-level classification. Other metadata in a repository describes things inside it: labels sort issues and pull requests, tags mark versions and documentation explains use. Only topics place the repository itself on GitHub's subject pages.

When a scenario stacks several requirements, settle each with its own decision: visibility decides who can see the repository, fork versus template decides whether copies keep history and a link back to the original, and topics decide whether people can browse to it by subject. Each choice answers a different requirement, so read every constraint before picking.