The Changelog: Software Development, Open Source - Open Source at Facebook (Interview)

Episode Date: July 15, 2016

James Pearce, Head of Open Source at Facebook, joined the show to talk about that very subject — open source at Facebook, his path to software development, why he's the person to lead open source at Facebook, their view on open source, their culture of open source, how they choose what to open source, and more importantly — how they focus on, support, and nurture the community.

I'm James Pierce, and you're listening to The Change Log. Welcome back, everyone. This is The Change Log, and I'm your host, Adam Stachowiak. This is episode 211, and today, Jared and I have a big show for you, Open Source at Facebook with James Pierce. This is a big show because we go so far back. We went back to the dorm room with Mark. Choosing open source for what to build upon. The LAMP stack, of course, as you all know. We talked about their open source, 180 repos, give or take on GitHub.

We talked about the way they model their open source, the way they choose what to open source, the way they nurture and support their open source, but more importantly, how they look at community and how they're building community around open source. We have three sponsors today, TopTile, Linode, and Compose. Our first sponsor of the show is our friends at TopTile, the best place to work as a freelance software developer. If you're freelancing right now and you're looking for ways to work with top clients, work on things that are challenging you,

interesting to you, technologies you want to use, TopTile is definitely the place for you. Top companies rely upon TopTile freelancers every single day for their most mission-critical projects. And at TopTile, you'll be part of a worldwide community of engineers and designers. They have a huge Slack community, very much like family. You'll be able to travel, blog on the TopTile engineering blog and design blog, apply for open source grants head to top dot com to learn more that's t-o-p-t-a-l.com to learn more or email me adam at changelog.com if you prefer a more personal introduction to our friends All right, we're here with James Pierce. Jared, I mean, this is a big show, open source at large of Facebook. We've obviously talked about React. We've talked about HHVM.

We've talked about hip hop. We've talked about all sorts of things over these years, but never truly about open source at large. What do you think? Yeah, it's time to get the big picture. This is, I guess, the fourth time we've had a show with somebody from Facebook. And now we have James Pierce, who is in charge of all of it. He's the one who looks after all the open source projects

so we can kind of see not just a specific project, but all the stuff that's going on. And as you well know, Adam, Facebook's putting out so much open source these days. We say open source is hard to keep up with, but even just open source at Facebook is hard to keep up. Right. It is. It is.

It is. James, what's your official title? Well, firstly, thanks very much for having me on the show. Yeah, I'm just, I guess, head of open source. I'm responsible for running the team that puts the new launches together and makes sure that we do a good job of looking after the projects that are already out there and a variety of other things, which I'm sure we'll get to talk about. It's a pleasure to be on the show.

At what point did Facebook identify the need for a head of open source? We want to go into your backstory here in just a second. So for the listeners who listen to the show all the time, we're getting there. But I'm just kind of curious at what point they say, well, you know what? We really care about open source so much. Let's put someone in charge. That's a very good question. So there is a story which actually predates me.

I believe back in the day, David Recorden joined you for one of your earlier podcasts. And David really kicked off the open source program at Facebook 2009, 2010 kind of era, I would think. And at that time, we had one or two interesting projects that we had worked on. And I think David was a real advocate for keeping things in the open. He'd worked on OAuth and various other standards himself. And we open sourced projects like Cassandra, projects like Tornado, projects like 320 for iOS, and really started to get the ball rolling in terms of giving engineers at Facebook the opportunity to share the projects they had worked on. As you might imagine, the program grew over the subsequent years. David moved on to

other things. And unfortunately, what happened is that a number of the projects that we had launched sort of fell into disrepair. And I can talk about this a fair amount in terms of what we've learned from that. But a number of those early projects, the internal engineering teams either lost interest in the open source versions or they stopped using them in production. And things fell into disrepair a little bit. And so in 2013, we made a decision to reboot the program in a sense and tidy up the portfolio, figure out which projects we were still prepared to support and get behind, which ones we weren't interested in, or at least ones that we weren't able to support anymore. Yeah, we basically tried to get things back in order.

And I took on responsibility for that. But I will just say one thing that's interesting here is that at Facebook, there is never really a sort of a top-down mandate to go and do things. No one declared, you know, open source needs to be fixed. We'll find someone to put on it. It was very much a group of individuals identifying that this was something we weren't doing as good a job of as we had done in the past, and we just needed to go and fix it. And so I jumped in, kind of raised my hand, volunteered, and got things going again. And three years on, almost exactly to the day, three years on, we've obviously got a pretty healthy ecosystem of projects.

React has obviously been a flagship project that's risen through the ranks over that three-year period, plus a whole bunch of other projects, many of which I will get a chance to talk about today. It sounds like you were, based on that, it sounds like you were really responsible for the reboot process and building the team and kind of bolstering up what was kind of already there and throwing away things that didn't need to be there anymore or be supported, as you said.

So you seem to be the one to speak to, obviously, about open source at Facebook then. I hope so. I do now have a team of folks that help me. I want to stress that I'm not doing this alone by any means. So we have a small team that helps with the tooling. A lot of the success of the open source program at Facebook, we attribute to having tools that make it easier for engineers throughout the company of the open source program at Facebook, we attribute to

having tools that make it easier for engineers throughout the company to just do the right thing anyway, with regards to open source. And we also have a team of people who manage the releases of new projects and work with teams to continue to ensure rich community interactions and make sure these projects go on to become more successful. So yeah, we have a very small centralized team. I think it's important to stress that we don't try to gather the engineering for each and every project into one place. So the React team is in one part of the organization and the HHVM team is in another part of the organization. And we really try to match the engineering teams up with their communities and kind of give them the tools

and give them the best practices and the guidance for them to run those projects themselves. We really wanted to create that impression or, in fact, that reality that, you know, engineers at Facebook are working directly with engineers in the community rather than trying to centralize some kind of central developer advocacy kind of function. You know, as a buffer, we really wanted to, you know, make this a direct connection between engineers internally and externally. Cool. I see about 353 people in your Facebook organization on GitHub. Can you give us an idea, just a context around that,

as far as the total number of engineers at Facebook and how many, like a percentage wise touch open source on a regular basis? One of the metrics we track very actively is how many engineers throughout the company have touched GitHub repos either directly or indirectly, which is something I can talk about as well. But, you know, it's well over a thousand in a given six month period engineers throughout Facebook who are contributing to one of our 350 projects or so. So it's really a core part of our culture. This is not some little off-to-the-side thing that a few crazy people do.

It's very much key to the way that we think about software, especially in the infrastructure side of the business where we're working on tools and frameworks and platforms that enable product engineers inside Facebook. A lot of those are really, really excellent open source candidates. And that's very much part of the culture. I should also stress, it's not just software. I mean, we also have open sourced many of the designs to our hardware and our networking and storage systems, let alone data centers themselves. So we've tried to weave that open source philosophy, narrative, if you like,

into other parts of the business as well, which has been extremely successful for us through the Open Compute Project and other things. It seems like that story is told a little less, though, the hardware side. I know we're all familiar with React and some of the recent success in terms of that platform and what it's done for you. But I've definitely known about some of your data center efforts and hardware efforts. And that's always interesting. I wonder, you know, maybe why that seems to me, maybe just me in particular, why that seems like more of a backstory than a front story, like the software side. I don't think we've been reticent about telling that story. It's really been a huge success for us as a business as we build out these data centers that we need to, obviously to support Facebook for the billion and a half people that would like to use it. We need to have large data centers across the world with many, many servers, you know, a huge amount of storage and networking. And, you know, quite honestly, the idea of open sourcing our designs there has really helped accelerate the pace of innovation throughout that sort of ecosystem.

It's helped us to iterate quickly. And we know that many other companies in the industry from, you know, Microsoft now through to Google and, you know, many other hardware partners have been involved with the Open Compute Project to, we think, you know, a huge amount of success industry-wide in terms of driving the pace of innovation, driving down the costs of much of this hardware, which we think benefits, you know, technology industry as a whole. Another facet of Facebook open source beyond the software and the hardware is you're also doing a little bit now in Facebook research, which I think it just hit our radar maybe a month or so ago,

Dark Forest, which is a game, a go game engine powered by deep learning and developed at Facebook AI research. So that's also out there in the open source ether. Is this a new initiative for you guys in terms of open sourcing some of the AI initiatives? There's probably two questions there. One is just the research work that we do in general is always something that we've been very keen to share. The work that we do on research is often very overlapping with, you know, the academic community where you go and speak at academic conferences

and write papers. And true to the scientific process, we want to make sure that others are able to reproduce the results that we're proposing or suggesting in papers. And so a lot of our open source projects historically in that area have been the data sets or the tooling required to basically articulate what we've achieved in those papers so that other people can go and reproduce it.

More recently, a lot of that focus has obviously moved to machine learning. And we pride ourselves on a strong research heritage in our machine learning teams in New York and in Menlo Park and I think now in Paris. And again, true to the academic community's expectations, we want to share as much of that research as possible as we do it. We are privileged, obviously, to be able to put resources into working on machine learning. And it's clearly an area where there is still a huge amount to be done. And it just comes back to this underlying philosophy for why we do open source at all. We feel that the more people have access to this kind of work, the more people that can reproduce it and reuse it and tweak and augment it, the more that we can help the industry as a whole move forward.

And I think it's really interesting that in machine learning in particular, we're seeing Google doing the same kind of thing. We're seeing Amazon doing the same kind of thing. We're seeing Microsoft doing the same kind of thing. We're seeing Amazon doing the same kind of thing. We're seeing Microsoft doing the same kind of thing. And I think it's a beautiful example of where we don't consider any of this to necessarily be a competitive environment. In fact, we think that together we can move thinking and the industry forward at a faster pace. And I think it's very exciting to see

on the github accounts of all of those four companies that the number of machine learning projects that have come uh come to light um and which build on top of each other as well i think absolutely yeah there's been like a cambrian explosion in the last few months of machine earning type of projects popping up on all the big tech companies, open source projects. So that's awesome. I love the collaboration. I always think of all the wasted time and money

that goes in when there's competition. A specific example is like Google Maps and Apple Maps. And there's other mapping companies as well, but both of those companies pouring so much into maps that could be a common base. It seems like a waste of resources, so great to see all of the collaboration and even a little bit of competition. Look what we're doing. Look what you're doing. You can gather ideas and see who's doing what. I think that's all healthy stuff, But I think we got a little bit further than we wanted to.

That's great. It was all interesting. Let's back up for just a little bit, James. And let's learn a little bit more about you because we like to get people's origin stories. We think it's very inspiring and can be insightful to find out, you know, how people got where they are.

So here you are. You're heading up open source at Facebook. And we want to find out how come you're the person that's doing that, not just because you were around three years ago and you were involved, but how'd you originally get in the game? That's actually a very interesting question. I've worked in the software industry for pretty much all of my career. And actually, this was not intentional necessarily, but when I look back at my career, I can see that the common thread going through it

has been my desire to work with other developers. So I've had a bunch of experience working on sort of developer advocacy kind of work at startups. I used to work for a JavaScript HTML5 framework company called Censure back in the day. And we worked on things like Censure Touch. And prior to that, I worked on mobile internet, as we called it back in the day, startups around the sort of WAP and the early mobile web technologies.

And again, I really, I think when I look at it, I always saw that the most leveraged way that I could share what I worked on is to help in any small way I can to give other developers the tools that they maybe not need, but could use to be successful. I would also surprisingly not characterize myself as having been an open source ideologue throughout my career. I've worked with a variety of different platforms over the years, and open source hasn't always been top of my mind. But at this point, I think it's difficult to think of software without thinking about open source. So it's kind of like a de facto position. I wouldn't characterize myself as an early open source warrior. You know, it's always seemed pretty obvious to me. And I guess I'm very...

Go back in your life and tell us, like, I think about my first interaction with open source software. And it's probably like Linux, maybe WordPress or Apache. And it was very, it was almost native to me as well. Like I didn't know life outside of it. How about yourself? Like give us early software experience or early open source experience. What got its hooks into you? I don't know whether I need to kind of open up my Pandora's box of historical facts. Crack it open, man.

Oh, for the longest time, I was a Microsoft.NET developer back in the day. So the early 2000s, you know, I was all about C Sharp and ASP.NET. And, you know, quite honestly, it was pretty amazing back in the day. And then I think my epiphany was, probably like you, was WordPress and PHP. And honestly,

if I remember that era, which I think, yeah, 2005, 2006 kind of time, quite honestly, the tooling was pretty miserable for me, having come from a very polished kind of tooling environment. That was one thing Microsoft did really well, you know, developer tools were pretty phenomenal even back then. Uh, and you know, suddenly going to something like PHP and Linux and MySQL, I mean, that was a big eye opener for me. Um, because on one hand the tools were just not there. It was extremely frustrating to get things done, but the epiphany was that, wait a minute, if something isn't the way I want it, I can go down and change it. Maybe not all the way

down to the kernel, but I can dive into the depths of WordPress and make it do what I need to do. Whereas I could never have dived into the depths of the.NET framework to change it, to get it to do what I needed to do. And so I realized that it was worth taking the hit in terms of the tooling that was available in order to have a little bit more power over what I wanted to do in the level below me in the stack. And honestly, ever since then, I think one of the things I've tried to remember is just how good tools can be and see how much more I can bring that philosophy of good tooling to, to the open source world as well. Because I think even now,

a lot of the tools that people settle for in the open source world are, are not as good as, uh, you know, some of those things were back in the, in the mid. And that's why I've been very excited to see things like Microsoft's shift towards open source ecosystems, things like Visual Studio Code. That's really exciting because I know they know how to do amazing tools. And if they can bring those to open source, that'll be great. That's why I've worked on things like Facebook's own Nuclide project, which is our IDE platform that we use here at Facebook. Because again, I'd love to be able to bring some of those IDE expectations to the open source world in the same way that proprietary platforms in the past have done. And we're getting there. Honestly, we're getting there.

There's some pretty exciting stuff going on right now in the tooling space. And yeah, I guess that's what gets me excited. That's what gets me to come to work today, knowing that I can help produce these exciting projects or shepherd these exciting projects, as well as build that layer of tooling on top of them. I love that. I feel like we've got some insight there,

recent history, kind of your early history in your career. Take us back. Let's just pop the stack and go one level deeper into Pandora's box and take us to, you know, childhood or first impressions with software. You know, when was your introduction into coding? And then we'll get that and then we'll take our first break. Oh, my goodness. So we're talking about a different century now, I'm afraid. Back in the 20th century, when I was a young boy, I was, in fact, I know the date

exactly. I know the date exactly. And the reason is that my grandparents decided that they wanted to buy me a gift to celebrate Charles and Diana's royal wedding in the UK. So I know it was the summer of 1981. And my grandparents wanted to buy me a silver spoon to commemorate the royal wedding. And my parents very fortunately suggested to my grandparents that this was not the best thing to buy a young boy. And that perhaps they might invest that same amount of money in a simple computer to see what i would make of it and at the time there was really only one uh in the uk which uh fit that bill which was a sinclair zx81 and i'm not sure whether the zx81 ever made it to the us but hopefully some of your international listeners will remember the the sinclair zx81 and spectrum

with uh with some fondness i certainly do and uh this was wonderful it was this tiny little black box you wired it up to your tv you had a cassette tape uh for loading and saving and uh 1k of memory was all you got and no games no apps nothing uh and if you wanted to use this computer for anything you basically had to type it in which either meant going to your local newsagents and buying a magazine from which you typed several hundred form of basic at the time, and started writing games just to get this box to do something. And so from a very early age, I kind of got the bug for programming and have always since then had this assumption that if I've got a computer in front of me, I basically need to be able to tell it what to do at that level of control. And I guess the passion for programming has stuck with me ever since. It was a formative part of my education, both in and outside school. And I guess I need to thank my grandparents in 1981 for

deciding not to buy me a silver spoon, but to buy me a little black plastic box containing a Z80 chip from which the rest of my career has derived. Definitely a fun story going back. I mean, why have a memento when you can have a future, right? I mean, that's what it seems to be is what I take away from that story in terms of how you got into programming, into computers and what a fun history. Let's take a quick break. And when we come back, we'll dive much deeper into the history and the story of open source at Facebook. We'll be right back.

We're excited to introduce our new sponsor, Compose. Production ready, cloud hosted databases. Pick your flavor, MongoDB, Elasticsearch, RethinkDB, Redis, Postgres, etcd, or RabbitMQ, and our listeners get 60 days for free on Compose. That's 30 extra days to scratch an itch and try a database you've always wanted to try. That's 60 days to migrate from that single-noded database you know you should be running to a three-node, highly available, backups included deployment so you can sleep better at night. It would take you longer to brew a cappuccino than it would to deploy a three node highly available failover

ready backups included auto scaling database on Compose. And for the price of about four cappuccinos you get all that with one gig of storage per month. For some databases the price climbs as high as six or seven espresso drinks which is still minuscule. And right now Compose is offering a limited edition free rethink db shirt for anyone who tries that particular database though of course with 60 days you can deploy them all totally for free learn more at compose.com and when you're ready sign up using our special url compose.com slash changelog to get 60 days free on Compose. All right, we're back with James Pierce of Facebook.

As a matter of fact, head of open source at Facebook, which, Jared, as we said earlier in the show, that's not a small thing. 180 repos on GitHub that we're actually able to track. It's public, or at least publicized right now. Roughly, yeah. Roughly 180, but React, HHVM, Hip Hop Virtual Machine, which is what that is, obviously.

Hack, so much fun stuff coming out of Facebook. James, I think the real question is, you kind of teased it a little bit earlier, obviously, with the reboot back in 2013 and your presence there, but why is Facebook interested in open source? And that's really where it comes from. Obviously we have David's earlier work in it and then you're helping to reboot it, but why Facebook? Not just you, but why Facebook?

So there are three or four answers to this question actually. And I think if we have the time, I'll run quickly through all of them. Yeah. It's of course important to remember that Facebook itself was built on open source technology right from the start. If you can picture day zero of Facebook.com or probably the Facebook.com as it was back then, Mark is sitting down in his bedroom and he's trying to figure out how to build this thing. I think he probably only had two choices. As I was mentioning earlier, the Microsoft stack was probably an option if he was prepared to spend some money, or the other alternative was a LAMP stack. And I'm going to guess on behalf of Mark that

the latter was far more dorm room friendly. And the idea that it wasn't going to cost anything, the idea that if it was successful, it might be something he could scale out more efficiently, plus a stack that if there was anything that didn't work for him, he could dive in and help augment. And so right from that first day, the first line of PHP, the first insert command into the MySQL database, it's been open source ever since then. And so we have this kind of deep obligation to share back the improvements that we've made to projects that we've used ever since. And now that we have a slightly larger engineering organization than just one individual in a bedroom, we are able to produce new projects of our own that we want to share back. So there's that real strong sense of wanting to stand on the

shoulders of giants and then give back in turn so that others can help develop their next great ideas and help accelerate their innovation on top of what we have built. So that's definitely a strong part of our ethos here. The second thing is that I think openness is just such a core part of the Facebook culture that it would be crazy if we weren't open sourcing a whole bunch of our software. So our company mission is to make the world more open and connected. And I think we think that applies to the art of software development just as much as it does to the tools and the products that we provide to support people around the world connecting on Facebook itself. And we see that open source is kind of this conversation that can happen through code, and we're allowing individuals around the world to connect via these projects,

work on things that they feel passionate about, and it's just, in a sense, another layer to the sort of mission that we're trying to achieve at the company as a whole. So definitely well aligned with our mission, very well aligned with our culture. The third thing is that, and this is kind of an interesting one, it turns out it means we write better software if we know we're going to be open sourcing it. And that is extremely demonstrable. So we've had many projects in the past where we've tried to open source them retrospectively, where it's something that we think is valuable that we've realized we've built in our infrastructure.

And we try to tease it out and we have to try to drag all these tendrils of dependencies out from other parts of the Facebook internal stack in order to get it ready for open sourcing. And that's such, you know, that's such a hard thing to do. I mean, we have done it many times, but those projects where we know we're going to open source it right from the start, where the team sits down and figures out, how are we going to package this system or this project in a way that's going to be easily shareable later on? You know, those projects are just so much better architecturally. They have much cleaner APIs. They're going to be much more modular. They've got much better documentation.

They've got a much easier installation process. And, you know, we do all of that because we know that it's going to make it that much easier to push it out onto GitHub when we're ready. And so the more that the open source philosophy bleeds out through the engineering organization as a whole, the better the systems we're building in the first place actually are. And slightly ironically, the fact that we've open sourced a project increases the chances that it will get adopted internally too. So we'll have a team that builds some piece of infrastructure

and it's obviously beneficial for that to be used throughout the company. We're a pretty large company at this point. And so having a system that's, you know, really easy to install, nicely modular, sits on GitHub, easy to contribute to actually increases the chances that it'll be used elsewhere inside the company, let alone outside. So that has actually been kind of an unexpected benefit of what we've done here. That is surprising. It's like the same social proof that works with strangers or with outsiders also works internally amongst engineers. That's interesting. Yeah, and we've seen, so we have some metrics internally where we can gauge how much people are using different projects just on internal systems. And you can see we'll have an event like ReactJSConf

or we'll go and speak at a conference like F8 or some other industry conference. And you'll see the bump in internal usage after we've gone and spoken about something at an external conference. It's amusing or maybe a little sad, but it's interesting that the company has now reached a level at which we need to do that advocacy both inside and outside the company and making a project open

from the start makes it much easier to do that. I have a colleague who has this great quote. He says open source is like the breeze from an open window. You know, basically if you know that you're going to be opening up your kimono and sharing all this work with the rest of the world, it's going to have to be excellent quality. And that has benefited us very much over the last few years. And then I think finally, the sort of unspoken benefit of doing open source is that it really gives us a chance to show

other people the sorts of problems we're having to solve. And I think if we had never open sourced anything, then other engineers around the world, other communities wouldn't really be able to comprehend the kind of scale at which we operate. They wouldn't be able to comprehend the sorts of systems we have to build. They wouldn't have a chance to comprehend how we think about performance or scaling out databases or building infrastructure that can be reused across large numbers of products. And actually, open source is a good chance for us to say, look, these are solutions to

the problems we have. And the community, by the way, doesn't always quite understand that at first. And we have that opportunity to tell the story. Why did we do it like this? Well, there's a story behind that. We figured out that at the scale we're operating or with the number of transactions we're having to deal with or with the of those problems. And, you know, clearly there is a benefit to our engineering brand as a whole and to the recruiting opportunities to encourage others that might be interested to come and join us. Yeah. I was going to ask you, I was waiting for that one.

I figured like, cause that's your fourth point there. It's in your DNA. It's part of your mission. You write better software. And then the one that I thought was kind of the most, I don't know, I guess if you think about the most capitalistic or the most obviously beneficial is like there's so many engineers, you have so many needs, and you want people to come work at Facebook and people like to see the hard problems being solved. They like to be involved in those things. And so open source is a great way of going about that.

We saw that firsthand with Dan Abramov when he came on the show. I think he was, that was his first week. He was actually training in London and that was his process to get hired at Facebook was the similar model, you know, the effects of what he's talking about. Yeah. We actually, every six months ask the new engineers at Facebook how aware they were of our various projects and the program as a whole. And we're obviously keen to make sure that as many people are aware of the projects we're

working on. And so that number, fortunately, is pretty healthy and it continues to go up. But the interesting fact is the number of people who join the company able to use those skills that they've worked on before they joined the company is really high. So yeah, people like Dan or Seth McKenzie, they can come into Facebook and they can immediately be impactful because they are already extremely familiar with these tools and this ecosystem. And if we contrast that with a new engineer who comes into the company and is confronted with this wall of proprietary technology they've never seen before, it's going to take them an awfully long time to ramp up and be effective. And at the speed at

which we're growing and the speed at which we're bringing new engineers onto our different teams, the ability for people to be productive and efficient as early as possible clearly has a big benefit for us. I'm kind of curious about process. You release so much open source, especially now, and you're involved in so much open source, especially now. If you've come up with a way, as you said before,

like releasing something as open source makes the software better for many reasons. I'm just wondering if there's some sort of secret sauce, some sort of process, some sort of boilerplate way of doing things, whether it's like community related or documentation related or doing things in certain ways. Is there some sort of process that you've come up with over these years that is somewhat shareable here? So we have tried to avoid forcing different teams to run their projects in certain ways. As I said, what we're really trying to do is federate the activity on these different projects to the teams themselves.

And so if the React team decides to run their project in a certain way and have a certain sort of interaction with their community and a certain sort of governance around pull requests and so forth, then in a sense that's their prerogative. And if a different team wants to do it a different way, then that's also fine. What we as an open source team have tried to do is distill down the patterns that appear to work well

and just share those best practices between the different teams. And evidently teams like React and React Native and HHVM have been extremely successful. And so a lot of new projects will simply say, look, we'll emulate the React team because basically whatever they're doing seems to be working. And then we sort of get this institutional set of best practices to build up. That's not always true, by the way. There are certain communities that expect to interact with projects in different ways, both geographically there are some differences in the way we run those versus HHVM, for example, or maybe some of our C++ projects. But I think philosophically, we want to give each team the leeway to do what's right for their community and right for their project.

Now, on top of that, there's a certain amount of tooling that we think we can provide to make those best practices easier to enact. And that's something that I think we're pretty proud of. We've worked hard to develop out tools which just allow engineers to do the right things when they're working on their projects by default. I'm happy to drill into some of those as well, because that's kind of an interesting topic all to itself. I'm kind of curious that you mentioned React. Obviously, it's well-known, but for those out there listening to this that may not exactly know what to emulate about React, what's successful about it, what do you know? What don't the rest of the listeners know about React and the way it's developed and the way the teams form around it and the way it's open source

and the way the community operates and the way the teams form around it and the way it's open source and the way the community operates and the conference and various things that make it successful? What are those attributes to you? Right, yeah. To emulate at least, you know, if you're following that as an example. I can't guarantee that I know exactly what the magic source is, but there are, again, three or four things that have worked really well for that particular project.

So the first thing to point out is that when we announced it, which I think was probably May of 2013 or so, so about the same time we were rebooting the program as a whole, coincidentally, when Tom Aquino and Jordan Walk stood up at JSConf and started talking about React, quite honestly, the JavaScript community had something of an allergic reaction. I think it did not go down well. People didn't really understand what we were trying to do, why we had chosen the particular syntax to solve it that we had. It was so unconventional in terms of the MVC patterns that were pretty much established at that time that to be perfectly honest,

for the first six months, it didn't look like React was going to be successful as an open source project at all. It didn't seem to have some success for a couple of years. It seemed like it was just, you know, like any other project out there that it didn't have much steam right away. It seemed to really build momentum over its years. Yes.

And I think there were plenty of skeptics who called us out on it. And quite honestly, it was our first JavaScript project for a while. And so we didn't even have a track record of knowing what we were doing. But you know what? We knew it was going to be successful. And internally, the reason we knew that is because it had been a long time coming. This was not something that we had just dreamt up overnight in order to talk about at JSConf. This was a JavaScript platform that we already were using throughout the Facebook suite or the Facebook products and websites. And so we knew that it was solving the problems that we needed. This was not just

some academic exercise to see whether you could build, you know, angle bracket templating into JavaScript. You know, this was a system which we had already used, deployed internally and advocated successfully to hundreds of engineers with. And we knew it was solving real problems that we had. So we knew that ultimately people would realize that, you know, based on the boundary conditions we had, you know, this was the best solution. Uh, it's obviously not necessarily going to be the solution for every problem, but for the problems we had, it was, it was the right thing. Um, and so we were pretty, pretty sure that, you know, eventually it would find a, a, a

role to play in the world. Uh, even if it was a somewhat niche one, we felt there was a role for role to play in the world, even if it was a somewhat niche one. We felt there was a role for it to play in the world. And we just needed to get over that initial skepticism, I think, because it just looked so foreign compared to everything else that was out there at that time. So we kept on working on it. And I guess this is the second thing that I think we did well with React.

And this was trying to find that inner circle of external developers who somehow got it and could be the advocates on our behalf for React. Because someone at Facebook can talk about React forever, but there is never that validation until someone outside the company sort of starts to rally to that cause. And we actually put in place a number of kind of ideas to help get that inner flywheel spinning. And one of the things I think React team projects that people were working on that worked with React. And one, that creates this sense of community forming. Two, it gave these individuals a kind of a brand that they could start capitalizing on. And three, it encouraged them to go out and re-advocate for this project. And yeah, you just

patiently wait for that inner ring to become the next ring out. And that then becomes the next ring out and the next ring out. And eventually you've kind of hit this critical mass as a runaway kind of adoption of this thing. And before you know it, even the skeptics have taken another look and figured out that, well, perhaps they judged it too quickly the first time. But I would definitely credit that idea of a community roundup as being pivotal to React's early success. And then I think another thing that has worked very well for us on React is that we are rigorously using the same version on Facebook products, all the Facebook products pretty much at this point, as we have on GitHub.

So you are not looking at an old fork of a version that we're using internally. You're not looking at a monthly code dump from us. Basically, what you are looking at is the same version of React that we're using on facebook.com. We use pretty much master. So if you view source on facebook.com and you look at the version of the library, it's going to be exactly the same thing that everybody else is using. And that has been critical for a number of reasons. One, it means that you can see us

working on it actively. You don't have any doubts that it's being neglected. You're seeing the commits coming in minute by minute as they happen. And two, it means that we're not going to be breaking compatibility too brutally when we go from one version to the next, because we ourselves would have to go through that same pain. And whilst we can do some kind of nice code mods internally, we're always aware of the fact that we don't want to break the APIs too dramatically. And so now React has this really nice kind of phased deprecation process from odd to even versions of React that has meant that the community can come along with us as we develop the framework. And without naming names, there are other projects out there where the companies that back them don't always get to use them as first-party libraries themselves,

and so they don't necessarily appreciate the pain that the community is going through when breaking changes or whatever are made. So I think that's been critical, and that's definitely something we've tried to echo with many of our other projects, keep the source of truth internally and externally as close as possible to each other so that the community can, one, follow along with what we're doing, and two, feel confident that we're going to continue to maintain it and not break it too brutally from one version to the next. One quick question before the break about the kind of problems that you guys solve at Facebook and how that affects the open source community at large. Your problems are big, you know, the quote unquote web scale, you have billions of users, you have a huge code base with a legacy and a history behind it. And so you come up with solutions

that apply to those problems. You also have a huge splash in the open source community whenever you release something, especially after React's success. The solutions to these big problems don't always scale down to smaller problems like a small website or app or an engineering team of two or a website that doesn't get that much traffic. And yet when you make the big splash, there's kind of a cargo cult mentality. Facebook released it. It must be good. Facebook released it. It must be for me. And so you have a lot of developers who are just like hopping on the bandwagon, perhaps grabbing tools that don't necessarily solve their problems have the solutions for every problem. And, you know, I think we work quite hard, whether it's at tech talks or in documentation, you know, to talk about when a particular thing that we developed is appropriate. And I guess we perhaps implicitly talk about when it's not relevant. But I think the more acute example of this

impedance mismatch is when the community starts to want to see certain items on a roadmap for a project that really are just not going to fall in any of our plans because they're not relevant to us. So that's actually more of a kind of a dilemma. So we have a project called RocksDB, for example, which is a pretty amazing project. It's a key value store designed for kind of flash storage, which is extremely useful for us and I can imagine not always useful for other people. But one of the things that I saw happen in that community quite early on was that there

was a whole set of APIs and bindings that started getting built by the community to connect this key value store system into Python, into Ruby, into Rust. We would get issues coming in on the GitHub project saying, please do a Ruby binding for RocksDB. I mean, I'm sorry, we're not going to build that. And the reason is that we don't use Ruby at Facebook. And I'm not really sure anyone at Facebook could reasonably write that kind of Ruby anyway. And sorry, without being rude, we're not a professional services company that's

just going to be here writing the software that the community needs. And so we've really got to be clear about what is on our roadmap and what is not. And if it's not, it doesn't matter. You know, it doesn't mean it's not going to get done by the community. It doesn't mean we're not going to accept the pull requests. But the dilemma is that, you know, someone then goes and writes the Ruby binding and they put it in as a pull request and we accept it. And now it's sitting on a Facebook, uh, repo, uh, you know, what implicit warranty are we making about that, uh, about that binding that, that actually isn't

something that we ourselves use. We can't guarantee that it's not going to break from version to version. Um, and so that, yeah, that's always a, I mean, we have to deal with these on a case by case basis, obviously, but that's often a thing that we find because the one thing we're absolutely adamant about is, you know, avoiding the need to ever fork these projects internally. We really, really want to make sure that the version on GitHub is the same as the version that we're using, you know, figuring out the APIs and the ways that we can allow these other bindings or other projects to interact

with these things is super critical to allowing the community to iterate on what they need whilst not necessarily distracting us from what we need and not ever leaving us in a situation where we're supporting

something that actually we didn't write and we can't even validate does what it's supposed to do. So that is just a constant ongoing governance question that I think we have to deal with. But it's a pretty interesting one. And I guess just to kind of round out that thought, at some point, these projects eventually become bigger than just Facebook alone. At some point, projects need to graduate to some kind of bigger governance model or some kind of more community-led model and that's also something we're looking at very aggressively on a project by

project basis looking to see when the community involvement is overtaking our own and then think about how to do that in a responsible way so that it goes on to become even more successful beyond our own walls. So that is, you know, that's a whole like lifecycle story for open source projects that we're having to figure out as we go along, quite honestly. But, you know, it's a pretty exciting thing to think about for the future. All right. We are hitting up against our next break. Up next, we've talked about some of the stuff that Facebook has open source.

We've talked about some of the processes or non-processes around the management of those communities. We're going to talk about what you open source and how you decide what to open source and what to not open source. And are there gatekeepers to such decisions? We'll be right back. If you're looking for one of the most fastest, efficient SSD cloud servers on the market, look no further than our friends at Linode. You can get a Linode cloud server up and running in seconds with your choice of Linux distro, resources, and node location. And they've got eight data centers spread across the entire world. North America, Europe, Asia Pacific, and plans start at just 10 bucks a month with hourly billing.

Get forward access for more control, run VMs, run containers, run your own private Git server, enjoy native SSD cloud storage, 40 gigabit network, Intel E5 processors. Use the code changelog20 with unlimited uses. Tell your friends it expires later this year so you have plenty of time to use it. Again, use the code changelog20. Head to linode.com slash changelog. So we're back with James Pierce talking about all things open source at Facebook. And it's so much fun to get an insight into the decision making process, formalized processes. How do things come out of Facebook? How do they go in? Who's in charge?

Those kind of things, James. And as the lead of the open source efforts there, you definitely got to ask about not just how you go about open sourcing things, but what about what to open source and what has to stay closed? And do engineers need to convince their managers that this should be open source? Give us the insight. How does that all work? All right. So again, we're very blessed with a culture that celebrates open source and appreciates open source and goes without saying that pervades the company from the top down.

So we generally don't have to argue the case for the value of open source at all. And I would say pretty much every engineering manager, every engineering director, every engineering VP, let alone a large percentage of our engineers themselves, are totally on board with the benefits of open source, both to the company and to the communities and to the industry as a whole. So certainly culturally, we have a very open door to push on. We don't really have to spend too much time arguing why it exists at all. That said, there are obviously certain projects that are likely to be more successful than others. And there are certain things that we do that we think are suitable for sharing and some that are not necessarily suitable for sharing. I try to maintain as simple and lightweight a process as possible

for deciding what we should or shouldn't open source, to the extent that we even have an internal tool on our Facebook intranet that basically allows people to answer a short series of questions as an engineer or as an engineering team, and basically finish the wizard, press the button, and we will enter into a very lightweight process to determine whether that project is good to go or not. So as long as a project fits well into the kind of the template of what we're looking for, you know, we can really accelerate these things and publish them pretty

quickly. There's not a many months long bureaucratic process, you know, involving lots of decision making or death panels or whatever. It's very much a fairly open door for most types of projects to go through. And I should say, you know, to some of my earlier points, really the main criterion of everything, out of everything, is I need to be comfortable that a team is committed to maintaining the project after it has been launched. And this goes back to some of our experiences in the early days of our open source program, where we literally pushed code out and walked away from it, or we gave it to a foundation and walked away from it. And those all ended badly because there wasn't that sense of ownership. We didn't give these projects a chance to grow up

and get traction with the community. So that is really the thing that I'm looking for. Is this team in it for the long run? Because the few months it takes to get something ready and the glory of open sourcing it in the first place is just tiny in comparison to the potentially multi-year commitment you have to keep the project going, keep it maintained, work with the community, et cetera, et cetera. And so we're really, really keen to make sure that the teams behind it understand that obligation

and are ready to meet that challenge. Of course, we do also have a legal team that is looking at licensing and looks at areas where we feel we have something new and exciting to offer the world versus maybe just a me too kind of project. We never want to be releasing projects that are just apparently a rewrite of something else that already exists. You know, we're trying to be additive to the community in a way that, you know, is, you know, beneficial to everyone. And then, you know, finally, we have some guidelines around which parts of the Facebook infrastructure are more likely to be good candidates for open source than others. So I think I mentioned earlier in the podcast, we've got a couple of really strong areas for open source,

such as the JavaScript product infrastructure, like React and React Native, Jest, Relay, GraphQL, et cetera. And so anything in that kind of area is a pretty strong candidate. We kind of feel like this is something that's really beneficial to a very large community. Machine learning, we also mentioned, that's a very strong area for us right now. Core data, database infrastructure, things like MySQL, RocksDB, those are also very popular. And I think the final area that we probably haven't mentioned on the call yet, which is actually a huge area for us open source wise, is developer tooling as a whole. So our developer infrastructure team that is building compilers and build tools and CI systems, editors, code review tools.

You know, that's a whole little ecosystem of stuff that we've been we've been open sourcing a lot recently so um some of your listeners might be familiar with buck which is a build tool for android and ios which is something that came out of that group you may be familiar with nuclide which is the ide that we use at facebook and which we've also open sourced so people can see like the actual tools we use to build stuff um So that's another big area. So yeah, we have these four or five kind of pillars or areas of software within the business where we're just like, okay, it fits perfectly. It really works well in the open source community. Let's just go for it. But definitely the infrastructure is an area that shares really well. So you mentioned this questionnaire. I'm sure the question about maintenance is on there.

You know, are you in it for the long haul? Can you give us a sample? What are the other, you said it's a lightweight little wizard. What are some of the other questions on that, that you would ask a prospective open sourcer? So obviously we want to know what the name is going to be, and we want to know whether it's going to need to have a website, um, because we have a small, uh, design team that can help put nice logos onto these projects and build out websites. We're looking to know what sort of technical writing is going to be required to build out documentation for projects. These are often things that engineers don't actually think about, but which my team can help put together. We also, you know, keen to find out whether the source of truth for the project

is going to be internal in which case we sync it out to GitHub or whether it's going to be on GitHub in which case we sync it back in again so we know how to organize the tooling around the actual code being transferred bidirectionally well you know that's basically

it it's a pretty short form we don't ask a bunch of questions. We default to a fairly standard set of licenses and we have a fairly standard boilerplate for how people contribute and so forth. So yeah, most of it is pretty templated and we're just asking for the kind of the things that vary from project to project. Well, James, let's talk about communities. I know that software is software, right? It is code, but it's powered by people. And that's what Facebook is powered by is people. The many billion that are, I guess, the billion and a half that's on Facebook now that as users, but also those

behind it to actually make it, you must have some strong affinity towards propping up the right communities. So I'm curious what you can share, especially as you mentioned earlier towards React and the things you're trying to emulate there as you do more projects that have that kind of limelight, so to speak. But I'm curious if you can share any tips on how you involve community, how you build community around your open source projects, how you nurture that open source community,

and maybe ultimately who actually owns the projects? I know you mentioned licensing, obviously, but do you feel like they're Facebook owned or do you feel like they're community owned? Okay. So lots of questions in there. A lot of questions, yeah. Yeah. I mean, the first thing to say is-

Here, let me break it up. Let me break it up. Let's start first with building strong communities. How do you nurture them? How do you support them? Let's start first with building strong communities how do you nurture them how do you support them let's start there you know i think this this answer varies during the the life cycle of a project uh i touched on this a little earlier the the seven stages of of life of a open source project um you know it starts off as an experimental thing. And then, you know, we try to incubate it and make it into a successful project.

And not everything makes it, but, you know, hopefully many of them do. And then we grow the community around it. And, you know, for many projects, at some point, we reach a stage where the community governance and the community contributions actually overtake the contributions of Facebook themselves. And then we have a whole set of new questions about, well, where do we take it from there? And then there are these off-ramps at various parts of that life cycle. We don't know what happens if actually a project doesn't become successful. What happens if the community just doesn't seem interested? Or what happens if

we ourselves stop using a piece of software because suddenly it's harder for us to carve out the time to maintain it. So, you know, what do we do if we need to find another steward for that project? Or what do we do if we need to archive it as a whole? So, you know, underpinning all of our interactions with the community, one thing I hope we can do a good job of is just be explicit about that life cycle and the role that the community can play in helping a project along that way. Ultimately, I believe that if you ship great quality software, it will get meritocratically popular and communities will form around it and communities will continue to grow and contribute back as well. But that's not the only part of that formula. I mean,

there's a lot more that we have to do as well to help these communities form. Can we pause there and talk about some of those things? Maybe that's much how you help them form, but what are some ways that facebook supports those communities you know the key thing that we do is to connect the engineers at facebook directly with the community so that's basically the the ground zero for all of these interactions um it seems kind of counterintuitive but we have never felt like we needed to put an official community management role into any of these projects. You might think that that would be, yeah, the first thing to do is get someone who can manage the community. But honestly, we've not needed to do that. And we found that we can be quite effective just by having excited and motivated and professional engineers at Facebook

doing the majority of that community interaction themselves. So that would be my first kind of takeaway, I think, is don't try to add a new kind of artificial role into the mix to try to somehow corral the community. You really, I think, need to be creating these bonds on an engineer-to-engineer level, at least in the very early stages of a project. In terms of things that we do to support the communities themselves, well, clearly we're putting the effort into working through issues and being very supportive of people's pull requests.

And incidentally, one of the things we do is track the average life or the average duration of a pull request so we can see which projects are being very prompt about dealing with community interactions and which are not. And so putting metrics around some of this interaction actually just motivates engineers to do the right thing community-wise anyway but as well as those interactions online through github and irc or whatever we also try especially in these sort of early to mid-stage projects we try to invest in meetups and events and making sure that engineers go out to speak at other tech conferences,

go to speak at other companies, to basically start spreading the word. And again, we don't invest in a sort of developer advocate role that goes and does this on behalf of engineers. We really try to make sure that it's engineers themselves who are on stage or in these communities that are doing the interactions themselves. It's far more authentic. It's far more about connecting like with like. At some point, these projects have the potential to become inside the portfolio, head and shoulders above everything else.

And I think we're at a state with React and React Native where these projects are now at a point at which we need to start thinking how do we involve the community even more. And we're thinking about that very actively. How do we give more non-Facebook employees the commit bits to accepting pull requests? And that's something we've really worked hard on on React Native to a lot of success. How do we get these ardent community members to feel like it's something that they own?

How do we, both online and offline, get the core part of these communities together to start working on driving the project forward, coming to some consensus on what the roadmaps are. And something that we found particularly exciting for React and React Native, how do we engage with other large companies that are also now using these projects to drive them forward? So community suddenly becomes not just about individual engineers or about startups or about people doing stuff in their spare time. It becomes about, you know, the Microsofts of the world and it becomes about the Samsungs of the

world and it becomes about, you know, the Twitters of the world who are, you know, now at this point also using React for some of their mobile services. And, you know, how do we as an industry start moving this forward and, you know, developing this project in a way that fulfills the needs of, you know, companies, you know, above and beyond in a way that fulfills the needs of companies above and beyond Facebook alone. So that's an interesting era that I think we're just starting to explore now and looking to see how the governance changes in order to respond to those requirements is probably an exciting period ahead for us. I think we've seen some histories with governance in other communities like JavaScript with Node, for example, and how that's changed. And so that's obviously raised a lot of ears in terms of people watching out for how governance plays out through a project, whether it's stewarded, as you mentioned earlier, by a company or actually started by a company.

So I think a lot of what you had to say that really did kind of answer my who owns it, so to speak, at the end. I think obviously you have your licensing, but it seems like you're at the point where you're trying to figure out not so much who owns React, for example, just to use that as an example, but how you include other people to give them ownership, to give them roles to play that are maybe typically Facebook engineer specific. Would you agree with that? I would agree that this is very much a work in progress. We as a company are in, I would say, uncharted territory, at least from our own point of view. Many are.

And we want to do this in a way that is responsible for the community and for the stability of the software too. I mean, we don't want to suddenly put React into some sort of model or environment where the speed at which we've been able to develop it and the quality of the software suffers in any way. So that is actually the challenge, as I said, reflecting back on some of our very, very early projects where we were premature about doing that and where the project suffered,

at least in the short to midterm, quite significantly. And I don't think that that's something we want to reproduce. So I think we'll know when it's the right time. And I think we know that might be quite soon. And we'll be working with our community and with partners in other large companies. As I said, Microsoft have made a stated investment to work on React Native for Windows. Samsung have made a stated investment to work on React Native for Tizen. And I think as an industry, we know how to figure out, well, how do we make sure this thing goes on to take it to the next level in a way that doesn't damage the speed and the quality

of the software that we've been able to build to date. I'll certainly tease up the second to last question we have here, which is really around you and your team and the way you're operating around open source to inspire the companies you'd mentioned, you know, having the commitment from other companies, which could to some degree seem like they're competitors in many ways, and I guess could be, but they're obviously supporting React and supporting, you know, that on a certain platform, so to speak. But I'm kind of curious, was it your mission?

Is it your mission even to inspire the companies? I'm thinking large and small, not just the big companies that you may see as competitors or not as competitors, but to follow suit with the support, as you'd mentioned, Mark back in the dorm room, going back to the early part of the podcast where Facebook's origination ground zero code zero, so to speak, uh, was built on open source. I guess the question really is, is, is it your mission, maybe even your personal mission, to inspire other companies, large and small, to follow suit with how you've supported and how you feel about open source to the degree that Facebook does? I would definitely say so. Again, that's a pretty easy door to push on. I don't think that there are many corners of, or at least... I thought there were still some companies out there that are big that are not doing anything in open source.

Not so much, not as much as they should. Being as open as you have is the point. You know, like you've really, like you said earlier, it's part of your DNA, open source. And not many companies actually have open source as their DNA. I think it is harder for companies that are significantly or even somewhat older than us. We, you know, formed in 2004, 2005, um, were just at that sort of tipping point at which you had this, sorry, that's a bit of management jargon. I should

have avoided tipping point, but, um, you know, it, it, it was a sort of a very ripe era for companies like Facebook to suddenly be able to years earlier or something similar, you wouldn't necessarily have had that open source DNA quite so strongly. And so, again, I want to come back to Microsoft. I think their recent sort of conversion or adherence to sort of open source philosophy has been really fantastic to see because I know internally that that has been a cultural shift that they've had to very consciously make.

And I really think that we need to celebrate that. So we've been lucky. And I think a lot of companies that have formed since the mid-2000s have found it just so much more a natural part of their DNA. That said, there's no reason why older, more established companies can't be at least made aware of the benefits that we've seen from open source. And I'm very happy to talk about the benefits that it's brought to us as a company and the benefits that it's brought to us as an engineering organization, because I would love to see that playbook enacted in other parts of the industry, in other parts of the world. And, you know,

to that end, we've created a small group called the To-Do Group, which is essentially a group of people like me who work on open source programs for large companies. And that's really a chance for us each to talk about the challenges that we've had to overcome, the tooling that we've had to build to manage these programs and the benefits that we've seen. And the to-do group now has 20 odd members at all the large companies that you might imagine. And we have a really healthy dialogue going about the sorts of challenges that we each face, and we're all learning from each other's experiences, and hopefully getting more of this good news out to other large companies that can benefit from doing open source like this. My philosophy is that eventually, we will get to a state in the industry where engineers just assume that the company that they are going to go and work for has a strong open source philosophy or a strong open source program.

And so if you want to remain competitive, even in the employment market, let alone in the sort of product market, you need to make sure you have a good open source story. Otherwise, you're just going to have trouble hiring people. And this is a message that I've hoped we'll get out to the technology industry and neighboring industries as much as possible, because that's a very powerful narrative and it benefits us all. That's certainly music to my ears, because that was almost exactly what I wanted to hear from that kind of answer was just that your philosophy is obviously what you said, and that's something to applaud. And I also agree on the Microsoft front. I'm so happy as someone who's been a podcaster for as long as I have been since 2006 to not

so much just cover open source, but care about how big companies produce what they produce and support the culture of computing and, and software development and all this different stuff. But, uh, that that's interesting to see there. We'll let you go, James, on one last question here. And, uh, this is a question that our, our listeners absolutely love to hear an answer to, and that's really what's on your radar. So if you had a weekend to hack, if you had, at Facebook, maybe no work-related things, you just was just maybe in a log cabin, tucked away by yourself. You're like, you know what? I'm going to play with this today.

What open source thing, what technology out there is on your radar to hack on? All right. So that's a very long list. And I think you're assuming that I discount the hundreds of open source projects that we ourselves have. So let me look elsewhere. So something that I am getting pretty excited about is machine learning. We talked about it a bit earlier. At Facebook, we've open sourced a bunch of libraries and toolkits for machine learning, and many others have too. And there's clearly some sort of perfect

storm happening. And there are many areas across the industry where machine learning is starting to make real headway at solving problems that were previously impossible, whether it's self-driving cars or search algorithms or playing board games. But the one area that I have not seen much discussion regarding machine learning, but which I feel is just totally ripe for it, is the art of writing software itself. Because I am absolutely convinced that many of the machine learning techniques that have been built for these other scenarios have some analog for actually coding as a craft. And I'm inspired by the fact that we've obviously reached a point

at which computers can now beat humans at chess and can now beat humans at Go. But routinely, a computer and a human together, playing together, can beat either all the other humans or all the other computers. I was listening to another podcast recently about this, that there are whole leagues for chess, at least, where it's basically all comers. You can bring a computer along and play with the computer,

or you can have the computer play on its own, or you can have the human play on their own. And it's these hybrid, you know, human and computer that always win because you've got the sheer data crunching have the computer play on its own, or you can have a human play on their own. And it's these hybrid, you know, human and computer that always win, um, because you've got the sheer data crunching of the computer and you've got the kind of the brilliance and creativity of the human to augment that. And this just sounds like the kind of winning combination we should apply to the art of writing software. Because if you think about what you do as a software programmer day to day, an awful lot of it is not high level thinking. A lot of it is just shuffling braces around and indenting things and getting rid of the lint errors. And

it's actually not 100% of your time is spent on high level brilliance and analysis and algorithmic thinking. The computers ought to be able to do a lot more of that dull day-to-day work involved in writing software. And I would love to see how we can somehow train systems to more augment the work that engineers do on a day-to-day basis, not just at Facebook, but, you know, worldwide. Because for 40 years, we've all been staring at monospaced fonts with 80 columns, moving stuff around to tell computers what to do. And I kind of feel that 40 years on,

we ought to have done a better job of disrupting ourselves. We've done a great job of going and disrupting the car industry and disrupting the search industry and the board game industry, but we haven't done a great job of disrupting ourselves. And I would love to see more intelligent tooling that might sort of explore how to make engineers, developers, 1.5, 2, 5, 10 times more productive than they are today. And I'm convinced it can be done. So if I ever had a weekend to just go and hack on something, that is what I would do. I would take some large corpus of code

and I would crack open some machine learning framework like Scikit-learn, and I would put the data into some kind of structure that I could train the machine on. And I would look to see whether I could encourage it to not necessarily write raw code, but whether I could encourage it to help me write what I needed to write in a more efficient way.

And I imagine some incredible IDE that is basically a human accepting all the suggestions that a computer is making one after another to create the code that I want. Autocomplete on steroids is something that we as an industry, I think, should be aspiring to and looking forward to. And that, I think, is something that I'm very excited about, looking forward to seeing what the industry can come up with in five to 10 years. We just need to step back and see how we can apply some of these techniques to our own work as well as to other industries. And in my very small way, I'd love to hack on that. You've got some big dreams, my friend. Big dreams. I like that. That's a good answer to that question. This is a chance to, I guess, give you a chance to say anything closing as we close up the podcast. Anything that has been left unsaid, anything you want to share to the listening

audience? You've got an audience of open source developers out there that probably really care about what Facebook is doing in open source. So is there any closing thoughts you want to share? So one of the things that Facebook tries really hard to do is articulate its mission and articulate its culture in a way that kind of preserves our values. And one of the ways that we do this is by putting posters up around the campus and stickers on back of laptops and stuff like that. And, you know, much of it just kind of washes over me. But there's one that really sticks with me, which is that we always should consider our journey to be 1% finished. And I know you've said some very nice things about the Facebook open source program during this podcast. But I really want to stress that we are just at the beginning of what we want to do.

Each one of our projects is potentially just at the beginning of what we might be able to do. And I am super excited to work with developers all around the world and with my colleagues at Facebook to look ahead and see what we can do with that remaining 99% of the journey that we haven't yet made. So this journey is 1% finished and we're looking forward to joining you. Well, fantastic, James. Thanks so much for taking the time to share with us a peek behind the curtain of Facebook and open source and how you

apply that to your business, how your business began with that at code zero, as you'd mentioned before, and how it's a part of your DNA, how it's a part of your mission, how it helps you make better software, and everything else you've shared here today. Thank you so much for your time. And listeners, thank you so much for tuning into this show. Obviously, we love you contributing, but we have an open inbox ourselves, speaking of being open. If you go to github.com slash the changelog slash ping, we have an open repository there of many issues that Jared does a great job of triaging and helping kind of hear from our listeners what to cover both in our weekly email called changelog weekly and also on this podcast. So head there, find what's already there that you might like pile on and add a comment or throw your own issue in there

but that is it for this week so everyone let's say goodbye goodbye thanks James it's been a huge pleasure thank you very much for having me on We'll see you next time.