Open Source Careers With Brandon Keepers of GitHub
The Director of Open Source at GitHub discusses GitHub's place in the industry, long-term ways of staying engaged in open source, and marvels at Microsoft's 180 on OSS.
Join the DZone community and get the full member experience.Join For Free
At AllThingsOpen in Raleigh, NC, I met with Brandon Keepers, Director of Open Source at GitHub. Just before his talk that day, we sat down outside (in the middle of Raleigh construction, oops!) and discussed how much the tech world has changed thanks to open source software.
Can you speak a bit about your role at GitHub?
I’m head of open source at GitHub, and our team is responsible for a lot of different things. We spend a lot of time looking at a lot of the challenges the community is facing, like what are open source maintainers running into, or what are companies who are using open source running into? How are they using a tool and how can GitHub be a better place for those open source projects? And then we work with customers who are in unique situations, or with projects that are in unique situations and try and figure out how we can help them adapt their workflows to GitHub or vice versa. We’ve also been spending a lot of time focusing on “what are the paths into open source?”, whether it’s people new to coding or people who’ve been coding for a while but haven’t been engaged publicly.
What’s GitHub main interest in learning these things? I assume it’s to drive adoption first and foremost, but how does it contribute to that?
The ultimate goal is that we want to build the best development tools out there, and we think that open source is one of the best ways to build software. The software that comes out of the process is a lot better, the process itself leads to more people being able to get engaged, and there’s transparency so as people are coming in and out of the project, you can see the history. You know why decisions were made and what led to certain events.
We also think open source is going to be a significant part of the future. It’s already become significant. As every company is becoming a tech company, they’re also using open source. So anything we can do to push that standard and make it the default is interesting to us.
Could you please summarize your talk today, “Contributing to Your Career”?
For a lot of people, open source has not only been a great way to build their skills and to gain experience, but also to build a reputation, find community, and get connected with opportunities. So this talk looks a little bit at “what’s the path to doing that?” How do you get engaged in an open source project, and why is it that for so many people it’s such a good career path? Just some general tips and advice on navigating that, with the end goal being that you should always be looking for ways to improve and grow, thinking about how the work you’re doing now becomes a permanent part of your portfolio and your reputation, and someday that will lead you further in your career.
Why do you feel like this is an important topic to speak about?
If you look at some of the companies that are active in open source right now, you’re seeing names that you wouldn’t normally expect. You’re seeing people like Nike, Disney, Walmart, or John Deere. This is further proof that every company is becoming a tech company, and all of that software is built on open source. Developers should to realize that it’s a great time to be a developer and it will be for quite a while, and there are quite a few easy steps you can take as a developer just to build your own skills and lead you to these opportunities. It’s important to them and it’s important to see that in terms of other professional development opportunities, one of the best ones is sitting right in front of them, it’s free, and it’s a very low barrier to entry. That participation in open source can open up doors to any of these companies.
What do you feel is the most exciting thing about open source technology right now?
From a developer’s perspective, you can essentially work anywhere using the tools that you’ve learned. You can use the same tools to build your side project or your work project, and lots of companies use those tools. The best programming language, the best AI framework, the best database, all of those are being released free and open source. You can start to engage with those right now, learn the tools of the trade, and take them to any of these other companies and the tools will be the same. When you step up and take that next great job, you’re not learning a different stack, it’s the same great stack that you’ve been using.
I don’t know that there’s one great opportunity. I think just the fact that if you pick the company that you dream to work at: you can build the skills you need to work there right now with tools that are freely available to use.
What advice would you give someone who wants to start contributing to OSS?
There are lots of different routes, I think everyone who’s in it has taken a different one. But the one that’s been most successful for people long-term is to start looking at the tools that they’re already using, and saying “which of these projects could I contribute to?” One of the bits of advice that’s popular is to find a project that’s welcoming to newcomers, or find a bug that you know how to fix on any random project, and for a lot of people, that’s a path that’s gotten them engaged. But long-term, I think the challenge is that it’s hard to stay engaged when you don’t also want something from the project.
So if you look at the tools you’re using and you say “okay this project or this library or this app does most of what I want, but I actually want a little bit more.” So then you start to engage in the project. It starts with just following it. Just watch it on GitHub and see what activity is happening, maybe you see some common patterns and just slowly start to immerse yourself in the project and see what people are wrestling with, and maybe start to comment and take some actions. You start to see people do that toe dip, then suddenly, weeks or months later, they’re the ones answering questions on the project or they’re identifying problems and proactively fixing them. I think finding tools you’re already using and already familiar with is one of the best paths.
What’s something you feel should be standard practice in the community but isn’t?
There’s a lot of emerging patterns that I think lead to healthy projects, and a lot of those are really simple, like having a readme, having a license, or having a contributing doc. One of the things that’s starting to emerge is having a code of conduct, and a code of conduct is important because it declares that this a project that anyone can participate in, that if there’s bad actors or if there’s situations that go south, here’s the process that you can take to deal with that abuse. Some of those patterns I think are already common, and we’d love to see them become even more common.
I think on the corporate side, there’s still a lot of education to be done around the value of companies in open source. Some of them get it, and some are incredibly strategic, using open source from the beginning and thinking about “how can we build better technology?” I think there are still a lot of companies that see it as a side project or a hobby, and we’re seeing a lot of developers educating middle management. The execs get it, the developers get it, and middle management is still wrestling with “why are the developers spending time on this?” There’s lower cost of ownership, better technology, you get engagement from other developers, that kind of thing.
So is that disconnect an effect of middle managers being told to embrace open source but also having old deliverables that executives are still expecting?
Their responsibility is the immediate efficiency of the team, and so with something like open source, there are tons of gains in quality and down-the-road efficiency, but some of the immediate investments may not always seem obvious. So when your incentive, as a middle manager, is “our team has to hit this deadline” you’re going to make trade-offs.
So what could help solve that cognitive dissonance to make sure the whole company’s on board?
I think it starts with education. I don’t think there’s enough. We’ve seen some pretty crazy transformations like a company like Microsoft, where ten years ago if you had said that their development platform would be entirely open source, Windows 10 would run bash, PowerShell would be open source, they’d be running Linux in the cloud, and they’d be a major contributor to open source, people would’ve thought you were crazy. I think what you saw there is that there had been a swelling for a long time of support amongst developers, and I think Microsoft got it. I think with changes in executive leadership, Satya clearly understood the value of it and some of the other executive leadership did too, from there’s it’s just a matter of helping middle management understand “here’s the value of this.” A lot of it too is tooling and friction. If you’re not set up with tools that help you think about “how do we help these two teams collaborate and share code, and how do we start a project from the beginning with the intent of open sourcing it?”, you’ll have so much working against you. I think we’re seeing it slowly change, but it takes some time.
Opinions expressed by DZone contributors are their own.