For more M12 news, follow us on Twitter.
Direct Line with Jason Warner, GitHub CTO
Direct Line is a series of interviews with Microsoft execs with an eye toward the startup and VC ecosystem.
Our inaugural Q&A session is with Jason Warner, the Chief Technology Officer of GitHub. Jason filled us in on the software development trends that have his attention, and the framework that he uses to consider if the team should build, buy, or partner.
How is GitHub handling the current shift in work? What technologies are rising in importance to you?
Fortunately, GitHub has always been remote-friendly, so we had a head start in managing the challenges of a distributed team. We use our own platform for async communication, in addition to video conferencing tools for real-time syncs. Stay-at-home orders have definitely been a pressure test, but I’d say that the distributed model of open source was already pandemic-ready.
If I could choose one tool for a time like this, I’d prioritize something to manage institutional memory. Asynchronous communication is critical as co-location is less of a norm, so I’m naturally I’m committing to GitHub, which allows you to write down an issue, lock it, and ratify the decision. You can even show comments to ensure that everyone has the background information they need.
My second priority tool is video. Remote work has created new challenges, particularly around empathy and connection. If you’re ever speaking past a co-worker or partner, jump to video right away to take advantage of the additional, emotional context.
My third priority tool is something like Slack, Microsoft Teams, or an open source alternative like IRC. Quick chats are a great way to push work forward without ideas getting stuck in an inbox. This said, never treat team chat tools as institutional memory. Backscrolling is the worst way to determine context.
What are some interesting technology or software development trends you’re seeing currently or interested in?
The complete overhaul of the entire web definitely has my attention. You have JAMStack taking off and changing everything (again) including applications (Gatsby/React), tooling (Netlify), and cloud infrastructure (Fastly, Cloudflare).
Kubernetes has taken over orchestration, and the resulting ecosystem of tools there looks a lot like the original Linux operating system revolution. All the tools, techniques, and layers of the stack are getting reimagined as companies and products. It’s both fascinating and infuriating to navigate.
I’m also highly anticipating the WASM revolution that’s expected to come out of web applications. Keep an eye on the space.
What is your vision for the future of software development?
At GitHub, we want to provide the underlying, permanent, ‘constantly evolving so you don’t have to’ platform for all software development. We’re committed to making development more accessible, so developers are more productive and informed. Our goal is to make GitHub the core fabric of all software development, so no matter what happens in the future, GitHub is the one tool you never have to change. It’s a big vision, but we’re up for the challenge.
Because of GitHub’s market position (we have over 50 million developers and more than 100 million repositories), we have a big responsibility. If we make a change, it should be meaningful to nearly everybody in the world who cares about software. If it’s a nice-to-have, or a shiny button type of scenario, that is not what we’re after. We’re after something that fundamentally uplevels the developer experience.
Most ideas are friction-reduction opportunity — making an action or engagement easier or less awkward. But that’s not what GitHub is after. We want to totally upend the experience, not focus on a small band-aid issue.
What keeps you up at night?
Security and compliance—that’s what keeps me up at night. Startups take on all kinds of debt: tech debt, process debt. I’m here to say don’t take on security and compliance debt. Move fast, pilot stuff, try stuff — but don’t mess around with customer data, or with your own internal security procedures.
Most software consumes from or feeds into into a large and opaque software supply chain. In most projects, the number of dependencies dwarf the size of code in the project. I’m constantly thinking about how we can make it possible for developers to understand, support, and secure the dependencies and dependents of their code, and stay ahead of the evolving compliance landscape.
What’s your framework for thinking about when to build vs. buy vs. partner?
- Build: Is it core to our strategy? Never outsource or acquire what is core. You must build the experience and muscle yourself.
- Buy: Will this accelerate our roadmap by some amount of time? Does the company in question have unique talent that we don’t? Would we be a better company with their ideas and unique talents?
- Partner: Partnering is 2+ steps removed from our core strategy and is the best approach if we want something for our customers, but don’t think we need to be the direct providers of the experience. Can our partner do a good enough or better job than we could?