GitHub Commits to Replacing “master” with a Neutral Default Branch Name

GitHub announced in June 2020 that it was actively working to replace the term “master” — historically used as the name of a repository’s default branch — with a neutral alternative such as “main.” The announcement came from GitHub CEO Nat Friedman, who confirmed the effort publicly on Twitter after being prompted by Google Chrome developer Una Kravets.

The move placed GitHub among a growing number of technology companies and open source projects revisiting terminology that critics argue carries racially charged connotations — a discussion that accelerated significantly during the Black Lives Matter protests of mid-2020.

Why This Terminology Is Contested

The concern centers on terms such as “master/slave” and “blacklist/whitelist” that are widely used in computing to describe technical relationships, but which some researchers and practitioners argue reflect and reinforce racial stereotypes. A 2018 academic paper cited in ZDNet’s reporting stated: “Such terminology not only reflects racist culture, but also serves to reinforce, legitimize, and perpetuate it.”

Proponents of change argue that replacing these terms carries a low technical cost while sending a meaningful signal of inclusion to developers from underrepresented communities. Common proposed replacements include:

• master → main, default, primary, or root
• slave → secondary, replica, or worker
• blacklist → deny list or exclude list
• whitelist → allow list

How Git and GitHub Use “master”

In Git, the version control system that underpins most modern software development workflows, a repository is initialized with a default branch historically named master. Developers create feature branches from this default branch, commit their changes, and merge them back in via pull requests. GitHub, which hosts tens of millions of Git repositories, surfaces the master branch prominently throughout its interface.

Because the default branch name is set at the Git level and inherited by GitHub, a change of this magnitude requires coordination across tooling, documentation, CI/CD pipelines, and existing repository histories — making it a non-trivial infrastructure decision for both the platform and its users.

A Movement With Roots Before 2020

Although the 2020 protests gave the effort fresh momentum, the push to remove racially charged language from software predates that moment by several years:

• 2014: The Drupal project replaced “master/slave” with “primary/replica” in its database configuration terminology.
• Subsequently: The Python programming language, the Chromium browser project, Microsoft’s Roslyn .NET compiler, and the PostgreSQL and Redis database systems made similar changes.

Despite those precedents, adoption remained uneven across the industry until 2020, when several high-profile projects committed to change in quick succession.

Other Projects Moving in the Same Direction

Around the same time as GitHub’s announcement, a number of other prominent projects and organizations announced similar intentions:

• Android — committed to replacing blacklist/whitelist with neutral alternatives.
• Go programming language — indicated plans to update its terminology.
• PHPUnit and Curl — stated intentions to adopt inclusive language.
• OpenZFS — replaced master/slave terminology used to describe storage relationships.
• OpenSSL, Ansible, Microsoft PowerShell, and P5.js — were reported to be evaluating or initiating changes to their default branch names.
• LinkedIn — engineer Gabriel Csapo publicly stated he was filing requests to update Microsoft’s internal libraries.

The Git project itself also opened discussion threads on its mailing list and GitHub Issues tracker about officially changing the default branch name, though those discussions attracted significant debate and pushback at the time.

The Counter-Arguments

Not everyone in the technical community supports the changes. Common objections include:

• The terms “master” and “slave” are now used in a purely technical sense to describe hierarchical system relationships, divorced from their historical origins.
• Renaming default branches introduces friction for existing repositories, tooling, scripts, and documentation.
• The word “blacklist,” some argue, derives from the historical practice of keeping “black books” listing problematic individuals, rather than from any racial reference — though this etymology is itself disputed by linguists.

Supporters counter that the technical cost of migration is manageable, that etymology does not negate real-world impact on affected communities, and that the industry regularly updates its vocabulary as understanding evolves.

What Happened Next

GitHub subsequently rolled out tooling to allow repository owners to rename their default branch and, eventually, set main as the default for all newly created repositories. Git itself, as of version 2.28 (released July 2020), introduced the init.defaultBranch configuration option, enabling users and organizations to set their preferred default branch name globally.

GitHub’s participation — given the scale of its platform — was widely seen as a turning point that both legitimized and accelerated adoption of inclusive naming conventions across the open source ecosystem.

Application performance management is different than container management in myriad ways. Don’t confuse the two.

It’s scary how quickly widespread adoption was achieved for container technology in the world’s mission-critical business applications. Consider that it took about 10 years after the introduction of Java for the programming language to become a near-ubiquitous standard (followed shortly by C#/.Net). In stark contrast, enterprise-ready Docker just turned 5 years old, and it’s been pretty much everywhere for a while.

Why so relatively quick? Are containers that much easier to deploy, control and manage than traditional Java app servers were? Uh, no! In fact, containers create a whole mess of control and management issues (especially performance management) that even the well-established application performance management (APM) companies struggled to create any visibility from inside containerized applications.

But when DevOps teams considered how useful and powerful containers were for deploying and operating microservice applications, collectively they figured it was worth the pain. To achieve the efficiencies of deployment, they were willing to put up with the management headaches associated with operating them, from over-committing infrastructure to application hangs and a lack of visibility, even with (or especially with) APM solutions.

Enter Kubernetes
And then came orchestration; more specifically, along came Kubernetes. While not the first or only system designed to manage containerized systems, Kubernetes simply rolled over the alternatives. How quickly did that occur? Quicker than you can spell Kubernetes—and I mean spelling it “K – 8 – S.” In what seemed to be one announcement on top of another, every cloud service provider announced its own enterprise version of Kubernetes. These enterprise distributions were announced by IBM, Microsoft, Red Hat, Amazon, Google and others; VMware announced it even before its cloud was available. Other orchestration tools simply didn’t know what hit them, and really didn’t stand a chance.

Kubernetes Becomes King of the Hill
Having a standard, especially when it comes to managing infrastructure (and especially application infrastructure), makes everybody happy. Thus, Kubernetes continued to win over the community—or to be more specific, communities—of developers and operations. K8S provided some semblance of control in the wild, wild west of containers and microservices. As a bonus, the multitude of distribution choices satisfied another requirement of modern application delivery teams—the desire to avoid vendor lock-in—pretty much for any part of their environment.

But even with the enterprise versions of K8s (which now includes newer distributions Pivotal PKS and Rancher in its ranks), container “management” is missing two major aspects of delivering applications that meet service requirements. The first gap is performance management; specifically, performance monitoring of the services running in Kubernetes. The second is a lack of understanding how a specific set of services, hosts, deployments and pods contribute toward the overall composition of a specific application. There’s a little chicken-and-egg problem there, but the salient point is that the orchestration system manages resources across containers—not applications and not application performance.

Orchestration certainly makes containers more malleable and enterprise-ready, but without visibility into application performance, service owners can’t prove (or even know) how well the application is actually servicing customer needs. To answer that question, the operations, DevOps, and/or development teams must have a way to tie application performance directly to Kubernetes (and Kubernetes orchestrated applications).

Ignoring Application Performance is Asking for Trouble
One could choose to simply ignore questions of how the application is performing: Is the app meeting its promised service levels (SLAs)? Does it scale appropriately? Is the response time fast enough? After all, if your applications are running properly, wouldn’t you be able to tell through the overall infrastructure usage and container status? (Hint: That’s a trick question—the answer is, “Not on your life!”)

Think of the last time you were in a meeting with the CIO (or maybe you’re the CIO meeting with the application owner). When she asked how the apps were doing, I’m guessing the answer, “Well, our resource usage is normal,” somehow would not be a satisfactory answer.

The onus for application performance management has shifted over the years. When the first APM tools appeared, it was simply a matter of survival to keep the apps running, getting visibility into production code running on Java application servers. Only the largest of organizations could afford (or even consider) to purchase APM solutions.

Today, even the tiniest startups rely on their business applications to conduct their business. Application performance and availability, troubleshooting and optimization are not nice-to-have luxuries of the Fortune 50—every ops team and development team has the need to see the performance of services and applications.

A Lesson to Learn From Capacity Management (and Capacity Planning)
One of the interesting anecdotes I like to use when discussing the evolution of IT operations is to talk about the difference between the “old school” practice of capacity planning and the ITIL/ITSM practice of capacity management.

Capacity planning was the exercise of figuring out the configuration, number and size of servers (physical servers, no less) needed to execute the application being delivered to operations. The answer was static—CPU/core counts, I/O bandwidth, storage size, memory size—and a count. The planner was (mayyyyybe) thinking about the concept of providing resources for the application to run properly, but all they had to go on was an estimate of compute resources needed by the programmer.

Then along came the concept of capacity management. First of all, capacity management was not an exercise with a hard beginning and end. Capacity management was fluid, always in play. Why? Sure, the capacity manager determines the exact same resource configuration—CPUs, memory, hard drive, network. The difference is the phrase that follows the answer, “In order to meet our scalability targets (1,000 concurrent users) and performance targets (all transactions less than half a second) …”

Capacity management is an always-active, always-questioning and always-reporting discipline. It requires adjustments to “the answer” depending on what’s happening with the applications.

Kubernetes and Application Performance Management
To ensure that orchestrated microservice applications from single mobile apps to complex financial suites are running at optimal performance levels, it’s critical to include application performance to the Kubernetes mix. Analogous to capacity management, K8s with APM provide resource allocation and management to meet your application scalability and performance targets. You can’t meet them if you’re not measuring them.

The final piece of the puzzle is picking an APM tool that can handle the three most difficult aspects of orchestrated container applications:

Visibility into containers, their stack and the performance characteristics of the services running on them (throughput, error rate and latency).
Observability in Kubernetes, understanding how the orchestration system is related to the services running on it.
Dealing with the complexity and constant change in microservice environments, being able to filter out the noise and show stakeholders everything they need to see about components and services they’re responsible for.
Conclusion
If you’re going to run microservices, you’re probably running them in containers. And if your application is critical to your business, you should be orchestrating your containers. Kubernetes is a good choice since enterprise versions are included with almost any cloud provider. Always keep an eye on your application’s performance with a modern application monitoring solution that supports the observability of your Kubernetes-orchestrated environments.

DevOps in 2019: Stability, Open Source, and Platform Growth

Change is constant in software development, yet some tools and platforms demonstrate remarkable staying power. Looking back at 2019, two facts stand out: Java and .NET — both dominant a decade earlier — remained the backbone of enterprise development, and GitHub continued to grow as the central hub of the DevOps ecosystem, even after being acquired by Microsoft.

Each of these three pillars went through significant evolution in 2019 — evolution that shaped how teams build, share, and ship software. Here is a breakdown of the developments that defined DevOps that year.

Java Redefined Itself with Jakarta EE 8

2019 was arguably the most consequential year for enterprise Java in two decades. The release of Jakarta EE 8 in September 2019 marked the first time enterprise Java was governed entirely under an open source model, free from single-vendor control.

The transition had been in motion since September 2017, when Oracle announced it would hand Java EE over to the Eclipse Foundation. The Foundation renamed the project Jakarta EE and spent two years establishing a new governance process, intellectual property regime, and release pipeline before shipping the first official release.

Mike Milinkovich, executive director of the Eclipse Foundation, described the significance to ITPro Today:

“With Jakarta EE, we are able to deliver a set of specifications that are free for implementation and are available under an entirely new licensing regime that’s far more open and cost-effective than what was available under Oracle and the JCP. The thing to keep in mind is that Java, as the language and as a platform, is still one of the largest and most widely used programming languages in enterprise computing on the planet.”

— Mike Milinkovich, Executive Director, Eclipse Foundation

For DevOps teams running Java-based workloads, the shift to open governance matters in practical terms: specifications are now free to implement, vendor lock-in risk is reduced, and the community — rather than a single corporation — drives the roadmap.

.NET Core 3.0: Open Source Gets Desktop and Self-Contained Apps

Microsoft’s .NET has been Java’s historical counterpart in enterprise development. In September 2019, .NET Core 3.0 shipped with several changes relevant to DevOps engineers and application developers alike.

Key Features in .NET Core 3.0

• C# 8 support: .NET Core 3.0 added support for C# version 8, bringing nullable reference types, async streams, and other language improvements.
• Windows desktop frameworks: Windows Presentation Foundation (WPF) and Windows Forms gained support, allowing legacy Windows desktop applications to be built and run on .NET Core.
• Self-contained executables: Applications can now ship as a single executable that does not require a separate .NET runtime installation on the target machine — a meaningful step for simplified deployment and containerisation.

Microsoft reported at the time that more than one million developers were actively using .NET Core. Much like Jakarta EE, .NET Core is fully open source, reinforcing an industry-wide trend of major runtimes and frameworks moving away from proprietary licensing.

GitHub’s Dominance Continued Under Microsoft

2019 was GitHub’s first full calendar year operating as a Microsoft business unit, led by CEO Nat Friedman. Many in the developer community had expressed concern at the time of the 2018 acquisition that Microsoft’s ownership might drive users toward alternatives. Those concerns did not materialise in measurable numbers.

At the GitHub Universe conference in November 2019, Friedman reported that the platform had surpassed 40 million developers, with more than 10 million joining in the previous year alone.

“More developers are choosing GitHub every day than ever before. Just in the last year, over 10 million new developers joined GitHub and started contributing to projects on GitHub.”

— Nat Friedman, CEO, GitHub (GitHub Universe, November 2019)

GitHub Actions and GitHub Packages

The most significant platform additions announced at GitHub Universe 2019 were GitHub Actions and GitHub Packages, both of which became generally available in November 2019.

• GitHub Actions: A workflow automation system built directly into GitHub. Teams can define CI/CD pipelines, automate testing, releases, and other repository events using YAML-based workflow files stored alongside their code.
• GitHub Packages: A package registry integrated with GitHub that supports Docker images, npm, Maven, NuGet, and RubyGems packages. It works alongside GitHub Actions and existing CI systems to provide a unified build-and-publish workflow.

Together, these features positioned GitHub as more than a code hosting service — they made it a first-class component of modern DevOps pipelines, combining source control, CI/CD, and package distribution under one platform.

What These Trends Meant for DevOps Teams

Looking at 2019 in aggregate, several clear themes emerge for DevOps practitioners:

• Open source governance is now the expected norm for major runtimes. Both Jakarta EE and .NET Core moved control away from single vendors, giving enterprises more confidence in long-term platform stability.
• Platform consolidation around GitHub accelerated. The addition of Actions and Packages reduced the need for separate CI and package registry tools, simplifying toolchain decisions for smaller teams.
• Java and .NET are not legacy concerns. Both platforms received substantial investment in 2019 and continue to underpin a large share of enterprise workloads. DevOps tooling and pipelines built around these languages remained as relevant as ever.

For teams evaluating their DevOps strategy, the lessons of 2019 reinforce that choosing well-supported, community-governed platforms and consolidating toolchains around mature ecosystems reduces operational risk over time.

AWS Extends .NET Core Support to CodeStar and CodeBuild

In July 2017, Amazon Web Services announced that two of its core developer tools — AWS CodeStar and AWS CodeBuild — would add support for .NET Core. The move came in direct response to developer demand for first-class .NET Core tooling on the AWS platform.

.NET Core is a lightweight, open-source, cross-platform runtime that enables developers to build web applications and services targeting Windows, Linux, and macOS. Its cross-platform nature made it a natural fit for AWS’s Linux-based infrastructure, and the addition of .NET Core templates brought parity with the JavaScript, Java, Python, Ruby, and PHP project types already supported.

What Is AWS CodeStar?

Launched in April 2017, AWS CodeStar is a unified service designed to simplify setting up a complete software development toolchain on AWS. Rather than manually wiring together individual services, CodeStar provides a pre-configured project environment that includes:

• A project management dashboard for tracking team activity and project status
• An automated continuous delivery (CD) pipeline built on AWS CodePipeline
• A Git code repository powered by AWS CodeCommit
• Automated build (AWS CodeBuild) and deployment (AWS CodeDeploy) stages
• Out-of-the-box integration with Atlassian JIRA Software for issue tracking and project management

CodeStar is also designed to integrate with existing IDEs, reducing friction for developers who want to use their existing local tooling while deploying to the AWS cloud.

What Is AWS CodeBuild?

AWS CodeBuild is a fully managed build service that compiles source code, runs tests, and produces deployment-ready software packages. Because it is fully managed, developers do not need to provision, configure, or scale their own build servers — AWS handles capacity automatically based on the workload.

With the July 2017 update, CodeBuild gained the ability to build and deploy .NET Core applications targeting both Amazon EC2 and AWS Lambda, expanding its supported runtime ecosystem significantly.

New .NET Core Project Templates in CodeStar

The CodeBuild .NET Core capability directly enabled the addition of new project templates in CodeStar. AWS engineer Tara Walker described the scope of the templates in an AWS blog post at the time:

“Each template provisions the underlying AWS Code Services and configures an end-to-end continuous delivery pipeline for the targeted application using AWS CodeCommit, AWS CodeBuild, AWS CodePipeline, and AWS CodeDeploy.”

— Tara Walker, AWS

The new .NET Core templates specifically support:

• Deploying .NET Core applications to Amazon EC2 Linux instances
• Deploying .NET Core applications to AWS Lambda
• Sample .NET Core starter code included out of the box
• A complete, pre-wired software development toolchain ready to use immediately

Walker also noted that the templates join the existing set targeting Amazon EC2, AWS Elastic Beanstalk, and AWS Lambda for JavaScript, Java, Python, Ruby, and PHP — making .NET Core a first-class citizen in the CodeStar ecosystem.

Why This Mattered for .NET Developers

Prior to this update, .NET developers working on AWS either had to rely on Windows-centric tooling or manually configure build pipelines without native CodeStar templates. The addition of .NET Core support meant that teams could:

• Use Visual Studio 2017 as their local IDE while targeting AWS cloud infrastructure
• Run .NET Core workloads on Linux-based EC2 instances, reducing OS licensing costs compared to Windows Server
• Deploy lightweight, cross-platform microservices to AWS Lambda using the same CI/CD pipeline workflow available to other language runtimes
• Onboard new projects in minutes rather than manually configuring build infrastructure

This announcement reflected a broader industry trend: Microsoft’s embrace of open-source and cross-platform development with .NET Core, combined with cloud providers like AWS integrating that ecosystem into their managed tooling. For DevOps teams managing mixed-language environments on AWS, the update simplified governance by consolidating .NET workloads into the same CodeStar/CodeBuild/CodePipeline workflow used for other runtimes.

Key Takeaways

• AWS CodeStar and CodeBuild added .NET Core support in July 2017
• New CodeStar project templates cover EC2 Linux and Lambda deployment targets
• CodeBuild provides fully managed build infrastructure — no server provisioning required
• CodeStar integrates CodeCommit, CodeBuild, CodePipeline, CodeDeploy, and JIRA in a single dashboard
• The update brought .NET Core to parity with existing supported runtimes (JavaScript, Java, Python, Ruby, PHP)

1. Pre-Made, Reproducible Runtime Environments

Provisioning a traditional server means installing the OS, the .NET SDK or runtime, a web server, and configuring environment variables — every single time. With Docker, you encode all of that in a Dockerfile or docker-compose.yml. Every time the container starts, it is guaranteed to have exactly the software it needs.

When a dependency needs upgrading, you update the container definition and redeploy. The change is atomic, auditable, and reversible — reducing server maintenance toil and making rollbacks straightforward.

2. Version-Controlled Infrastructure

Because your Dockerfile and docker-compose.yml live alongside your application code in source control, your infrastructure is versioned with your code. When you check out an old commit to reproduce a bug, you also get the exact environment that was running at that time. Spin up the container, attach a debugger, and investigate — no guessing about what SDK version or configuration was live at the time.

3. Runtime Consistency — Eliminating “Works on My Machine”

If a developer runs their application inside the same Docker container that will be used in production, then development, staging, and production are, by definition, the same environment. Differences in OS patch level, framework version, or environment variable configuration — the usual culprits behind environment-specific bugs — are eliminated because every environment is derived from the same image.

4. Security Isolation Comparable to Virtual Machines

Containers share the host kernel but run in their own isolated user space. By default, one container cannot access the file system or network of another container, nor of the host machine, without explicit configuration. Docker uses Linux namespaces and cgroups (or the Windows equivalent) to enforce this boundary. The result is a security posture similar to running separate VMs, but with significantly less overhead.

Container images typically use a minimal base OS layer, reducing the attack surface compared with a fully provisioned virtual machine.

5. Lighter Than Virtual Machines

A virtual machine pre-allocates CPU and RAM at creation time, whether or not the workload needs those resources. A container uses only the host resources it actually consumes, and you can apply soft and hard limits using Docker’s --memory and --cpus flags (or equivalent Compose settings). This makes it practical to run many containers on a single host without one misbehaving container starving the others — for example, during a denial-of-service event or a memory leak.

6. Native Cloud Provider Support

Both Microsoft Azure and Amazon Web Services offer managed container services that deploy Docker images directly. Azure supports single-container deployments via Azure App Service for Containers, and orchestrated workloads via Azure Kubernetes Service (AKS) and the now-retired Azure Container Service. AWS provides Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). This breadth of support means your containerised .NET application can be deployed to managed infrastructure with minimal additional configuration.

7. Cleaner CI/CD Pipelines

Many CI/CD platforms — including Azure DevOps, GitHub Actions, GitLab CI, and Jenkins — can build, test, and push Docker images as first-class pipeline steps. When your unit and integration tests run inside the same container image that will be promoted to production, you eliminate a whole class of pipeline-specific environment discrepancies. A test failure on the build server is far more likely to be a genuine code problem, not an environmental quirk.

8. Deep Visual Studio Integration for .NET

Microsoft has invested heavily in making Docker a first-class part of the Visual Studio developer experience. The Visual Studio Tools for Docker generate a base Dockerfile and Compose files for new projects. Pressing F5 builds the image and attaches the Visual Studio debugger to the running container — meaning you are debugging inside the container, not against a locally installed runtime that may differ from production. This workflow is also integrated into Visual Studio Code via the Docker extension.

9. Standardised Container Format and Portability

Docker popularised and, together with the Open Container Initiative (OCI), helped standardise the container image and runtime format. A Docker image built on a developer laptop can run on a cloud VM, a Kubernetes cluster, or an on-premises server without modification. This portability removes friction at every handoff point — from developer to tester, from tester to ops, from on-premises to cloud.

10. Straightforward Horizontal Scalability

Scaling a containerised .NET application horizontally is largely a matter of configuration. Docker Compose lets you declare the desired replica count for a service. Docker Swarm or Kubernetes can enforce that replica count — automatically replacing containers that crash and distributing load across healthy instances.

For .NET web applications running on Kestrel, Microsoft already recommends placing a reverse proxy in front of Kestrel in production. Adding an NGINX or Traefik reverse-proxy container to your Compose file satisfies that recommendation and gives you load balancing across replicas. You can define this topology from the outset rather than retrofitting it later.

Getting Started

The combination of Microsoft’s .NET container images on Docker Hub, Visual Studio’s built-in Docker tooling, and mature cloud deployment targets makes adopting Docker for .NET projects more accessible than ever. Start by adding Docker support to an existing ASP.NET Core project in Visual Studio, review the generated Dockerfile to understand the multi-stage build pattern, and work outward from there to Compose-based local orchestration and then to a managed cloud service.