Brandon Keepers is head of open source at GitHub. He believes open source is fundamental to build products. I caught up with Brandon prior to his talk at All Things Open about open source principles for better engineering teams.

I asked him not only about the talk itself, but also about his work at GitHub. Brandon shares some interesting insights into constraints developers face and how they account for these through transparency, participation, and collaboration.

Can you tell us a bit about yourself and how you got involved in open source?

I lead our open source efforts at GitHub, helping make GitHub a better role model, helping companies and communities overcome hurdles in open source, and looking for ways we can amplify the efforts of other communities. I previously worked as an engineer on various parts of GitHub.com, like GitHub Flavored Markdown, notifications, wikis, and other internal tools. Before we were acquired by GitHub in 2011, I was part of the five-person team that built speakerdeck.com, gaug.es, and harmonyapp.com.

Thanks to many great mentors and role models, open source has been critical to my growth as a software developer from the very beginning. I learned to program with open source languages, built applications with open source libraries and frameworks, and fell in love with the open source process as a model for creating great software.

What does it mean to be head of open source at GitHub? What does an average day look like?

GitHub is where most of the world collaborates on open source software. My goal is to ensure we live up to that responsibility. We’ve pulled together a team of people from across the company that aims to bring a comprehensive perspective to our open source efforts. We are especially interested in making it easier to adopt and contribute to open source by lowering barriers for participation, helping communities become more welcoming, and increasing diversity in open source.

You will often find me planning or contributing to projects, writing code to automate processes, meeting with community members to learn more about how GitHub can help them, or preparing for and attending conferences.

You use GitHub to build GitHub. Is that part of understanding and improving the service for its users?

Using GitHub to build GitHub has been a huge advantage and has enabled us to create a platform that is used by over 10 million developers. We also have to constantly be aware of the fact that not everyone works the same. GitHub is used by a very diverse audience; open source projects with a single maintainer, large communities with aligned goals and ambitions, groups with conflicting social constructs, and enterprises with tens of thousands of developers all use GitHub every day. We have to account for the ways our own biases affect what we create. We want to enable developers to build the best software, regardless of how they work or what they look like. To accomplish that, we are building an extremely diverse company, using research to learn more about how people use our product, listening to the feedback we get from customers, and applying what we have learned about how to build great software.

Is it required for engineers at GitHub to understand open source principles? Do they apply those principles to building GitHub?

GitHub was born out of the open source community and it has had an enormous impact on the way our engineering teams work. We strive for transparency in all of our processes, so we learn simply by watching each other work. Whether it’s doing code review on a Pull Request, or deploying changes to a system, or diagnosing an issue in production—it’s all visible to anyone that wants to learn.

We make heavy use of automation wherever possible, mostly via ChatOps through Hubot, our customizable chatroom robot. We use Hubot to deploy code to production, find out where one of our coworkers are located in the world, diagnose errors that happened recently on GitHub.com, or thousands of other things that we do every day. Anyone at the company can write and deploy a script that teaches Hubot new tricks.

All of this is preserved in archives so we can work backwards from an issue or failure and learn how to prevent it in the future. True to open source software itself, we are constantly learning and adapting the way that we work, and then documenting it in prose or code.

Which specific parts, philosophies, and workflows can be used to build better engineering teams?

The open source process has proven adept at producing systems that can be built, maintained, and adapted by many developers around the world. But open source communities have to accept certain constraints: they are distributed geographically and across time zones. They rarely have the luxury of high-fidelity communication such as hallway conversations, face-to-face meetings, or even chat or instant messaging. They account for these “constraints” by changing the way they communicate, which has enormous benefits:

1. Transparency – Not only is open source software freely available for anyone to examine, so is the process by which the code came to be. Communication happens in mediums that allow anyone to subscribe, regardless of role or geography.

2. Participation – A commitment to clarity in both information and process eliminates “tribal knowledge”, creates shared goals, and enables anyone to participate.

3. Collaboration – A system designed to allow anyone to participate naturally leads to massive collaboration.

These principles are backed by tools and workflows that have been proven to produce software that is both adaptable and resilient, whether the software is an entire operating system, a small utility, or an enterprise application.

Any final words you’d like to say about your talk? Maybe some advice to maintainers and contributors on GitHub?

Nearly every piece of software we interact with today uses open source code and workflows at some level. From the programming language and libraries that it is built with, to the servers it is running on, to the network that transfers the data, to the device or web browser used to access it. Open source has become the foundation for modern software development.

In The Success of Open Source, Steve Weber says, “The steam engine was the metal behind the first industrial revolution; but the revolution was a set of ideas about organizing factories, limited liability corporations, trade unions, and daily newspapers.” Software may be the steam engine powering the current technological revolution, but the ideas that shape the open source community will have a much more profound impact than the code it produces.

We become better software developers by observing how some of the best software in the world is being written. Open source has changed and will continue to change the way the world builds software, not only by creating high-quality reusable components, but by giving us a model for how to produce better software. Open source gives us complete transparency into that process.

All Things Open
Speaker Interview

This article is part of the All Things Open Speaker Interview series. All Things Open is a conference exploring open source, open tech, and the open web in the enterprise.