티스토리 수익 글 보기

So much of what you interact with on GitHub depends on search—obviously the search bars and filtering experiences like the GitHub Issues page, but it is also the core of the releases page, projects page, the counts for issues and pull requests, and more. Given that search is such a core part of the GitHub platform, we’ve spent the last year making it even more durable. That means, less time spent managing GitHub Enterprise Server, and more time working on what your customers care most about. 

In recent years, GitHub Enterprise Server administrators had to be especially careful with search indexes, the special database tables optimized for searching. If they didn’t follow maintenance or upgrade steps in exactly the right order, search indexes could become damaged and need repair, or they might get locked and cause problems during upgrades. Quick context if you’re not running High Availability (HA) setups, they’re designed to keep GitHub Enterprise Server running smoothly even if part of the system fails. You have a primary node that handles all the writes and traffic, and replica nodes that stay in sync and can take over if needed.

Much of this difficulty comes from how previous versions of Elasticsearch, our search database of choice, were integrated. HA GitHub Enterprise Server installations use a leader/follower pattern. The leader (primary server) receives all the writes, updates, and traffic. Followers (replicas) are designed to be read-only. This pattern is deeply ingrained into all of the operations of GitHub Enterprise Server.

This is where Elasticsearch started running into issues. Since it couldn’t support having a primary node and a replica node, GitHub engineering had to create an Elasticsearch cluster across the primary and replica nodes. This made replicating data straightforward and additionally gave some performance benefits, since each node could locally handle search requests. 

Unfortunately, the problems of clustering across servers eventually began to outweigh the benefits. For example, at any point Elasticsearch could move a primary shard (responsible for receiving/validating writes) to a replica. If that replica was then taken down for maintenance, GitHub Enterprise Server could end up in a locked state. The replica would wait for Elasticsearch to be healthy before starting up, but Elasticsearch couldn’t become healthy until the replica rejoined.

For a number of GitHub Enterprise Server releases, engineers at GitHub tried to make this mode more stable. We implemented checks to ensure Elasticsearch was in a healthy state, as well as other processes to try and correct drifting states. We went as far as attempting to build a “search mirroring” system that would allow us to move away from the clustered mode. But database replication is incredibly challenging and these efforts needed consistency.

What changed?

After years of work, we’re now able to use Elasticsearch’s Cross Cluster Replication (CCR) feature to support HA GitHub Enterprise. 

“But David,” you say, “That’s replication between clusters. How does that help here?” 

I’m so glad you asked. With this mode, we’re moving to use several, “single-node” Elasticsearch clusters. Now each Enterprise server instance will operate as independent single node Elasticsearch clusters.

CCR lets us share the index data between nodes in a way that is carefully controlled and natively supported by Elasticsearch. It copies data once it’s been persisted to the Lucene segments (Elasticsearch’s underlying data store). This ensures we’re replicating data that has been durably persisted within the Elasticsearch cluster.

In other words, now that Elasticsearch supports a leader/follower pattern, GitHub Enterprise Server administrators will no longer be left in a state where critical data winds up on read-only nodes.

Under the hood

Elasticsearch has an auto-follow API, but it only applies to indexes created after the policy exists. GitHub Enterprise Server HA installations already have a long-lived set of indexes, so we need a bootstrap step that attaches followers to existing indexes, then enables auto-follow for anything created in the future.

Here’s a sample of what that workflow looks like:

function bootstrap_ccr(primary, replica):
  # Fetch the current indexes on each 
  primary_indexes = list_indexes(primary)
  replica_indexes = list_indexes(replica)

  # Filter out the system indexes
  managed = filter(primary_indexes, is_managed_ghe_index)
  
  # For indexes without follower patterns we need to
  #   initialize that contract
  for index in managed:
    if index not in replica_indexes:
      ensure_follower_index(replica, leader=primary, index=index)
    else:
      ensure_following(replica, leader=primary, index=index)

  # Finally we will setup auto-follower patterns 
  #   so new indexes are automatically followed
  ensure_auto_follow_policy(
    replica,
    leader=primary,
    patterns=[managed_index_patterns],
    exclude=[system_index_patterns]
  )

This is just one of the new workflows we’ve created to enable CCR in GitHub Enterprise Server. We’ve needed to engineer custom workflows for failover, index deletion, and upgrades. Elasticsearch only handles the document replication, and we’re responsible for the rest of the index’s lifecycle. 

How to get started with CCR mode 

To get started using the new CCR mode, reach out to support@github.com and let them know you’d like to use the new HA mode for GitHub Enterprise Server. They’ll set up your organization so that you can download the required license.

Once you’ve downloaded your new license, you’ll need to set `ghe-config app.elasticsearch.ccr true`. With that finished, administrators can run a `config-apply` or an upgrade on your cluster to move to 3.19.1, which is the first release to support this new architecture.  

When your GitHub Enterprise Server restarts, Elasticsearch will migrate your installation to use the new replication method. This will consolidate all the data onto the primary nodes, break clustering across nodes, and restart replication using CCR. This update may take some time depending on the size of your GitHub Enterprise Server instance.

While the new HA method is optional for now, we’ll be making it our default over the next two years. We want to ensure there’s ample time for GitHub Enterprise administrators to get their feedback in, so now is the time to try it out. 

We’re excited for you to start using the new HA mode for a more seamless experience managing GitHub Enterprise Server. 

The post How we rebuilt the search architecture for high availability in GitHub Enterprise Server appeared first on The GitHub Blog.

Welcome back to GitHub for Beginners, our series designed to help you navigate GitHub like a pro and get the most out of it! We’re bringing you a double dose by sharing these episodes in video format and adding them to our blog, so you can consume the material in whichever form works better for you!

We’re now entering our third season! In the previous seasons, we focused on a general introduction to all things Git and then spent an entire season talking about Copilot. This season, we’re going back to the basics and exploring the core features of GitHub. Our goal is to help you level up—or dust off—your GitHub skills.

In this episode, we’re going to start with two of GitHub’s most powerful collaboration tools: GitHub Issues and Projects. By the end of this post, you’ll know how to create an issue, how to sync your issues to a GitHub Project board, and how to use GitHub Projects to track your work.

Let’s get into it! Or, watch the full video above!

Why issues and projects matter

GitHub Issues and Projects are essential tools for any team that wants to stay organized and collaborate efficiently. Issues help you track tasks, bugs, and ideas, all in a clear shared space—ensuring nothing slips through the cracks. Projects look at the bigger picture, letting you visualize, prioritize, and plan your work, turning individual issues into an actionable workflow that everyone can follow.

By combing issues and projects, you can coordinate work, communicate progress, and ensure that everyone’s aligned toward the same goal.

Creating your first GitHub Issue

GitHub Issues are a simple way to capture anything that needs attention in your project, whether that’s a new idea, a bug, or a task. Think of them as the building blocks of what you want to add to or update in your project. They help teams work collaboratively and stay organized, while making sure that every item is addressed.

So how do you create an issue? Here’s a sample repository where you can try this out for yourself by following these steps.

1. Navigate to gh.io/gfb-issues in your browser. 
2. At the top of the page, click the Issues tab. 
3. In the top-right of the window, click the green New issue button. 
4. A window will appear with a couple of boxes. First, give your issue a clear title by entering it in the box under “Add a title.” 
5. Provide a description for your issue in the “Add a description” box. Your description should include all of the relevant information necessary to set expectations. When someone attempts to resolve this issue, what is the behavior they should add or fix? 
6. On the right-hand side of the window, you have several options that you can configure.  
   • Assignee: Assign someone to work on this issue directly. You can even assign yourself to show what you’re working on. 
   • Labels: Classify your issue into one of several predesigned categories or potentially add a new one. 
   • Type: Indicate whether your issue is about something like a bug or a task. 
   • Projects: Add your issue to projects, which we’ll be covering later in this post. 
   • Milestone: Assign your issue to a specific milestone. 
7. Click the green Create button below the issue description. 

Congratulations! You have just created your first issue! Once an issue is created, anyone on the team can jump in and comment. All they need to do is enter some text in the comment field and then click the Comment button. You can even link issues together by typing # and then the number of the issue in the comment field. GitHub will automatically provide a clickable link to the numbered issue. This is super handy for tracking related work.

And when the work is finished, you can close the issue, letting the entire team know that it’s been addressed.

Creating your first GitHub Project

Projects give you a way to group GitHub Issues together in a visual dashboard that’s perfect for planning, organizing, and tracking work. It’s a tool for breaking big goals down into manageable tasks that you can track all in one place.

Now let’s walk through creating a project board. Here’s a sample repository where you can try this out, or you can do it in your own repository. If you still have the repository open from the walkthrough above, you can skip the first step.

1. Navigate to gh.io/gfb-issues in your browser.
2. At the top of the page, click the Projects tab.
3. In the top-right of the window, click the green New project button.
4. A window will pop up providing several templates for you to start from. Select the Kanban template.
5. Enter a title in the “Project name” field.
6. Unselect the checkbox for Bulk import items.
7. At the bottom of the window, select Create project.

GitHub will now create the project for you and take you to the project view. You’ll see the name of your project at the top of the window. In addition, GitHub automatically created columns for you, but you can customize them however you want.

Notice that underneath your project’s name, there are several tabs. These correspond to different views of the project board. Feel free to click on them to see what the different views look like in your project.

To manage your project board, click the three dots in the top-right corner and select Settings. This opens a new page where you can:

• Manage who has access to your project board.
• Create custom fields.
• Update any current fields.
• Change your project name.
• Provide or change the project description.
• Include a README.
• Create a copy of your project board.
• Change the visibility of your project.

To customize charts

At the top of the window, select the Insights button. On the following page, you’ll be able to view, create, and customize charts. You can change the layout of any of your charts by clicking the Configure button and choosing options from the dropdown menus.

To check the status of workflows

Going back to the main window, you can see a Workflows button next to the Insights button on the top. Select the Workflows button. Now you can see several built-in workflows on the left side of the window that you can use to update the status of items based on certain events. For example, you can automatically set the status to todo when an item is added to your project, close issues when the issue’s status in your project is changed or set the status to Done when an issue is closed.

To add a status update

Going back to the main project view once again, select the Add status update button at the very top. This opens a window where you can add a status report of your project’s health and progress.

Connecting issues and projects

Combining issues and projects together is how you’re able to get a complete view of your work. Think of issues as individual tasks, and projects as the dashboard that organizes those tasks. When you link issues to a project board, you can visualize where everything stands at a glance.

Go ahead and open your project board if it isn’t open already. At the bottom of the window, select Add item. You can either create a new issue right here, or you could search for existing ones. Click the plus icon and select Add item from repository. Select the issue or issues that you want to add to this project board. You can use the checkbox at the top of the list to automatically select all items at once if you want to add them all.

Once you’ve selected the issues you want to add, press the Add elected items button at the bottom of the window. Notice how this adds all of the selected issues to your project board as cards. You can select the cards and move them between status columns as work progresses. You can also click on the issue to see the full details of the issue.

And here’s something cool. The issue and your project board are now synchronized. When you change the status of the issue in one, it will automatically be reflected in the other. You can move multiple issues at once, organizing them into columns that match your workflow, and get that satisfying feeling when you finally move them into the “Done” column.

End-to-end flow

Let’s now simulate a real workflow that you might use in your team project by going through the following steps.

1. Navigate to your project board if you are not already there.
2. Click Add item at the bottom of your first column, indicating that you are adding a new issue to your workflow.
3. Click the plus icon and select Create new issue from the context menu.
4. Enter a title and description for the issue, describing a new feature you want to add.
5. Select Create to create the issue and automatically add it to the project board.
6. Underneath the description, select Labels and select enhancement from the list of options.
7. Click the issue in the project board to open it.
8. In the right-hand column, click the gear next to “Assignees” to assign this issue to someone on your team.
9. Add comments to the issue to signify making progress or providing updates.
10. Now let’s say that some work was done to address this issue. Open a pull request, and in the comment field, mention that it closes the relevant issue. Do this by entering Closes # and then the number connected with the issue in the pull request description. This will automatically connect to the issue and provide a link to it for ease of reference.
11. Merge the pull request, and it will automatically close the issue.

This workflow keeps everyone aligned without the need for constant status meetings. Everything you need to know is there, both in the issue and on the project board!

What’s next?

Now you know how to use GitHub Issues and Projects to organize your work with GitHub. Start simple with a few issues, build out your project board as you go, and you’ll have a system that scales with your team.

If you want to learn even more about GitHub Issues and GitHub Projects, make sure to check out our documentation.

Happy coding!

The post GitHub for Beginners: Getting started with GitHub Issues and Projects appeared first on The GitHub Blog.

Most developers already do real work in the terminal.

We initialize projects there, run tests there, debug CI failures there, and make fast, mechanical changes there before anything is ready for review. GitHub Copilot CLI fits into that reality by helping you move from intent to reviewable diffs directly in your terminal—and then carry that work into your editor or pull request.

This blog walks through a practical workflow for using Copilot CLI to create and evolve an application, based on a new GitHub Skills exercise. The Skills exercise provides a guided, hands-on walkthrough; this post focuses on why each step works and when to use it in real projects.

What Copilot CLI is (and is not)

Copilot CLI is a GitHub-aware coding agent in your terminal. You can describe what you want in natural language, use /plan to outline the work before touching code, and then review concrete commands or diffs before anything runs. Copilot may reason internally, but it only executes commands or applies changes after you explicitly approve them. 

In practice, Copilot CLI helps you:

• Explore a problem based on your intent
• Propose structured plans using /plan (or you can hit Shift + Tab to enter planning mode), or suggest concrete commands and diffs you can review
• Generate or modify files
• Explain failures where they occur

What it does not do:

• Silently run commands or apply changes without your approval
• Replace careful design work
• Eliminate the need for review

You stay in control of what runs, what changes, and what ships.

Step 1: Start with intent, not scaffolding

Instead of starting by choosing a framework or copying a template, start by stating what you want to build.

From an empty directory, run:

copilot
> Create a small web service with a single JSON endpoint and basic tests

If you want to generate a proposal in a single prompt instead of entering interactive mode, you can also run:

copilot -p "Create a small web service with a single JSON endpoint and basic tests"

In the Skills exercise, this pattern is used repeatedly: describe intent first, then decide which suggested commands you actually want to run.

At this stage, Copilot CLI is exploring the problem space. It may:

• Suggest a stack
• Outline files
• Propose setup commands

Nothing runs automatically. You inspect everything before deciding what to execute. This makes the CLI a good place to experiment before committing to a design.

Step 2: Scaffold only what you’re ready to own

Once you see a direction you’re comfortable with, ask Copilot CLI to help scaffold:

> Scaffold this as a minimal Node.js project with a test runner and README

This is where Copilot CLI is most immediately useful. It can:

• Create directories and config,
• Wire basic project structure,
• Generate boilerplate you would otherwise type or copy by hand.

Copilot CLI does not “own” the project structure. It suggests scaffolding based on common conventions, which you should treat as a starting point, not a prescription.

The important constraint is that you’re always responsible for the result. Treat the output like code from a teammate: review it, edit it, or discard it.

Step 3: Iterate at the point of failure

Run your tests directly inside Copilot CLI:

Run all my tests and make sure they pass

When something fails, ask Copilot about that exact failure in the same session:

> Why are these tests failing?

If you want a concrete proposal instead of an explanation, try:

> Fix this test failure and show the diff

This pattern—run (!command), inspect, ask, review diff—keeps the agent grounded in real output instead of abstract prompts.

💡Pro tip: In practice, explain is useful when you want understanding, while suggest is better when you want a concrete proposal you can review. Learn more about slash commands in Copilot CLI in our guide. 

Step 4: Make mechanical or repo-wide changes

Copilot CLI is also well suited to changes that are easy to describe but tedious to execute:

> Rename all instances of X to Y across the repository and update tests

Because these changes are mechanical and scoped, they’re easy to review and easy to roll back. The CLI gives you a concrete diff instead of a wall of generated text.

Step 5: Move into your editor when you need to start shaping your code

Eventually, speed matters less than precision.

This is the natural handoff point to your editor or IDE, so it can:

• Reason about edge cases
• Refine APIs
• Make design decisions

Copilot works there too, but the key point is why you switch environments. The CLI helps you quickly get to something real. The IDE is where you can shape your code into exactly what you want. 

A good rule of thumb: 

• CLI: use /plan, generate a /diff, and move quickly with low ceremony
• IDE: use /IDE when you need to refine logic and make decisions you’ll defend in review
• GitHub: commit, open a pull request with the command /delegate, and collaborate asynchronously

Step 6: Ship on GitHub

Once the changes look good, commit and open a pull request which you can do through the Copilot CLI in natural language:

Add and commit all files with a applicable descriptive messages, push the changes.

Create a pull request and add Copilot as a reviewer

Now the work becomes durable:

• Reviewable by teammates
• Testable in CI
• Ready for async iteration

This is where Copilot’s value compounds as part of a flow that ends with shipping versus just being a single surface. The Skills exercise intentionally ends here, because this is where Copilot’s value becomes durable: in commits, pull requests, and review (not just suggestions).

One workflow, three moments

A helpful mental model for Copilot looks like this:

• CLI: prove value quickly with low ceremony
• IDE: shape and refine your code
• GitHub: review, collaborate, and ship

Copilot CLI is powerful precisely because it fits into this system instead of trying to replace it.

Take this with you

Copilot CLI is most useful when you treat it like a tool for momentum, not a replacement for judgment.

Used well, it helps you move from intent to concrete changes faster: exploring ideas, scaffolding projects, diagnosing failures, and handling mechanical work directly in the terminal. When precision matters, you move into your editor. When the work is ready to share, it lands on GitHub as a pull request—reviewable, testable, and shippable.

That flow matters more than any single command.

If you take one thing away from this guide, it’s this: Copilot works best when it fits naturally into how developers already build software. Start in the CLI to get unstuck or move quickly, slow down in the IDE to make decisions you can stand behind, and rely on GitHub to make the work durable.

The post From idea to pull request: A practical guide to building with GitHub Copilot CLI appeared first on The GitHub Blog.

You open an issue before lunch. By the time you’re back, there’s a pull request waiting.

That’s what GitHub Copilot coding agent is built for. It works in the background, fixing bugs, adding tests, cleaning up debt, and comes back with a pull request when it’s done. While you’re writing code in your editor with Copilot in real time, the coding agent is handling the work you’ve delegated.

A few recent updates make that handoff more useful. Here’s what shipped and how to start using it.

Visual learner? Watch the video above! ☝️

Choose the right model for each task

The Agents panel now includes a model picker.

Before, every background task ran on a single default model. You couldn’t pay for a more robust model to complete harder work or prioritize speed on routine tasks.

Now you can. Use a faster model for straightforward work like adding unit tests. Upgrade your model for a gnarly refactor or integration tests with real edge cases. If you’d rather not think about it, leave it on auto.

To get started:

• Open the Agents panel (top-right in GitHub), select your repo, and pick a model.
• Write a clear prompt and kick off the task.
• Leave the model on auto if you’d rather let GitHub choose.

Model selection is available for Copilot Pro and Pro+ users now, with support for Business and Enterprise coming soon.

Learn more about model selection with Copilot coding agent. 👉

Pull requests that arrive in better shape

The painful part of reviewing agent output has always been the cleanup. You open the diff and there it is: logic that technically works, but nobody would write it that way.

Copilot coding agent now reviews its own changes using Copilot code review before it opens the pull request. It gets feedback, iterates, and improves the patch. By the time you’re tagged for review, someone already went through it.

In one session, the agent caught that its own string concatenation was overly complex and fixed it before the pull request landed. That kind of thing used to be your problem.

To get started:

• Assign an issue to Copilot or create a task from the Agents panel.
• Click into the task to view the logs.
• See the moments where the agent ran Copilot code review and applied feedback.

Review the pull request when prompted. Copilot requests your review only after it has iterated.

Learn more about Copilot code review + Copilot coding agent. 👉

Security checks that run while the agent works

Just like with human-generated code, AI-generated code can introduce real risks: vulnerable patterns, secrets accidentally committed, dependencies with known CVEs. The difference is it does it faster. And you really don’t want to find that in review.

Copilot coding agent now runs code scanning, secret scanning, and dependency vulnerability checks directly inside its workflow. If a dependency has a known issue, or something looks like a committed API key, it gets flagged before the pull request opens.

Code scanning is normally part of GitHub Advanced Security. With Copilot coding agent, you get it for free.

To get started:

• Run any task through the Agents panel.
• Check the session logs as it runs. You’ll see scanning entries as the agent works.
• Review the pull request. It’s already been through the security filter.

Learn more about security scanning in Copilot coding agent. 👉

Custom agents that follow your team’s process

A short prompt leaves a lot to judgment. And that judgment isn’t always consistent with how your team actually works.

Custom agents let you codify it. Create a file under .github/agents/ and define a specific approach. A performance optimizer agent, for example, can be wired to benchmark first, make the change, then measure the difference before opening a pull request.

In a recent GitHub Checkout demo, that’s exactly what happened. The agent benchmarked a lookup, made a targeted fix, and came back with a 99% improvement on that one function. Small scope, real data, no guessing.

You can share custom agents across your org or enterprise too, so the same process applies everywhere teams are using the coding agent.

To get started:

• Create an agent file under .github/agents/ in your repo.
• Open the Agents panel and start a new task.
• Select your custom agent from the options.
• Write a prompt scoped to what that agent does.

Learn more about creating custom agents. 👉

Move between cloud and local without losing context

Sometimes you start something in the cloud and want to finish it locally. Sometimes you’re deep in your terminal and want to hand something off without losing your flow. Either way, switching contexts used to mean starting the conversation over.

Now it doesn’t. Pull a cloud session into your terminal and you get the branch, the logs, and the full context. Or press & in the CLI to push work back to the cloud and keep going on your end.

To get started:

• Start a task with Copilot coding agent and wait for the session to appear.
• Click “Continue in Copilot CLI” and copy the command.
• Paste it in your terminal to load the session locally with branch, logs, and context intact.
• Press the ampersand symbol (&) in the CLI to delegate work back to the cloud and keep going locally.

Learn more about Copilot coding agent + CLI handoff. 👉

What this adds up to

Copilot coding agent has come a long way. Model selection, self-review, security scanning, custom agents, CLI handoff—and that’s just what shipped recently. The team is actively working on private mode, planning before coding, and using the agent for things that don’t even need a pull request, like summarizing issues or generating reports. There’s a lot more coming. Stay tuned.

Share feedback on what ships next in GitHub Community discussions.

The post What’s new with GitHub Copilot coding agent appeared first on The GitHub Blog.

Over the years (decades), open source has grown and changed along with software development, evolving as the open source community becomes more global.

But with any growth comes pain points. In order for open source to continue to thrive, it’s important for us to be aware of these challenges and determine how to overcome them.

To that end, let’s take a look at what Octoverse 2025 reveals about the direction open source is taking. Feel free to check out the full Octoverse report, and make your own predictions.

Growth that’s global in scope

In 2025, GitHub saw about 36 million new developers join our community. While that number alone is huge, it’s also important to see where in the world that growth comes from. India added 5.2 million developers, and there was significant growth across Brazil, Indonesia, Japan, and Germany. 

What does this mean? It’s clear that open source is becoming more global than it was before. It also means that oftentimes, the majority of developers live outside the regions where the projects they’re working on originated. This is a fundamental shift. While there have always been projects with global contributors, it’s now starting to become a reality for a greater number of projects.

Given this global scale, open source can’t rely on contributors sharing work hours, communication strategies, cultural expectations, or even language. The projects that are going to thrive are the ones that support the global community.

One of the best ways to do this is through explicit communication maintained in areas like contribution guidelines, codes of conduct, review expectations, and governance documentation. These are essential infrastructure for large projects that want to support this community. Projects that don’t include these guidelines will have trouble scaling as the number of contributors increases across the globe. Those that do provide them will be more resilient, sustainable, and will provide an easier path to onboard new contributors.

The double-edged sword of AI

AI has had a major role in accelerating global participation over 2025. It’s created a pathway that makes it easier for new developers to enter the coding world by dramatically lowering the barrier to entry. It helps contributors understand unfamiliar codebases, draft patches, and even create new projects from scratch. Ultimately, it has helped new developers make their first contributions sooner.

However, it has also created a lot of noise, or what is called “AI slop.” AI slop is a large quantity of low-quality—and oftentimes inaccurate—contributions that don’t add value to the project. Or they are contributions that would require so much work to incorporate, it would be faster to implement the solution yourself. 

This makes it harder than ever to maintain projects and make sure they continue moving forward in the intended direction. Auto-generated issues and pull requests increase volume without always increasing the quality of the project. As a result, maintainers need to spend more time reviewing contributions from developers with vastly variable levels of skill. In a lot of cases, the amount of time it takes to review the additional suggestions has risen faster than the number of maintainers.

Even if you remove AI slop from the equation, the sheer volume of contributions has grown, potentially to unmanageable levels. It can feel like a denial of service attack on human attention.

This is why maintainers have been asking: how do you sift through the noise and find the most important contributions? Luckily, we’ve added some tools to help. There are also a number of open source AI projects specifically trying to address the AI slop issue. In addition, maintainers have been using AI defensively, using it to triage issues, detect duplicate issues, and handle simple maintenance like the labeling of issues. By helping to offload some of the grunt work, it gives maintainers more time to focus on the issues that require human intervention and decision making.

Expect the open source projects that continue to expand and grow over the next year to be those that incorporate AI as part of the community infrastructure. In order to deal with this quantity of information, AI cannot be just a coding assistant. It needs to find ways to ease the pressure of being a maintainer and find a way to make that work more scalable.

Record growth is healthy, if it’s planned for

On the surface, record global growth looks like success. But this influx of newer developers can also be a burden. The sheer popularity of projects that cover basics, such as contributing your first pull request to GitHub, shows that a lot of these new developers are very much in their infancy in terms of comfort with open source. There’s uncertainty about how to move forward and how to interact with the community. Not to mention challenges with repetitive onboarding questions and duplicate issues.

This results in a growing gap between the number of participants in open source projects and the number of maintainers with a sense of ownership. As new developers grow at record rates, this gap will widen.

The way to address this is going to be less about having individuals serving as mentors—although that will still be important. It will be more about creating durable systems that show organizational maturity. What does this mean? While not an exhaustive list, here are some items:

• Having a clear, defined path to move from contributor to reviewer to maintainer. Be aware that this can be difficult without a mentor to help guide along this path.
• Shared governance models that don’t rely on a single timezone or small group of people.
• Documentation that provides guidance on how to contribute and the goals of the project.

By helping to make sure that the number of maintainers keeps relative pace with the number of contributors, projects will be able to take advantage of the record growth. This does create an additional burden on the current maintainers, but the goal is to invest in a solid foundation that will result in a more stable structure in the future. Projects that don’t do this will have trouble functioning at the increased global scale and might start to stall or see problems like increased technical debt.

But what are people building?

It can’t be denied that AI was a major focus—about 60% of the top growing projects were AI focused. However, there were several that had nothing to do with AI. These projects (e.g., Home Assistant, VS Code, Godot) continue to thrive because they meet real needs and support broad, international communities.

Just as the developer space is growing on a global scale, the same can be said about the projects that garner the most interest. These types of projects that support a global community and address their needs are going to continue to be popular and have the most support. 

This just continues to reinforce how open source is really embracing being a global phenomenon as opposed to a local one.

What this year will likely hold

Open source in 2026 won’t be defined by a single trend that emerged over 2025. Instead, it will be shaped by how the community responds to the pressures identified over the last year, particularly with the surge in AI and an explosively growing global community.

For developers, this means that it’s important to invest in processes as much as code. Open source is scaling in ways that would have been impossible to imagine a decade ago, and the important question going forward isn’t how much it will grow—it’s how can you make that growth sustainable.

The post What to expect for open source in 2026 appeared first on The GitHub Blog.