Facebook’s most popular open source projects like React, GraphQL, and PyTorch thrive and grow thanks to intensive effort by Facebook Open Source. The Open Source website showcases a handful of its hundreds of tools and libraries. It’s also a source for multi-media content for the communities of developers using our tools. Despite the sociable nature of open source, little is known, even internally, about the Open Source Tooling team. Three months ago, I joined this mysterious team, and I am pleased to finally shed some light onto the bustling work taking place behind the scenes of some of Facebook’s most prominent endeavors.
I joined Facebook in May 2021 as a rotational engineer (rEng). Originally from a non-technical background, I taught myself to code using free resources, which I’ve written about in detail on my personal blog. Simply put: open source software forms the backbone of my career. Not only did tutorials, documentation, and source code give me the resources I needed to succeed, but before Facebook, I also worked for a well-known, computational virology lab that produces open source software for scientists.
Needless to say, my mind was set on joining a team producing open source software. During Facebook’s engineer bootcamp, I sought out the singular Open Source team in Seattle with an opening: Open Source Tooling. I fired off my request to connect, leaned back in my chair, and daydreamed about one day releasing new React features for the world to use. When I met the team manager, Paul O’Shannessy, he quickly dismantled my flimsy assumptions, for I would not be working on public facing projects.
Instead, I would mostly be interacting with systems that are inevitably private. My daydream thought bubble burst. Even though it wasn’t what I initially envisioned, I proceeded, still hoping to support Open Source in any way I could. Months later, I am able to share what I’ve learned. Before my transition to software engineering, I worked in several restaurants, so please allow me to metaphorically illustrate the role of the Tooling team within the broader context of Open Source.
The front of the house is the half of a restaurant that directly caters to guests’ needs. The hosts, servers, and bartenders all work to delight and satisfy customers, while the back of the house, i.e. the implementation details, are obscured from view. Open Source Tooling is the back of the house. Like the sous chefs and dish washers invisibly supporting restaurants, we software engineers are working behind the scenes to keep Open Source operating smoothly.
In short, the Tooling team supports Open Source by providing seamless integrations between Facebook’s public and private codebases. While we target our tools towards our primary customers, Open Source Developer Advocates and project maintainers, there are thousands of employees at Facebook, from marketing and recruiting to engineering, who are contributing to open source without even realizing it. This is possible because of our invisible code syncing.
Take a look at React Native, for example. If you look across its 23,000+ commits, you’ll see code written by hundreds of employees, some even without GitHub accounts, facilitated by ShipIt (a Tooling team project). These commits represent automated code syncing between two version control systems (VCS): mercurial (Facebook’s VCS at scale), and git (the canonical, industry VCS used by our public repository hosting site, GitHub). As a result, engineers at Facebook are contributing to Open Source without ever straying away from internal processes thanks to our robust GitHub integrations.
The Tooling team has a long-standing relationship with GitHub. Another way we’re using the GitHub API is to create a self-service portal for our Open Source customers. This tool manages security concerns, triages permissions, and enables our customers to edit project settings or request tokens all from the convenience of an internal dashboard.
Inspired by iOS engineer Mayuko's viral video, “A day in the life of a software engineer,” I present to you a typical day in the life of an Open Source Tooling software engineer working on these internal GitHub repository dashboards.
I log onto my laptop and scratch the sleep dust from my eyes as I wait for my pour-over coffee to finish brewing. The dim, Seattle morning light filters through the window as I check my Workplace messages, e-mail, and the status of my open code reviews. I unblock a teammate’s work by reviewing their code.
I join a Zoom call for the Tooling team’s daily stand-up. Unlike other teams I’ve worked on, the Tooling team uses stand-up as a way to connect on a personal level during the COVID-19 pandemic. Sometimes we discuss work blockers, but we commonly chat about movies, memes, vacations, and other, casual content. We save the serious talk for our weekly team meetings.
I pour a second cup of coffee and dive into my tasks for the day. Task prioritization looks entirely different from the previous two software engineering teams I worked on. There’s no backlog of tasks (well, not in the Agile sense). In fact, our team is not even remotely close to Agile: we have no sprints, no project manager, and no designers. We are only six engineers and our manager, Paul.
How do we identify problems to work on? As a self-directed team, the bulk of our project planning comes from direct user feedback sessions with Open Source projects. We ask our customers questions like “What’s working well for you? What are the gaps we need to bridge?” For example, in a recent session with one of our projects, we learned that they needed additional, automated tooling that required exposing more data in our pipeline. Since we can’t serve every individual Open Source project’s needs, we prioritize feature requests with the biggest impact. Our strong relationships with Open Source teams, Facebook’s culture of fast feedback, and activity in our internal support groups all allow us to engage with Open Source teams and identify and get ahead of trends like GitHub Actions. In essence, our team’s cultural values still align closely with those of the broader, open source software community.
I take my hour-long lunch break and decide whether to make yet another quarantine quesadilla or prepare some routine ramen.
I have two 1:1s every week: one with my rEng mentor and the other with Paul. We discuss my career goals and how I’m fitting into Facebook. Because I’m only on the team for a 6 month rotation, they pitch me projects to choose from. I express my continued interest in UI/UX work, and they ask me to write up a technical proposal and suggested timeline for the features we discuss.
I return to my remaining focus time. I’m currently revamping and adding new features to the UI of the self-service GitHub repository dashboard. I’m writing a lot of front-end code in React, which I used professionally before coming to Facebook. Previously, I always queried REST APIs for my client-facing data needs, but here at Facebook, we primarily pull data from GraphQL APIs. As a full stack software engineer, I’m learning both how to write GraphQL queries and fragments with Relay and how to write back-end GraphQL objects, root calls, and mutations with Hack.
I commit any remaining code changes and write up some notes to help me restart in the morning. I reflect on my progress for the day and consider my next steps on my project.
Thank you for taking the time to learn about the Open Source Tooling team at Facebook. While I don’t know where the rEng program will take me next, I’m grateful to have had this experience and insight into the internal workings of the massive endeavor that is Facebook Open Source. The next time you use one of Facebook’s open source tools, I hope you picture a team of internal engineers persevering in the background, moving Facebook forward commit by commit.
If you are interested in a career as a rotational engineer at Facebook, the Facebook Rotational Engineering Program will be happy to hear from you! To explore other opportunities here, don’t miss the Facebook career portal.