How GitHub COO Erica Brescia runs the coding gold mines

An astonishing amount of the code that runs the world's software spends at least part of its life in GitHub. COO Erica Brescia is responsible for making sure that's not a disaster in the making.

Brescia joined GitHub after selling Bitnami, the open-source software deployment tool she co-founded, to VMware in 2019. She's responsible for all operational aspects of GitHub, which was acquired by Microsoft in 2018 for $7.5 billion in one of its largest deals to date.

Microsoft wanted to own GitHub because GitHub owns one of the most central gathering places for software development on the planet. More than 65 million software developers use GitHub to store code and collaborate on projects with colleagues and, increasingly, as part of their software assembly lines. That also makes it a prime target for hackers, as well a potential source of frustration for software developers around the world.

Brescia has witnessed a dramatic expansion in both enterprise sales and hiring at GitHub in the two years since she joined the company. She's also choreographed the tricky dance steps that come with operating a service used by almost everyone in tech that also happens to be owned by one of the biggest software companies ever created. In an interview with Protocol, she discussed the state of GitHub's infrastructure, changes in open-source software philosophies, and why "hybrid" work strategies will thrive in the post-pandemic era.

This interview has been edited and condensed for clarity.

It's been a little over two years since you joined Github. Can you give me a sense of what things have changed?

While I didn't work at GitHub previously, my husband actually did work [at GitHub] with our CTO; he had left before I joined. But I met the founders when they were just starting the company. I have long followed GitHub, and admired the company prior to joining it.

I think probably what's most interesting about what has changed is really the expansion of the platform. When Microsoft acquired the company it was really focused just on code collaboration and since then we've greatly expanded the surface area of GitHub to include, you know, Actions and a complete [continuous integration/continuous deployment, or CI/CD] engine, we've recently launched Codespaces, our security investments and products. Those announcements I think are of critical importance.

Certainly, from an operational perspective, the company has grown quite a bit. We were around 1,000 employees when I joined, and we're about 2,500 now.

In terms of the operating structure, is LinkedIn a good parallel for the way that GitHub works within the Microsoft world?

There's certainly a lot of similarities. The most important one is we really do manage the business independently on [its own] P&L. We have our own C-suite, just like LinkedIn, [and] we make our own decisions around the direction of the products and the business. Of course, we do that in some collaboration with folks at Microsoft. But our roadmap, our resource allocation, everything is really left up to us.

I think what might be a little bit different is there are a lot of opportunities on the product side to co-develop with Microsoft. I think Codespaces is a great example of that.

Do you anticipate they're having that kind of arm's-length separation for the foreseeable future?

I do. GitHub is the home for all developers no matter where they want to build. They might be deploying to Azure, but they might also want to deploy to AWS, or Alibaba, or Google or any number of other providers around the world. And so, you know, we'll always focus on what's best for developers and offering developers choice. We'll continue to leverage the resources and the opportunities that we have through Microsoft, whether that's an enormous global sales force or products like VS Code, that we can build on top of [to] accelerate GitHub in a way that provides us with a unique competitive advantage.

I remember when the deal was announced there was a fair amount of worry in some developer circles that GitHub would put this really big "deploy on Azure" button, like, right in the middle of the UI. As you think about co-development opportunities, how do you balance that desire to work more closely with Microsoft against this customer base that's very wide and diverse and has a wide variety of needs?

It's one of my favorite topics of conversation. Yeah, we will not have a "deploy to Azure" button without a "deploy to the other cloud vendors" button as well. Currently, we don't have either. And that's of critical importance from my perspective.

One of the organizations that rolls up to me is our business development and technology partnerships and engineering team. Their mandate is really to make sure that we have healthy and fruitful relationships with a variety of players in the ecosystem, not just the other cloud vendors, but also companies that compete with GitHub in various ways. When I first joined, my three first meetings outside of GitHub were all with CI/CD providers in advance of our launch of Actions to tell them what was coming and talk about how we can continue to work together to make sure the developer is going to have a great experience — not only with GitHub products, but also with other products that they might want to use in the ecosystem.

If you go back to my first Universe keynote [at GitHub's annual conference], which was towards the end of 2019, I had Clare Liguori from AWS on stage demoing our integration with them, we've done a bunch of great work there. It was Amazon, not Azure, that was on stage, and there's a good reason for that.

Ultimately we're here to deliver what developers need, and I'll go back to what I said before, which is, that's choice. I think you asked, how do you balance that? Part of it is through this lens of "developers first" whenever we're making product decisions, and whenever our product folks are meeting with our technology partnerships folks that is the topic of conversation.

Are we striking the right balance? Is this really what's best for developers? I think if we truly are always putting developers first that leads you to make the right decisions around preserving choice and optionality.

Where does GitHub run at the moment? Do you run on Azure? Do you maintain your own infrastructure?

We have quite a bit of our own infrastructure that we maintain. So we maintain our own data centers. And we also run some things on AWS and some things on Azure.

Has that changed in the last couple of years post acquisition?

Our infrastructure has greatly expanded because the platform has expanded vastly. We're continuing to invest across all three platforms, just depending on our needs. Obviously, Codespaces runs on Azure because we built it on top of VS Code. But there's plenty of other things that are running [in] other places.

There's an argument that security is better on the cloud versus maintaining your own data centers, although I would suspect that GitHub is a little more advanced than most organizations out there. But given the strategic importance of what people have stored in GitHub to their businesses, I am curious about how that works.

We have an exceptionally good track record from a security perspective and we have an incredible team of folks that does that work. That said, we've made a very significant additional investment in security this year; we hired an incredible guy, Mike Hanley, who scaled up Duo from under 100 employees through Cisco, then he was the CSO at Cisco.

We're greatly expanding that team. With the increase in nation-state threat actors that are after every technology company, I don't think that's unique to GitHub. But there's a lot of important investment that needs to be made across the industry.

I'm sure you're tracking all the executive order stuff on [software bill of materials] requirements and [Developer Certificate of Origin checks]. And, as you might imagine, we're very deep in in all of that work, and making sure that GitHub as a platform is not only secure in the platform itself, which is of the paramount importance given the value of intellectual property and code on our platform and the opportunities that that might provide to a bad actor, but also providing our customers with the tools that they need in order to not only develop, but maintain secure source code.

I think the original approach that some folks took to open source was like, "We're just gonna build something cool and figure it out later." And that's really, really risky business these days.

I know you have a very long history within the open source community, and this world has obviously changed so much over the last three or four years in terms of the way that people think about the relationship between open source software and commercial activity. If you were starting a company today, would you feel as confident about building around an open source project as you would have, say, eight or 10 years ago?

It depends on what you're building. I was on the phone with one of the founders of Isovalent earlier today, and they're building Cilium, which is based around [the data packet filtering tool] eBPF, which is a really interesting technology that I'm far from an expert on. I think this open core model really can work, it really can work well, but it just depends on what you're building and how people are going to use it.

I think that cloud and SaaS definitely did change things. People need to be thorough when they're thinking about their strategy from the beginning, when deciding whether or not to open source at all, and which parts of their business to open source and what they're going to build around that to drive additional value. With some companies, it's very, very clear; it's easy to draw a line between enterprise features and non-enterprise features. And then for other companies, that's a lot harder to do.

I think the original approach that some folks took to open source was like, "We're just gonna build something cool and figure it out later." And that's really, really risky business these days. I think you need to be more deliberate in your strategy and what you're trying to get out of open source.

I think the other thing — and then I'll stop because I could talk about this for a very long time — is the way that people think about open source as a part of their model has changed, too. You know, I think before people just thought, "I'll make it open source, and then everybody's gonna use it." I think folks [now] have a much better understanding of the commitment it takes to actually build something in open source and nurture a community around it.

What do you think about the ethical licensing movement?

I will be honest, I have not been tracking this closely. My high-level view is that I don't see how you can do that in a way that will make open source still palatable and consumable by businesses, which means it is a non-starter. Maybe there's some more state-of-the-art thinking that I'm not yet familiar with, but I don't see a way that you can codify that into a license, because ethics typically requires judgment. That's a hard thing to capture in a license and something that's very challenging for companies to get behind because of the lack of clarity. A lot of open-source development is happening by developers that are paid to work on open source.

What has GitHub learned from its experiences with employee protests over its work with ICE and with respect to the youtube-dl tool over the last couple of years?

Learning from things like youtube-dl, I think that's a very different case. And I think what we learned from that — we published a great blog post following that — was that, obviously we need to comply with the letter of the law, but we also need to make sure that we have all the support in place for developers when companies come after them for open-source projects, and file these DMCA notices that may not actually be valid, or are maybe solvable with some small fixes.

In terms of your other question, it's something that we'll continue to see across the board. Customers and employees are absolutely within their rights to voice their opinions, and vote with their feet if they're not happy with the decisions that a company is making.

I think what we learned is it's just really important to have a clear set of operating principles about how decisions are made and who you do business with. I think we made that clear to employees: that we are going to continue to do business with the U.S. government in this particular case, but it applies much more broadly beyond that, just making sure that people understand, "these are our views as a company." And we realize that you [the employee] might not always be aligned with those, but these are the decisions that we've made. You can choose to continue working and accept it if you have a different perspective, or find a place that's more aligned with your own views.

The key is really delivering clarity. I think that's the biggest learning: How are you going to operate as a business?

What is your current remote work strategy and how has it evolved over the past year, which obviously has been a disruption like none of us have ever really seen? And then what are your plans going forward as we continue to all try to figure this out?

GitHub was largely remote long before the pandemic, about 80% of the workforce works remotely around the world. Because we do all of our work on GitHub and use it to drive everything that we do, we were very well set up to make the full transition to having everybody working remotely.

We do not expect to require people to come back into the office — with very limited exceptions — over time. I am a very firm believer in hybrid work: I have myself worked either remotely or in a hybrid environment for a decade now. And my view is that if you really want to build a global and truly diverse team, hybrid is the winning strategy.

The reality is working from home most of the time doesn't necessarily work for everyone, right? We have people who live in multigenerational housing in different countries who have just too many distractions, or not enough space; our employees in Japan, they have typically smaller houses and working from their apartments is really challenging for them.

You have people in San Francisco who have really high rent, so they have a lot of roommates. I've been taking calls with people in the bathroom sitting on the floor, because that's the only place they had to go for a call. A lot of those folks want to come back into the office some of the time, they just want that flexibility to choose how and when they do that.

Like everybody else, I think we have learned over the last year and continued to evolve and improve. We expanded our home office reimbursement policy to get people even better setups at home; we already had a pretty robust policy in place, but folks get more now. The other and more important thing is that we're just more deliberate in thinking [about] how to connect people that are working remotely into the company and build belonging, which has been one of the things that companies have been struggling with.

Correction: An earlier version of this story misstated the number of active users. This story was updated on Sept. 17, 2021.