Twilio leverages GitHub to strengthen the community behind its developer-first platform.

Twilio CEO and Co-Founder Jeff Lawson started his first company in the 1990s as a student at the University of Michigan, when the Internet was in its infancy. Years later, after stints at StubHub, an extreme sports retailer called NineStar and Amazon Web Services, he found a problem he was viscerally passionate about solving. Lawson set out to reimagine communications through a software lens—and uproot it from its 150-year legacy in hardware. A developer himself, Lawson and his two cofounders built Twilio with and for developers. And even though there wasn’t a “developer” market yet, he launched in 2008 amidst the financial crisis with a small loan from his parents (he and his new wife even returned all their wedding gifts to add to the fund). It was worth it.

Today, Twilio’s cloud communications platform provides more than 170,000 global businesses with the building blocks to add messaging, voice, and video into their web and mobile applications. Twilio’s APIs are cloud-powered, continuously updated, and built to auto-scale to its customers needs, helping clients like Zendesk launch in 40 new countries, Airbnb to power communications between hosts and guests, and Lyft deploy worldwide support in just days. Unsurprisingly, Lawson recognizes that fostering developer creativity is essential to Twilio’s success. “GitHub is a critical service for developers–our community relies on it. So for us, it’s important to have a presence,” said Developer Evangelist Dominik Kundel.

At Twilio, there’s a developer on every team, in every department. “It’s integral for us to walk in our customer’s shoes. Having a developer relations team is important for us to be real and credible and interact with the community,” Kundel said. Every Twilion—no matter their role—is encouraged to build an application within their first week. “This helps everyone speak the same language and it helps Twilions build empathy for our customers.”

Head of Productivity Engineering Roman Scheiter explained their first use of GitHub was “bootstrapped by product engineers who wanted to focus on building Twilio rather than building and maintaining scalable source code management infrastructure.” When he arrived, his team shifted from on-premise hardware in the closet of their San Francisco office to a more operationally mature Enterprise version. Twilio currently leverages both GitHub Enterprise in AWS to host internal source code and in the cloud on GitHub.com for their open source development. “Anyone who’s working on internal product development commits code changes to GitHub as the entry point into our CI/CD processes,” Scheiter said. “GitHub also serves as the collaboration portal for engineers to peer review code changes.”

GitHub is a critical service for developers–our community relies on it. So for us, it’s important to have a presence.

Kundel manages everything on GitHub.com. Currently, he has 250 developers working across various organizations, using GitHub for everything from actual product development to libraries to starter kits and SDKs. Of their open source projects, some are Twilio-specific, like the Flex Plugin Builder, an interface for developing, testing, and releasing a plugin, while others, like SOCless, a serverless framework that helps security teams automate tasks like incident responses, are not. There’s also the Serverless Toolkit, which allows users to locally develop and deploy Twilio Functions in a Serverless environment. More general use case tools like Guardrail, for code generation, originated internally from engineering. Scheiter noted that they leverage “various open source frameworks and libraries to build the Twilio experience.” The team consumes open source more as binaries, often pulling infrastructure through binary repository manager Artifactory rather than forking the code bases.

One of Kundel’s priorities is to find the best way to interact with the developer community, “both in consuming open source ourselves, and how we can contribute in a way that’s sustainable for Twilio and makes sense for the community.” Currently, Twilio is giving various maintainers visibility in the open source ecosystem by publishing their learnings on the Twilio blog.

Recently, Twilio launched an open source project called Open Pixel Art, which is fully run on GitHub Actions. It helps new developers learn how to make their first pull request to GitHub by making a contribution in the shape of a pixel; the program automatically picks GitHub Actions to ensure all tests have passed before the pull request is merged by another tool. “It’s super powerful and certainly something that we’ve seen a lot of internal interest in it,” Kundel explained. This is especially true for enterprise, where the majority of product development is being done on the entry request side.

To build a releasable artifact in Twilio’s broader developer ecosystem, they start with source code iteration, code reviews, and analysis in the GitHub interface. The artifact workflow is then supported by a house-built tool called Admiral, which sits on top of GitHub, Jenkins, Artifactory, and their deployment system. “Admiral serves as a single pane of glass for developers to see the code changes throughout the CI/CD lifecycle. It provides engineers with the ability to build release pipelines to automate the entire process.” When a code change is committed to GitHub, Admiral orchestrates the creation of a release artifact, then triggers deployment and validation, cycling through interactions in both a pre- and production environment. When it comes to incorporating innersource best practices, “Twilio engineers are encouraged to submit pull requests to projects that are not immediately owned by their team. They can then work with the owning team on integrating their change into the code base.” Scheiter said.

Twilio’s Productivity Engineering team recently worked on automating certain SOX compliance requirements that are often tedious to satisfy unless you leverage tooling to codified processes. Conveniently, “we recently enforced code reviews across our entire code base using GitHub’s protected branches,” Scheiter said. “That saved us three months of engineering effort every year that we’d otherwise have to spend code sampling.”

Documentation is a big part of what developers love about Twilio. On top of using an open source tool called Wagtail, Twilio built its own content management system that supports the entire documentation process and includes ways to lift content right from GitHub. “So a lot of the code snippets that you’ll see across the documentation are being pulled from GitHub through the APIs,” Kundel explained.

GitHub has also helped Twilio build more secure code. In addition to code reviews and automated pull request validation process, they’ve integrated BlackDuck and Anchore as scanning technologies for the third party software they leverage. They also integrated SonarQube’s static code analysis with GitHub at the pull request level. This gives them feedback on insecure dependencies within the code. “GitHub’s vulnerability alerts are very useful,” Kundel explained. “Especially as we continue to build a variety of different demo applications, having bots like Dependabot catch vulnerabilities is super helpful.” They also partnered with GitHub to launch Git Guard, a service that helps protect developers from inadvertently committing account tokens.

For Twilio, GitHub is a natural choice for both internal work and open source projects, empowering teams to keep code safe, streamline processes, and stay inspired. “One of the big things is the community aspect. For us as a developer company, being able to learn from each other and build on the shoulders of other giants is powerful,” Kundel said. And in the true spirit of open source, “We are trying to do the same and give back to others and enable them to do the same.”