Open Source at Facebook

Welcome back everyone. This is The Changelog and I am your host, Adam Stacoviak. This is episode 211 and today Jerod and I have a big show for you - open source at Facebook with James Pearce. 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.

Yes, 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 sources is hard to keep up with, but even just open source at Facebook is hard to keep up with.

Right, it is, it is. James, what’s your official title?

Well, firstly, thanks very much for having me on the show. 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 Head of Open Source? We want to go into your back story here in just a second, so for listeners who listen to this show all time or getting there, but I’m just kind of curious at what point did 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 Recordon 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.

At that time we had one or two interesting projects that we had worked on, and David who is a real advocate for keeping things in the open, had worked on OAuth and various other standards himself, and we open source 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.

[04:07] 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. 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.

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 try 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 “Open source needs to be fixed, we’ll find someone 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. So I jumped in, kind of raised my hand, volunteered and got things going again.

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.

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, be supported as you said, so you seemed 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 to just do the right thing anyway with regards to open source.

Right.

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 that 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 were really wanted to create that impression or, in fact, that reality that 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 as a buffer. We really wanted to 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, 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 I can talk about as well. But it’s well over a thousand in a given six-month period, engineers throughout Facebook who are contributing to one of our 350 projects also.

[\00:08:06.10] So it’s really a cool 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, key especially in the infrastructure side of the business where we’re working on tools and frameworks and platforms that enable product engineers inside of Facebook. You know, a lot of those are really, really excellent open source candidates and that that’s very much part of the culture.

I should also stress, it’s not just software. 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 has 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 maybe why that seems to me, maybe just me in particular, why that seems like more of a back story 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 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 servers, huge amount of storage and networking.

You know, quite honestly the idea of open sourcing our designs 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 Microsoft, now through to Google and many other hardware partners have been involved with the open compute project to, we think, 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 the technology industry as a whole.

Another facet of Facebook open source beyond the software and 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; DarkForest, which is 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 we’ve been very keen to share. The work that we do on research is often very overlapping with 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 are 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 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 a 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.

[11:54] We are privileged obviously to be able to put resources into machine learning and it’s clearly an area where there’s still a huge amount to be done. And it just comes back to this underlying philosophy for why we do open source, which is 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, 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 the number of machine learning projects that have come to light, and which build on top of each other as well.

Absolutely, yeah. There’s been like a Cambrian explosion in the last few months of machine learning type of projects popping up on all the big tech companies, open source projects. 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 are pouring so much into maps that could be a common base, and it seems like a waste of resources.

So it’s great to see all of the collaboration… And even a little bit of competition, you know - look what we’re doing, look what you’re doing, you can gather ideas and see who’s doing what, and 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’d like to get people’s origin stories. We think it’s very inspiring and it can be insightful to find out how people got where they are.

So here you are, you’re heading up open source at Facebook, and we wanna 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 like how did 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. 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 Sencha back in the day, and we worked on things like Sencha Touch. Prior to that I worked on Mobile Internet as we called it back in the day, startups around the WAP and the early-mobile web technologies. And again, 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; it’s always seemed pretty obvious to me.

Go back in your life and tell us… I think about my first interaction with open source software, and it’s probably like Linux, maybe WordPress or Apache, and it was almost native to me as well, I didn’t know life outside of it. How about yourself? Give us early software experience or early open source experience. What got its hooks into you?

[16:16] I don’t know whether I need to kind of open up my Pandora’s box of the historical facts, but…

Do it.

Crack it open, man.

Oh, for the longest time I was Microsoft .NET developer, back in days, so the early 2000s. I was all about C# and ASP.NET. Quite honestly, it was pretty amazing back in the day. And then I think my epiphany, 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 - developer tools were pretty phenomenal even back then.

And suddenly going to something like PHP and Linux and MySQL - that was a big eye-opener for me, 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 wanted, I can go down and change it.” Maybe not 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.

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 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 not as good as some of those things were back in the mid-2000s. That’s why I’ve been very excited to see things like Microsoft’s shift towards open source ecosystems, things like Visual Studio Code, now 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 everyday knowing that I can help produce these exciting projects, or shepherd these exciting projects, as well as a build that layer of tooling on top of them.

I love that. I feel like we’ve got some insight there, your early history in your career. Take us back… Let’s just pop a stack and go one level deeper into Pandora’s box and take us to childhood or first impressions with software. When was your introduction into coding? We’ll get, and then we’ll take our first break.

Oh my goodness, so we’re talking about a different century now, I’m afraid. [laughter] 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 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.

[20:06] 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 in the UK which fit that bill, which was the Sinclair’s ZX81. And I’m not sure whether that ZX81 ever made it to the US, but hopefully some of your international listeners will remember the Sinclair ZX81 and Spectrum with some fondness. I certainly do.

It was wonderful. It was this tiny little black box, you wired it up to your TV, you had a cassette tape for loading and saving, and 1K of memory was all you got; no games, no apps, nothing. And if you wanted to use this computer for anything, you basically had to type it in, which either meant going to your local newsagent’s and buying a magazine from which you typed several hundred lines of ASCII text or you just made up your own stuff.

Within a few weeks of realizing this box didn’t actually do much, I figured out that I was gonna have to type in some numbered lines, which was a fairly simple form of Basic at the time, and started writing games just to get this box to do something. 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 of school. 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.

Love it.

I mean, why have a memento when you can have a future, right? I mean, that’s what it seems to be. This 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.

Alright, we are back with James Pearce of Facebook; as a matter of fact, Head of Open Source at Facebook. Which Jerod, as we said earlier in the show, that’s not a small thing. A hundred and eighty repos on GitHub that we’re actually able to track that’s public, or at least publicized right now…

Roughly, yeah.

[24:00] Roughly a hundred and eighty, but React, HHVM, HipHop Virtual Machine which was 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 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. I think if we have the time, I’ll run quickly through all of them. 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 thefacebook.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 gonna guess on behalf of Mark that the latter was far more dorm-room friendly. The idea that it wasn’t gonna 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 wasn’t 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, you know, it’s been open source ever since then. So we have this kind of this 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 really want to share back.

So there’s that really 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, help accelerate their innovation on top of what we have built. So that’s definitely, you know, a strong part of our ethos here.

The second thing is that I think openness is just such a core part as of 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.

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 - and this is kind of an interesting one - it turns out it means we write better software if we know we’re open sourcing it, and that is extremely demonstrable. We’ve had many projects in the past where we’ve tried to open source them retrospectively, where something that we think is valuable that we realize 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 a hard thing to do. I mean we have done it many times, but those projects where we know we’re gonna open source it right from the start, where the team since down and figures out, “How are we gonna package this system or this project in a way that’s going to be easily shareable later on?”, those projects are just so much better architecturally.

[28:03] They have much cleaner API’s, they’re gonna be much more modular, they’ve got much better documentation, they’ve got a much easier installation process, and 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. 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 is obviously beneficial for that to be used throughout the company. We are a pretty large company at this point, so having a system that’s 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… 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 React.js Conf 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.” Basically, if you know that you’re going to be opening up your kimono sharing all this work with the rest of the world, it’s gonna 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 get 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.”

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, you know, the story behind that, we’ve figured out that at the scale we’re operating or with number of transactions we are having to deal with or with the complexity of our web UI, this was deemed to be the best solution to the problem.”

That is a way for us to tell that story about the types of problems we have to solve, which it goes without saying, gives us the opportunity to find other individuals who might want to come and help us solve some of those problems. 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 gonna ask you, I was waiting for that one. I figured… Because 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 it the most capitalistic or the most obviously beneficial was 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.

[32:06] We saw that first hand with Dan Abramov. When he came on the show, I think that was his first week he was actually training in London and that was his process to get to get hired at Facebook, this similar model, 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 have worked on before they joined the company is really high.

So 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 gonna take them an awfully long time to ramp up and be effective.

You know, with 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 the 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, releasing something as open source makes the software better for many reasons. I’m just wondering if there is 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 a certain way. Is there some sort of process that you’ve come up with over these years that is somewhat shareable here?

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. 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. So a lot of new projects will simply say “Look, we’ll emulate… We’ll emulate the React team, because basically whatever they’re doing seems to be working.” 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, but also in terms of stack. So the JavaScript projects that we have, I would say 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. 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.

[36:02] 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 the listeners know about React and the way it’s developed, and the way the team is formed around it and the way it’s open sourced, when the community operates, their conference, and various things that make it successful - what are those attributes to you to emulate? If you’re feeling that is an example.

Right. I can’t guarantee that I know exactly what the magic sauce is, but there are again three or four things that have worked really well for that particular project.

The first thing to point out is that when we announced it, which I think was probably May of 2013 or so; about the same time we were rebooting the program as a whole, coincidently. When Tom Occhino and Jordan Walke stood up at JS Conf 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. To be perfectly honest, for the first six months it didn’t look like React was gonna 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 like any other project out there that 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. 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 gonna be successful, and internally the reason we knew that was 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 JS Conf. This was a JavaScript platform that we already were using throughout the Facebook suite, or the Facebook products and websites, 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; this was a system which we had already used, deployed internally and advocated successfully to hundreds of engineers with, and we know it was solving real problems that we had.

So we knew that ultimately people would realize that based on the boundary conditions we had, this was the best solution. It’s obviously not necessarily going to be the solution for every problem, but for the problems we had it was the right thing. So we were pretty sure that eventually it would find a 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 need to get over that initial skepticism I think, because it just looks 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. 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 somebody outside the company sort of starts to rally to that cause.

And we actually put in place a number of ideas to help get that in a flywheel spinning. And one of the things I think React team did really well was a regular community roundup. Pretty much right from the start we did this monthly blog post where we would share all of the slides or YouTube videos or projects that people were working on that worked with React.

[40:07] 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, this 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’ve judged it too quickly the first time.

But I would definitely credit that idea of 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 product - 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 gonna be exactly 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 a next, because we ourselves would have to go through that same pain. Once we can do some kind of nice code marked internally, we’re always aware of the fact that we don’t want to break the API’s too dramatically. So now React has this really nice kind of phased deprecation process from odd to even versions of React; that means that the community can come along with us as we develop a framework.

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 are made.

So I think that’s being 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. They’re “web scale,” you have billions of users, you have a huge code base with a legacy and a history behind it, so you’ve 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. Is that a factor that you guys think about? I’d just like you to speak to that idea.

[43:53] Yeah, that’s a really interesting point. I don’t think we pretend to have the solutions for every problem, and I think we worked quite hard, whether it’s tech talks or in documentation, 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 road map for a project that really are just not gonna fall in any of our plans, because they’re not relevant to us.

Exactly.

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 API’s 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 a RocksDB.” I mean, I’m sorry, we’re not gonna 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, sorry. Without being rude, we’re not a professional services company that’s just gonna be here writing the software the community needs, and so we’ve really gotta be clear about what is on our roadmap and what is not. And if it’s not, it doesn’t matter. It doesn’t mean it’s not going to get done by the community, it doesn’t mean we’re not gonna 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 repo. What implicit warranty are we making about that binding that actually isn’t something that we ourselves used? We can’t guarantee that it’s not gonna break from version to version.

So yeah, 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 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 API’s and the ways that we can allow these other bindings or other projects 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 ride and we can’t even validate that it does what it’s supposed to.

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 needs to graduate to some kind of bigger governance model or some kind of more community-lead 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. 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 it’s a pretty exciting thing to think about for the future.

[47:56] Alright, 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 gonna 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.

So we’re back with James Pearce, talking about all things open source at Facebook. 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, that kind of things, James. And as the lead of the open source efforts there, you’re definitely the guy 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?

Alright, again we’re very blessed with a culture that celebrates open source and appreciate open source and it goes without saying that 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 of that are not necessarily suitable for sharing.

I tried 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.

As long as a project fits well into the kind of the template of what we’re looking for, we can really accelerate these things and publish them pretty quickly. There’s not a many months-long bureaucratic process involving a lot of that decision making or death panels or whatever. It’s very much fairly open-door for most types of projects to go through.

[51:53] And I should say 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.

Those all ended badly, because there wasn’t that sense of ownership. We didn’t give this project 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 in the 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.

So we really, really came 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 are trying to be additive to the community in a way that it’s beneficial to everyone.

Then finally we have some guidelines around which parts of the Facebook infrastructure are more likely to be good candidates for open source than others. 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. 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 are very popular. And I think the final area that we probably haven’t mentioned on the call yet, which is actually a huge area open source-wise is developer tooling, as a whole. So developing an infrastructure team that is building compilers, and build tools, and CI systems, editors, code review tools - that’s a whole little ecosystem of stuff that we’ve been open sourcing a lot recently.

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 that people can see the actual tools we use to build stuff. So that’s another big area.

So yeah, we have this 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 committee. 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 a 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 others? 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 gonna to be, and we want to know whether it’s gonna need to have a website, because we have a small 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 and these are often things engineers don’t actually think about, but which my team can help put together.

[55:56] We’re also keen to find out whether the source of truth for the project is going to be internal, in which case we sink it out to GitHub, or whether it’s gonna be on GitHub, in which case we sink 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 very 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.

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, it’s people. There is the billion and a half that’s on Facebook now 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 committee, how you build community around 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 and lots of questions in there.

A lot of questions, yeah. Here, 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 there.

You know I think this answer varies during the lifecycle of a project. I touched on this a little earlier, the seven stages of life of an open source project. It starts off as an experimental thing and then we try to incubate it and make it into a successful project. Not everything makes it, but hopefully many of them do. Then we grow the community around it, and 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 where do we take it from there.

Yeah.

And then there are these off ramps at various parts of that lifecycle. You know, what happens if your project doesn’t become successful, what happens if the committee 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 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 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 lifecycle 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 committees will form around it and committees 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 not so much how much you help them form, but what are some ways that Facebook supports these 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 ground zero for all of these interactions. It seems kind of counter-intuitive, but we’ve never felt like we needed to put an official community management role into any of these projects.

[01:00:05.22] You might think that the first thing to do is get someone who can manage the community. But honestly we’ve not needed to do that and we’ve 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 our 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, clearly we’re putting the effort into working through issues and being very supportive of people’s pull requests. And 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. So putting metrics around some of these interactions actually does motivate 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 this sort of early to mid-stage projects, we try to invest in meet-ups 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 or sort of develop an 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 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 in 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 think about that very actively, how do we give more non-Facebook employees the commitments 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 add both online and offline get the core part of these communities together to start working on driving the project forward, coming to some kind of consensus on what the road maps 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 the Microsofts of the world and it becomes about the Samsungs of the world and it becomes about the Twitters of the world who are now at this point also using React for some of their mobile services. And how do we as an industry start moving this forward and developing this project 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.

[01:03:56.01] 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 for 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 come to 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 to owns React, for example - just using 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. And yeah, 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 mid-term 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… You know, I think as an industry we know how to figure out, or 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.

That’s to really 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’ve mentioned, having the commitment from other companies, which could to a certain degree seem like they’re competitors in many ways and I guess could be, but they’re obviously supporting React and supporting that on a certain platform, so to speak.

But I’m kind of curious, 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 suite with the support, as you had 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, was built on open source.

I guess the question really 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, or at least…

I know there’s still some companies out there that are big that are not doing anything in open source… Or not so much, not as much as they should; being as open as you have is the point. You’ve really… You said it 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 formed in 2004, 2005… We’re just at that tipping point at which you had this - sorry, that’s management jargon, I should have avoided ‘tipping point’… [laughter] Yeah, it was sort of a very right era for companies like Facebook to suddenly be able to build things out very quickly, around the time that AWS and other sort of alternatives came out.

[01:08:12.00] But I think if you were to have started Facebook five, ten, twenty years earlier or something similar, you wouldn’t necessarily have had that open source DNA quite so strongly. 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. 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 world.

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.

The To-Do Group now has 20-odd members of all the large companies 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’re going to go 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 product market, you need to make sure you have a good open source story, otherwise you’re just gonna have trouble hiring people. And this is a message that I hope 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, that your philosophy is obviously what you said and that’s something to apply. 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 software development and all this different stuff. That’s interesting to see there.

We’ll let you go, James, I have one last question here and this is a question that 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 nothing of Facebook maybe, no work-related things, you were just maybe in a log cabin, tucked away by yourself and like, “You know what? I’m gonna play with this today.” What open source thing, what technology out there is on your radar to hack on?

[01:11:50.10] Alright, 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 tool kits for machine learning, and many of those have, too. There is 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 its 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 right for it is the art of writing software itself. Because I am absolutely convinced that many of the machine learning techniques that are being built for these other kinds of scenarios have some analog for actually coding, as a craft. And I’m inspired by the fact that, you know, 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… 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 his own or you can have the human play on their own. And it’s these hybrid, human and computer, that always win, 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 lint errors. Actually not a hundred percent of your time is spent on high-level brilliance and kind of 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 worldwide. Because for 40 years we’ve all been staring at mono-spaced fonts with 80 columns, moving stuff around to tell computers what to do. And I kind of feel it 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 hadn’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 kind of hack on something, that is what I would do. I would take some large core piece of code and I would crack open some machine-learning framework like a 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. Auto-complete on steroids is something that we as an industry, I think, should be aspiring to and looking forward to. [01:15:59.28] That I think is something that I’m very excited about and looking forward to see what the industry can come up with in five to ten 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 in closing as we close the podcast, anything that has been left unsaid, anything you wanna 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 thought 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 we do this is by putting posters up around the campus and stickers on the back of laptops and stuff like that. And you know, much of it just kind of washes over me, but this one really sticks with me, which is that we always should consider our journey to be one percent finished.

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.

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 had 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.

[01:18:03.17] 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/thechangelog/ping, we have an open repository there of many issues that Jerod 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, add a comment or throw your own issue in there.

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.