When people imagine developers leveraging public code, they often think of developers using code that’s already been written and building upon it to create something new. It’s faster to build from something than to build from nothing, right? While this is transactionally true, there’s more to it than that. Central to the open source culture is not only leveraging public code but being able to explore the repository in which it exists, learn about code origins, see who else has worked on the code, increase knowledge sharing among the community, and understand possible licensing structures.

With the advent and scale of new AI technology solutions like GitHub Copilot, the way developers work is changing, and with those changes it’s important to incorporate the habits and practices developers value in new ways of working. In this case, identifying myriad sources where code may appear required the creation of a new solution—one that enables developers to prioritize these values while fostering learning and knowledge sharing at scale.

GitHub engineering teams got to work to address this, and today we’re announcing the general availability of code referencing in GitHub Copilot Chat and GitHub Copilot code completions. Developers can now choose whether to block suggestions containing matching code or allow those suggestions with information about the matches. This feature is currently available in VS Code and will be more widely available soon.

How code referencing works

With billions of files to index and a latency budget of only 10-20ms, it’s a miracle of engineering that finding specific matches is even possible. Still, when a match is found (if public code matching is allowed), a notification appears in the editor showing: (1) the matching code, (2) the file where that code appears, and (3) licensing info (if any) detected in the relevant repository. This information is shown for all the public code matches that are detected in a model response.

We’re also excited to announce that GitHub has partnered with Microsoft Azure to make the code referencing API available on Azure AI Content Safety. Azure AI Content Safety users can leverage this feature via the protected material detection for code filter. We believe in transparency as a core value of the open source community and want to ensure that this capability is available to everyone, no matter which tool you use.

Whether you’re using GitHub Copilot or other generative AI tools leveraging the code referencing API, you can depend on transparency so that you can make informed development decisions for the project at hand.

Why code referencing matters

The power of code referencing for individual developers

For individual developers using GitHub Copilot, this adds a layer of transparency and keeps you in the driver’s seat. We’ve always had a filter that users can apply to prevent Copilot from producing suggestions matching public code. Now, with code referencing, you have the additional option to allow all suggestions while still utilizing Copilot because if Copilot produces suggestions of 150 characters or more that match public code, you’ll be notified about the matches found, the repositories the code was found in, and potential licenses detected. This information helps you make more informed decisions so that you can build, with Copilot, with confidence.

The power of code referencing for businesses

Copilot helps organizations innovate faster than ever. To help businesses innovate responsibly, the option to block suggestions matching public code has always been available to admins, and using that filter ensures customers are protected by GitHub’s indemnification commitment.

For dev teams wanting to benefit from the learning code referencing enables, GitHub’s indemnity will now extend to their use of code referencing where GitHub Copilot Business or GitHub Copilot Enterprise customers comply with cited licenses. This means that Copilot Business and Copilot Enterprise customers can expand their teams’ Copilot context, use, and effectiveness while keeping existing contractual protections.

We’ve collaborated to make code referencing a reality, not just for GitHub, but for all AI dev tools, and have been driven by the values that the open source community has long cultivated and upheld—that surfacing and sharing information can unlock innovation in new and groundbreaking ways. As we continue to grow and scale our capabilities with AI, GitHub is excited to empower developers with greater transparency, knowledge sharing, and tools for innovation.

The post Code referencing now generally available in GitHub Copilot and with Microsoft Azure AI appeared first on The GitHub Blog.

In the most recent period, you may notice a significant jump in projects affected by DMCA takedowns, with 1,041 notices processed and 18,472 projects taken down in H1 2024 versus 964 notices and 6,358 projects taken down in H2 2023. This jump can largely be attributed to a single takedown.

Moderating GitHub presents challenges specific to the code collaboration environment, but policymakers, researchers, and other stakeholders are often less familiar with how a platform like GitHub works. That’s one of the reasons our policy team regularly advocates on behalf of the interests of developers, code collaboration, and open source development. Open source software is a public good, underpinning all sectors of the economy and serving as essential digital infrastructure, and moderating the home for open source software requires careful consideration to ensure that essential code remains accessible. Meanwhile, our Trust and Safety team has continually evolved our developer-first approach to content moderation in response to technological and societal developments.

In the interest of broadening understanding of code collaboration, advancing the transparency of our own governance practices, and enriching platform studies research, we are proud to share the recently published article, “Nuances and Challenges of Moderating a Code Collaboration Platform” in the Journal of Online Trust and Safety and co-authored by members of our Trust and Safety, Legal, and Policy teams. The paper is available to all, and we encourage you to read it in its entirety. It covers how moderating a code collaboration platform presents unique considerations illustrated with diverse case studies. We also consider how the new frontiers of AI will present challenges and opportunities for maintaining our developer-first standards at scale.

The post The nuances and challenges of moderating a code collaboration platform appeared first on The GitHub Blog.

Today, GitHub Copilot Individual and Business plans now include preview access to Copilot functionality, including GitHub Copilot Chat, in github.com. The integration with GitHub allows Copilot to leverage the rich context from repositories, pull requests, issues, actions, and more, providing you with more valuable interactions, more tailored coding assistance, and an AI-native developer experience with GitHub.

Doing more with what you know

With this latest release, GitHub Copilot is now ubiquitous across the IDE, Visual Studio Code, browser, and mobile for all Copilot users and is there to assist you across the software development lifecycle. Whether you’re on the browser or mobile, you can now use Copilot not only as an AI pair programmer that makes code suggestions, but also as a coding assistant powered by entire codebases, conversations between collaborators, and workflows.

Now, you can ask Copilot to help:

• Explore GitHub through powerful natural language search. Trying to understand a new codebase? Copilot can help with that. You can ask Copilot questions to help quickly understand the structure and key components of repositories. Check out how.

• Understand code faster. Struggling to understand what a piece of code does? Ask Copilot to explain it to you—it’s like having a knowledgeable teammate who’s always available to help without having to clone the repository locally.

• Quickly gain context. Draft summaries for pull requests or outline key takeaways from discussions threads with the help of Copilot, making it easier for you and your team to get up to speed and stay aligned.

• Analyze failing GitHub Actions jobs to identify issues (public preview). We all know the pain of broken Actions jobs. Copilot can help you analyze failing builds and make suggestions so you can get back on track.

• Get insights on the go. When you’re out and about, you can chat with Copilot in GitHub Mobile about your private repositories to quickly catch up on updates to code, issues, pull requests, and more.

Dig deeper with OpenAI o1

For questions that require more time and intensive analysis by GitHub Copilot to construct a response, switch into immersive mode, or go directly to github.com/copilot. You can even try using an OpenAI o1 model to power your conversation. We know that one model doesn’t fit each and every task, so while the base model for GitHub Copilot Chat, GPT-4o, may provide satisfactory explanations on pull request diffs and generate great boilerplate code, o1-preview or o1-mini may suit complex tasks like crafting advanced algorithms or helping to fix performance bugs much better. Join the waitlist for early access to OpenAI o1 for Copilot Chat in immersive mode.

Get started today

By integrating GitHub Copilot into GitHub, we’re taking another step of putting AI right where you need it—whether you’re coding in an editor or troubleshooting and collaborating with your team in github.com. And with a growing ecosystem of GitHub Copilot Extensions, you can even integrate your favorite third-party and critical internal developer tools with Copilot to keep you in your flow state. This update is designed to streamline your development process, empower you with your organization’s context, and allow you to focus on what you do best—creating great software.

As with all GitHub betas, these features are governed by our pre-release terms. We’re eager to see how you all leverage these new capabilities, and, as always, you can provide feedback in the GitHub Community.

Note: videos have been sped up for display purposes.

The post GitHub Copilot now available in github.com for Copilot Individual and Copilot Business plans appeared first on The GitHub Blog.

Cybersecurity Awareness Month is a global initiative that highlights the importance of protecting our digital work. At GitHub, security is the core of how we operate. We’re proud to participate and demonstrate our commitment to safeguarding our customer’s data. As such, GitHub’s Bug Bounty team is excited to celebrate the Cybersecurity Awareness Month this year with some additional incentives for security researchers! This includes:

• Bonuses for new and existing researchers.
• Bonus for providing Nuclei template for reproductions and fix verifications.
• Spotlight on a few of the talented security researchers who participate in the GitHub Security Bug Bounty Program.

Bonuses for new and existing researchers

For the month of October:

• A new hacker to our program will receive an additional 20% bonus on their highest severity valid submission.
• For returning hackers, we are offering an additional 10% bonus on their highest severity valid submission.

Note: these bonuses will only apply to (1) submission per researcher.

Bonus for providing Nuclei templates

A valid report that also contains a functional Nuclei template that we can use to both reproduce the report and verify that it is fixed will receive an additional 5% bonus. To learn more about Nuclei, please visit this documentation.

Researcher’s spotlight

Every year, we like to spotlight researchers who are participating in our program and learn more about them. In these interviews, we learn about their hunting methodology, interests, and more.

To read more about our previous spotlights, please check out:

1. Cybersecurity spotlight on bug bounty researchers @chen-robert and @ginkoid
2. Cybersecurity spotlight on bug bounty researcher @yvvdwf
3. Cybersecurity spotlight on bug bounty researcher @ahacker1
4. Cybersecurity spotlight on bug bounty researcher @inspector-ambitious
5. Cybersecurity spotlight on bug bounty researcher @Ammar Askar

Stay tuned for more researcher spotlights this coming month!

Each submission to our bug bounty program is a chance to make GitHub, our products, the developer community, and our customers more secure, and we’re thrilled with the ongoing collaboration to make GitHub better for everyone with the help of your skills. If you are interested in participating, visit our website for details of the program’s scope, rules, and rewards.

The post Kicking off Cybersecurity Awareness Month: Researcher spotlights and additional incentives! appeared first on The GitHub Blog.

Working with the command line is something many developers love. Even though we love it, there are times when it can be really frustrating. What’s the command for switching to a branch? How do I fix merge conflicts? Do I have the correct credentials or permissions for my file or directory?

In our recent blogs, we showed you some of the top Git commands and useful commands for the GitHub CLI. However, there are hundreds, if not thousands, of terminal-based commands, and knowing them all would be difficult. We could search for the correct command in a browser but at the cost of breaking our flow and maybe still not finding exactly what we need.

In the previous blog, we showed you how to use --help to receive some helpful suggestions about which commands to use, but this is usually a basic list. Instead, wouldn’t it be great if we could have a conversation with our terminal and ask which commands to use? This is where GitHub Copilot in the CLI comes into play.

GitHub Copilot in the CLI

Many developers are loving GitHub Copilot Chat, and the time-saving benefits and productivity gains that come with it. So, we thought, “Why not bring GitHub Copilot to the command line?” With GitHub Copilot in the CLI, we can ask questions to help us with our terminal tasks, whether they are Git-related commands, GitHub, or even generic terminal commands.

If this sounds like something you want to try, then read on. We’ve also left you with some challenges for you to try yourself.

Getting started

To get started, you’ll need to make sure you have the GitHub CLI installed on your Windows, Mac, or Linux machine, and an active subscription of GitHub Copilot. If your Copilot subscription is part of a Business or Enterprise license, you’ll need to ensure your organization or enterprise’s policy allows you to use “Copilot in the CLI:”

You can find these Copilot settings by clicking your profile icon in the top right-hand corner on github.com → Settings → Copilot.

Ensure you’re authenticated in your terminal with GitHub by using gh auth login. You can follow the guide in our CLI Docs to ensure you authenticate correctly.

Copilot in the CLI is a GitHub CLI extension. Thus, you have to install it by typing gh extension install github/gh-copilot into your terminal of choice. Since I’m using Windows, all the examples you see here will be Windows PowerShell:

Now that you have Copilot in your CLI, you can use gh copilot to help you find information you are looking for. Let’s look at some of the most common things you can do with Copilot.

Have GitHub Copilot explain computer science concepts

GitHub Copilot is your friend when it comes to using the terminal, regardless of how familiar you are. Copilot can help explain something by using gh copilot explain, followed by a natural language statement of what you want to know more about. As an example, you might like to know how to roll back a commit:

You can receive help from Copilot when you don’t understand exactly what a particular command does. For example, a teammate recently passed me the script npx sirv-cli . to run in my terminal as part of a project we were working on. If I want to better understand what this command does, I can ask Copilot:

TRY IT: Ask Copilot to explain the difference between Git and GitHub.

If you get stuck, you can type gh copilot --help to see a list of commands and examples for how to use Copilot in the CLI:

GitHub Copilot can suggest commands

Explaining concepts is good for understanding and knowledge. When we want to execute a command, however, the explain command might not be enough. Instead, we can use the suggest command to have GitHub Copilot suggest an appropriate command to execute. When it comes to suggesting commands based on your questions, Copilot will follow up with another question, such as “What kind of command can I help you with?” with three options for you to choose from:

The user can choose between:

• generic shell command (terminal command)
• gh command (GitHub CLI command)
• git command

Copilot can then provide a suggestion based on the type of command you want to use. Let’s dive into each of the three command types.

Generic shell commands

There are hundreds of terminal specific commands we can execute. When asking GitHub Copilot for a suggested answer, we’ll need to select generic shell command from the drop down. As an example, let’s ask Copilot how to kill a process if we’re listening on a specific port:

Along the way, we are answering the questions Copilot is providing to us to help refine the prompt. At the end of each suggestion, we are able to have Copilot explain further, execute the command, copy the command, revise the command, or exit the current question.

TRY IT: Ask Copilot how to list only *.jpg files from all subfolders of a directory.

Git commands

In our recent blog, we went through some of the main Git commands every developer should know. Instead of having to search for a specific command, you can ask GitHub Copilot for help directly from the command line.

For Git commands, select git command from the Copilot drop down. If we wanted to know which branch we were on before making a commit, we could ask Copilot to suggest the best way to achieve this:

In this example, you can see I first ask to have the answer explained, and then execute the command to see that we are currently working on the main branch.

What if we accidentally checked our new changes onto the main branch, but we actually want them on a new branch? We can ask Copilot how would we go about fixing this:

Remember to also check the responses Copilot is giving you. In the above example, Copilot gave me a very long answer to my question, and my question was also rather long. We didn’t get exactly what I needed. Instead, I select to revise the question further. Still, we didn’t get exactly what we wanted. Let’s revise it again, and ask to add the changes to a new branch instead:

Now, I have three steps to execute in order to create a new branch, reset the previous branch, and then switch to the new branch. From there, I can make a new commit.

Once we’ve made a commit, we can ask how to update the previous commit message:

Now, we can change the previous commit message.

TRY IT: Ask Copilot how to merge a pull request as an admin.

GitHub commands

In our last blog, we showed you useful GitHub commands for using the GitHub CLI. Now, let’s ask GitHub Copilot when we get stuck. When we want to ask Copilot about GitHub- specific commands, choose the gh command from the drop down menu in the terminal.

Let’s look at diffs—the difference between two files or two commits on GitHub. We can ask Copilot how to view these differences. Here, I’m also asking Copilot in the terminal via VS Code, and it’s also providing me with suggestions for the question:

Here, I didn’t specify in the prompt whether it was a GitHub command. By choosing gh command, Copilot knows I am looking for a GitHub-specific command, and therefore shows me the command for showing a difference of the pull request number we selected.

Now, let’s see if there are any pull requests or issues from this repository that are assigned to me:

Copilot tells me there are none assigned to me from this repository—winning!

Let’s put a few Git and GitHub commands together. Let’s ask how to open a pull request from a branch using a gh command. Firstly, let’s ask Copilot to commit all my changes to a new branch, and then ensure I’m on the correct branch. After switching to the correct brand, we can ask Copilot how to open a pull request from a branch we are on:

Remember (again) to check the responses we are given. In this example, Copilot gave us the command gh pr create --base --head --title “” --body <"pull_request_body>" which provides all the tags. If we just use gh pr create then we are guided through the pull request process. We can follow the prompts within the command line and ask Copilot along the way for help if we get stuck. I created a draft pull request so I can work on it with my team further before converting it to an open pull request.

By answering the questions Copilot gives us, such as “What kind of command” is this, and selecting the correct option, we can have Copilot successfully execute a command. In this case, we have committed our code to a new branch, navigated to the correct branch, and opened the pull request as a draft.

TRY IT: Ask Copilot how to create a new release and edit the contents.

Working with aliases

All this typing gh copilot suggest has got me thinking “there’s got to be a faster way to use GitHub Copilot”, and there is. We can use the prebuilt ghcs alias to have “Copilot suggest” a command for us. We’ll need to configure GitHub Copilot in the CLI before we can use these commands. There are also flags like --target (or -t for short), which allow us to specify a target for the suggestion, such as shell, gh, or git. In this way, we can make our conversation with Copilot so much faster. To learn more about the commands and flags available, you can use --help with any Copilot command or either of the ghce and ghcs aliases.

Each system configures these aliases differently. Check out the Copilot Docs and video for how to configure aliases for you.

TRY IT: Configure Copilot in the CLI with aliases for even fewer keystrokes.

Using GitHub Copilot CLI

When it comes to using GitHub Copilot in the CLI, the question you ask–also called the prompt–is really important for receiving an answer that is correct for your situation. Unlike GitHub Copilot in your editor, Copilot CLI doesn’t have as much context to draw from. You’ll need to ensure the prompt you write is succinct, and captures the question you are wanting to ask. If you want some tips on writing good questions, check out our guide on prompt engineering. You can always revise your question to get the answer you are looking for.

This has been a brief introduction on using Copilot from the command line. Now, you’re ready to give our “try it” examples a go. When you try these out, share your results in this discussion so we can see the answers Copilot gives you and discuss them together.

The post Boost your CLI skills with GitHub Copilot appeared first on The GitHub Blog.

Today, we announced that GitHub Enterprise Cloud will offer data residency, starting with the European Union (EU) on October 29, 2024, to address a critical desire from customers and enable an optimal, unified experience on GitHub for our customers.

Data residency and what it means for developers

We’ve heard for years from enterprises that being able to control where their data resides is critical for them. With data residency, organizations can now store their GitHub code and repository data in their preferred geographical region. With this need met, even more developers across the globe can build on the world’s AI-powered developer platform.

Enterprise Cloud with data residency provides enhanced user control and unique namespaces on ghe.com isolated from the open source cloud on github.com. It’s built on the security, business continuity, and disaster recovery capabilities of Microsoft Azure.

This is a huge milestone for our customers and for GitHub–a multi-year effort that required extensive time, effort, and dedication across the company. We’re excited to share a behind-the-scenes look at how we leveraged GitHub to develop the next evolution of Enterprise Cloud.

Designing the architecture for the next evolution of GitHub Enterprise

This effort started in summer of 2022 with a proof of concept (PoC) and involved teams across GitHub. We carefully considered which architecture would enable us to be successful. After iterating with different approaches, we decided to build the new offering as a feature set that extends Enterprise Cloud. This approach would allow us to be consistently in sync with features on github.com and provide the performance, reliability, and security that our customers expect. For hosting, we effectively leveraged Microsoft Azure’s scale, security, and regional footprint to produce a reliable and secured product with data residency built-in, without having to build new data centers ourselves.

As the home for all developers, developer experience is critically important for us. We recognized early on that consistency was important, so we sought to minimize differences in developing for Enterprise Cloud and Enterprise Cloud with data residency. To this end, the architecture across both is very similar, reducing complexity, risk, and development costs. The deployment model is familiar to our developers: it builds off of GitHub Actions. Also, changes to github.com and Enterprise Cloud with data residency are deployed minutes apart as part of a unified pipeline.

To accomplish this, we had to organize the work, modify our build and deployment systems, and validate the quality of the platform. We were able to do all three of these by using GitHub.

Organizing with GitHub Issues and Projects

To organize the project, we used GitHub Issues and Projects, taking advantage of multiple views to effectively drive work across multiple projects, more than 100 teams, and over 2,000 issues. Different stakeholders and teams could take advantage of these views to focus on the information most relevant to them. Our talented technical project management team helped coordinate updates and used the filtering and slicing capabilities of Projects to present continuously updated information for each milestone in an easily consumable way.

We also used upcoming features like issues hierarchy to help us understand relationships between issues, and issue types to help clearly classify issues across repositories. As part of using these features internally we were able to give feedback to the teams working on them and refine the final product. Keep an eye out for future announcements for issues hierarchy and issue types coming soon!

All of these powerful features helped us keep the initiative on track. We were able to clearly understand potential risk areas and partner across multiple teams to resolve blockers and complex dependencies, keeping the project effectively moving forward across multiple years.

Building Enterprise Cloud with data residency using GitHub

GitHub has always been built using GitHub. We wanted to continue this practice to set ourselves up for success with the new data residency feature. To this end, we continued leveraging GitHub Codespaces for development and GitHub Actions for continuous integration (CI). In addition, we added deployment targets for new regions. This produced a development, testing, and CI model that required no changes for our developers and a deployment process that was tightly integrated into the existing flow.

We have previously discussed our deploy then merge model, where we deploy branches before merging into the main branch. We expanded this approach to include successful deployments to Enterprise Cloud data residency targets before changes could be merged and considered complete, continuing to use the existing GitHub merge queue. A visualization of our monolithic deployment pipeline is shown in the figure below.

We start by deploying to environments used by GitHub employees in parallel. This includes the internal environment for Enterprise Cloud with data residency discussed more in the next section. As we use GitHub every day to build GitHub, this step helps us catch issues as employees use the product before it impacts our customers. After automated and manual testing, we proceed to roll out to “Canary.” Canary is the name for the stage where we configure our load balancers to gradually direct an increasing percentage of github.com traffic to the updated version of the code in a staged manner. Additional testing occurs in between each stage. Once we successfully deploy the updated version of github.com to all users, we then deploy and validate Enterprise Cloud with data residency in the EU before finishing the process and merging the pull request.

Ensuring all deployments are successful before we merge means changes are deployed in sync across all Enterprise Cloud environments and monitored effectively. Note that in addition to deployments, we also use feature flags to gradually roll out changes to groups of customers to reduce risk. If a deployment to any target fails, we roll back the change completely. Once we have understood the failure and are ready to deploy again, the entire process starts from the beginning with the merge queue.

Finally, to maintain consistency across all teams and services, we created automation to generate deployment pipelines for over 100 services so, as new targets are introduced, each service automatically deploys to the new environment in a consistent order.

Using Enterprise Cloud with data residency ourselves

To create the best possible product, we also prioritized using it ourselves and stood up an isolated environment for this purpose. Using our GitHub migration tooling, we moved the day-to-day development for the team working on GitHub Enterprise Importer to that environment, and invested in updating our build, deploy, and development environments to support working from the data resident environment. Since its creation, we have deployed to this environment over 8,000 times. This gave us invaluable feedback about the experience of working in the product with issues, pull requests, and actions that we were able to address early in the development process. We were also able to iterate on our status page tooling and internal Service Level Objective (SLO) process with the new environment in mind. The team is continuing to work in this environment today and runs over 1,000 actions jobs a month. This is a testament to the stability and quality we’ve been able to deliver and our commitment to this feature.

What’s next

We are proud that we’ve been able to evolve Enterprise Cloud to offer data residency while using GitHub to organize, build, deploy, and test it. We’re excited to unlock GitHub for even more developers and for you to experience what we have built, starting on October 29, 2024 in the EU, with more regions on the way.

The post GitHub Enterprise Cloud with data residency: How we built the next evolution of GitHub Enterprise using GitHub appeared first on The GitHub Blog.

OpenAI o1 is a new series of AI models equipped with advanced reasoning capabilities, trained to think through complex tasks using an internal thought process. During our exploration of using o1-preview with GitHub Copilot, we found the model’s reasoning capability allows for a deeper understanding of code constraints and edge cases produced a more efficient and higher quality result. And o1-preview’s deliberate and purposeful responses made it easy to pinpoint problems and quickly implement solutions.

Now, you can test it out and start building on GitHub with o1-preview and o1-mini. During the preview, you can choose to use o1-preview or o1-mini to power Copilot Chat in VS Code in place of the current default model, GPT-4o. Toggle between models during a conversation, moving from quickly explaining APIs or generating boilerplate code to designing complex algorithms or analyzing logic bugs. Using o1-preview or o1-mini with Copilot gives you a first-hand look at the new models’ ability to tackle complex coding challenges.

You can also test either of the o1 models in the playground in GitHub Models to discover their unique capabilities and performance. And once you’re familiar with how the models work, take the next step and start to integrate the models into your own apps.

With this preview, we’re excited to bring OpenAI’s latest advancements to you, whether you’re developing software along with Copilot or building the next great LLM-based product. We can’t wait to see what you build!

The post Try out OpenAI o1 in GitHub Copilot and Models appeared first on The GitHub Blog.

This July, the world experienced the hottest day in recorded history according to NASA. The graph below, from a GitHub repository of open access climate visuals, shows the longer version of this story, where carbon dioxide and other greenhouse gasses have increased since the beginning of the industrial revolution. The effects of which we’re starting to see more and more—from severe weather events to hitting all-time highs—like the hottest day in history. These serve as reminders to all of us for the need to take action, particularly for those of us working in tech. As the energy use of our industry grows, we believe that we have a responsibility to help support sustainable practices so that we can reduce the environmental impact of the software we build.

So, how do we accelerate climate progress without inhibiting innovation? Well, that’s the conversation we want to open up within our developer community. And to start, we went directly to those who are already making progress to develop green software tools within the open source ecosystem. After reviewing repositories on GitHub that self-identified as being a green software tool as their primary purpose, we compiled these into a directory of resources built by our community, for our community. We ended up with GitHub’s Green Software Directory that includes a comprehensive list of the green software tools out there. Below, we picked some of the most-loved repositories within the community—those with 250+ stars—to help you code sustainably, whether you’re just starting out or you’re a seasoned professional.

TL;DR: What is green software?

Green software is software that emits the least carbon possible. There are three ways to reduce the carbon emissions of software: through energy efficiency, carbon awareness, and hardware efficiency. Energy efficiency means your software is consuming the least amount of electricity possible. Hardware efficiency is using the least amount of embodied carbon as possible. And carbon awareness means adjusting your workflow so that you’re doing more when you’re using clean electricity, and doing less when it’s dirty.

Our top 10 tools

1. Scaphandre

⭐: 1,500+

Scaphandre [skafɑ̃dʁ] is a metrology agent dedicated to electric power and energy consumption metrics. Use it to measure the power consumption of your tech services and get this data in a convenient form, sending it through any monitoring or data analysis toolchain.

2. Kepler

⭐: 1,100+

Kepler (Kubernetes-based Efficient Power Level Exporter) uses eBPF to probe performance counters and other system stats, uses ML models to estimate workload energy consumption based on these stats, and then exports them as Prometheus metrics. Use it to learn about energy consumption of Kubernetes components such as Pods and Nodes.

3. Code Carbon

⭐: 1,100+

A Python package that estimates your hardware electricity power consumption (GPU + CPU + RAM) and then applies to it the carbon intensity of the region where the computing is done.

Bonus: check out mlco2’s other repository, Impact, to calculate machine learning emissions.

4. Kube Green

⭐: 972+

A simple k8s add-on that automatically shuts down some of your resources when you don’t need them.

5. Cloud Carbon Footprint

⭐: 882+

A tool to estimate energy use (kilowatt-hours) and carbon emissions (metric tons CO2e) from public cloud usage.

6. Carbon Aware SDK

⭐: 456+

A toolset to help you measure the carbon emissions of your software, in turn helping you measure and reduce your software’s carbon emissions, and choose when and where you run your software to make it greener.

Bonus: check out the Green Software Foundation’s other repository, Impact Framework, which is a framework to model, measure, simulate, and monitor the environmental impacts of software.

7. CO2.js

⭐: 388+

An open source JavaScript library that enables you to estimate the carbon emissions produced by transferring bytes of data on the internet, get different forms of grid intensity data, such as annual average and marginal data by country, and make automated queries against Green Web Foundation’s Green Domain’s dataset.

Bonus: check out The Green Web Foundation’s other repositories, grid-intensity-go, which helps you factor carbon intensity into decisions about where and when to run jobs, the Green Cost Explorer, which will show you your climate-related spend analysis for AWS, and carbon.txt, which allows digital service providers to demonstrate that their digital infrastructure runs on green electricity.

8. carbontracker

⭐: 356+

Track and predict your energy consumption and carbon footprint of training deep learning models.

9. Kernel Tuner

⭐: 269+

Create optimized GPU applications in any mainstream GPU programming language (CUDA, HIP, OpenCL, OpenACC).

10. experiment-impact-tracker

⭐: 266+

A simple drop-in method to track energy usage, carbon emissions, and compute utilization of your system.

Bonus tools (that you shouldn’t miss out on)

We found a couple other great measurement tools from Green Coding Solutions that you should check out: Eco-CI, a project aimed at estimating energy consumption in continuous integration (CI) environments, and Green Metrics Tool, which measures the energy and CO2 consumption of software through a software life cycle analysis (SLCA).

Do you know of a green software repository that we missed? Let us know! This list is meant to grow and develop, so we welcome any suggestions from our community on how we can improve it. And don’t forget, this is just the beginning of the conversation, so stay tuned as we continue to share knowledge from our community and develop new resources to help you code more sustainably!

The post The 10 best tools to green your software appeared first on The GitHub Blog.

Open source software has come a long way from its origins as a niche endeavor of technical experts. Recent studies have shown that open source software can be found in 96% of code bases, and its demand-side value to the economy is estimated at $ 8.8 trillion. Its open model of collaboration makes it easy for governments, businesses, nonprofits and individuals to work together for the common good. Yet you don’t have to be an idealist to rely on open source: the ubiquity of the tech speaks for itself.

While many critical open source projects are maintained by developers as part of their jobs, many parts of the open source ecosystem are underfunded, and only get enough attention when a potentially catastrophic vulnerability is discovered every few years. Like with physical infrastructure, we shouldn’t limit ourselves to funding it once a bridge has collapsed. To better understand strengths and weaknesses in the funding landscape, GitHub is conducting research with Linux Foundation and Harvard Business School into how organizations support open source. GitHub would not exist without open source and we are committed to doing our part to address the open source sustainability gap. It’s encouraging to see that more and more public institutions are doing the same.

Open source takes center stage at the UN

This shift in public sector attitudes was visible at the OSPOs for Good summit in July, where hundreds of open source enthusiasts swarmed the United Nations headquarters in New York City to discuss what open source can do for global development, and what the world’s nations can do for open source. Our very own Demetris Cheatham shared how joining open source communities was instrumental to her computer science education and later inspired her work advancing diversity, equity and inclusion at GitHub. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) reflected on its work to strengthen open source software security, Germany presented its Sovereign Tech Fund, which invests $20M per year into the maintenance of basic open source technologies such as curl, PHP or Log4J. France showcased its community of open source champions in public administrations, called Les Blue Hats.

The United Nations’ commitment to open source doesn’t end at hosting a conference. Its goal is for governments to adopt the Global Digital Compact at the Summit of the Future later this month. One of the Global Digital Compact’s key commitments is to increase funding for Digital Public Goods (DPGs), that means open source software, open standards, open data, open AI systems, and open content collections that adhere to privacy and other applicable laws and best practices, do no harm, and help attain the Sustainable Development Goals (SDGs).

Public and private sector working together

About 80% of DPGs live on GitHub. To help developers connect with these projects, we have launched the For Good First Issue where developers can easily find and contribute to open source projects that support SDGs. If you want to lend your skills to an open source project focused on a public good, this is a great place to start working together with public sector-led open source projects, without having to be a public policy geek.

We believe that industry and government can work together to find solutions to the sustainability challenge of open source maintenance as well. Through GitHub Sponsors, we provide the infrastructure to make it easier for organizations to invest in the open source projects they depend on. To date, this has resulted in +$40MM in funding. GitHub is a sponsor of the Open Technology Fund’s FOSS Sustainability Fund, which combines public and private sector funding to support the long-term maintenance of open source projects. Through GitHub Accelerator, we provide resources and mentoring to help open source projects become financially sustainable. Through GitHub Fund, we invest in the next generation of open source entrepreneurs,- providing capital, connections, access, and benefits to help open source companies grow. Last but not least, we support open source maintainers with free product offerings, like GitHub Copilot, and community, like Maintainer Community.

We hope that the United Nations’ efforts to convince governments of the value of open source will lead to the creation of many more initiatives like the U.S. Open Technology Fund or the German Sovereign Tech Fund. Advocating for such programs and highlighting their positive impact is a pillar of our developer policy work. Whenever the budget for one such fund gets cut, many new ones have to take its place.

Better yet: by treating open source software as a public good, funding its maintenance should become a central part of industry and government spending.

The post Software as a public good appeared first on The GitHub Blog.

The history of technology is, in many ways, a history of platforms and their ecosystems. From the early days of personal computing with Windows and macOS to the mobile and cloud revolution, the most impactful tech products have rarely stood alone. Instead, they’ve served as foundations upon which entire systems of complementary tools, applications, and services have been built. These ecosystems, more than the platforms themselves, often determine how technology impacts our everyday lives.

When we introduced GitHub Copilot Extensions in limited public beta in May, it marked our first step in evolving GitHub Copilot into a platform that could support a much larger ecosystem. Copilot Extensions allow developers to integrate their favorite development tools directly into the Copilot experience. This means that AI can now not only suggest code but also interact with external databases, testing frameworks, deployment tools, and more–all without requiring developers to leave their flow.

Today, Copilot Extensions are now available in public beta to all Copilot users and open for any developer or organization to create extensions. Alongside, we’re introducing a comprehensive Copilot Extensions Toolkit, designed to equip developers by centralizing the information they need to build quality extensions. This announcement isn’t just about wider availability; it’s about the open nature and democratization of AI-assisted development tools. Whether you’re an individual developer looking to streamline your workflow or an organization aiming to integrate proprietary tools, Copilot Extensions now offers a platform to make that happen and for you to share your creations on the GitHub Marketplace.

Customization and integration made for organizations

For organizations and individuals, Copilot Extensions offer unprecedented opportunities for customization and integration. All Copilot users can now build private Copilot Extensions that encapsulate their internal and proprietary tools, frameworks, and best practices. Imagine a world where Copilot doesn’t just know general coding patterns but understands your company’s specific workflows, coding standards, and internal APIs.

This level of customization can lead to significant productivity gains. Developers spend less time context-switching between tools, searching for documentation, or remembering company-specific conventions. Instead, they can focus on solving core business problems, with Copilot acting as a knowledgeable guide that understands both the code and the broader organizational context.

For example, the team at Octopus developed a Copilot Extension to offer on-demand expertise on their systems and processes to their developers from within Copilot Chat.

A new platform for innovation

For third-party developer tools providers, Copilot Extensions represent a massive new opportunity. With over 77,000 organizations, 1.8 million paid subscribers, and more than 500,000 students, teachers, and open source maintainers using Copilot, creating an extension is a way to get your tool directly in front of a vast, engaged audience.

This isn’t just about distribution, though. By integrating deeply with Copilot, extensions can offer a fundamentally better user experience. Instead of requiring developers to leave their coding environment to use a tool, extensions allow seamless interaction through natural language queries right in the editor.

We expect to see a wave of innovation as developers reimagine their tools for this new, AI-driven paradigm. From improved testing frameworks that can generate tests based on code changes to deployment tools that can explain and fix issues through a conversational interface, the possibilities are boundless.

Introducing the GitHub Copilot Extensions Toolkit

The Copilot Extensions Toolkit equips developers and organizations with information to help them build quality extensions.

We’ve created step-by-step tutorials to guide you through the process, along with additional resources including documentation, a CLI tool, samples, and SDKs. Regarding use of these resources, we’ve developed a Copilot Extension for GitHub Models, showcasing how easy it is to bring context into and work with tools in Copilot.

What’s next

We’re committed to fostering a thriving Copilot Extensions ecosystem, providing the tools and support needed for developers and organizations to create innovative, powerful extensions as well as to find integrations with Copilot for all the tools and services they rely on.

As we move forward, we’ll see how extensions are used, gather feedback, and continuously improve the platform. The future of AI-assisted development is not just about smarter suggestions—it’s about creating a flexible, extensible environment where AI can be tailored to every developer’s and organization’s unique needs.

We invite you to join us on this journey, whether by using extensions to supercharge your development workflow or by building extensions to share your innovations with the world.

The era of truly customizable, AI-assisted development starts now.

The post Enhancing the GitHub Copilot ecosystem with Copilot Extensions, now in public beta appeared first on The GitHub Blog.