a16z Podcast - a16z Podcast: The Changing Culture of Open Source

Starting point is 00:00:00 The content here is for informational purposes only, should not be taken as legal business, tax, or investment advice, or be used to evaluate any investment or security and is not directed at any investors or potential investors in any A16Z fund. For more details, please see A16Z.com slash disclosures. Hi everyone. Welcome to the A6 and Z podcast. I'm Sonal. Today we're continuing our series on the theme of open versus closed by focusing on the topic of open source communities and more specifically the changing culture of open source across generations and governance models to access an identity and identity politics. Should there be a sense of ownership in open source? What's healthy? What's not? Do we need to get religion or have a culture of personality in order to drive vision? What happens to projects that evolve out of big companies? companies and universities. Joining us to have this discussion, we have Nadia Ikbal, who did research for the Ford Foundation on the sustainability of open source projects before going to GitHub to focus on community programs there. And then we have Michael Rogers, who's been a contributor to various open source projects for over a decade and currently manages community and much more for the Node.js Foundation. And just for quick context, node.js is a platform built on Chrome's JavaScript runtime for building fast and scalable network applications. And its package

Starting point is 00:01:15 manager NPM is the largest ecosystem of open source libraries in the world. So we talk about open source a lot on this podcast in so many different ways in the context of infrastructure, pricing, trends. I just kind of want to break it down starting from the basics for the culture of open source. And maybe we can start with, you know, why you got into open source in the first place. Wow. So I think I got involved because when when I was really young, how I got involved in computers was through the hacker scene. And one of the things that really kept me there was that there were, like, people to talk to, and there was a community angle to it. And so when I started to work in, like, the actual industry, I was kind of searching for that continued

Starting point is 00:01:50 community. And that ended up being the open source community. Why is the community aspect so important to you? It sounds like so obvious, but why? We're in industry where people are in a job for like a year to three years. The relationships, the personal relationships that they have tend to stretch decades. And so community is kind of important to everybody. But in the open source world, it's just a lot more defined. The community is like literally the only thing holding these people together even at the time that they're doing the work. They don't all work for the same company. Right. So there's a certain portability in that because regardless of what job you take, you sort of take it along with you. Nadia, what brought you to the open source world?

Starting point is 00:02:22 So, I mean, the way I first discovered what open source even was was someone learning to code maybe like four years ago. And I remember having this moment at a Rails Ridge workshop where you get your Rails app up and running for the first time and typing in like, you know, three words. And all of a sudden, like, all these magical things happened behind the scene that I didn't know about. And I was like, where did all this come from? How did I create this app by not really typing that much? It was pure magic to me. And that was the part where I was like, huh, I wonder who is actually building all this stuff in the back end to, like, allow me to have that experience.

Starting point is 00:02:52 It's actually very democratizing that when you have all these people building that it allows you to literally write a few lines of code and then have this app up and running. Yeah. And the part that I think I've always been excited by is the human part behind it of like who made all this stuff and where does it come from. And why are they providing it to me for free? I'm glad you brought up that the human part of it because I feel like there's a tendency when we talk about open source and code to sort of mechanize it

Starting point is 00:03:14 and to me like the arc of this podcast is about the human aspect of open source because essentially you're working on code and then you have human beings, personalities clashing and coming together while working on this through these various open source communities so go back to just even the nature

Starting point is 00:03:31 of the fork you led and by the way you just told me today that you merged it back in now like what was the story behind This was the I.O.js fork of Node. The main difference was that there wasn't a technical disagreement. A lot of these other forks like Ethereum and whatnot, there's a technical disagreement that essentially is not really reconcilable a lot of the time. For us, we were actually kind of hitting a lot of the problems that actually Nadia's research calls out where

Starting point is 00:03:54 the sustainability of the project was in question. We had tons of users. I mean, the users of Node.js are still doubling every year, but the number of people working on it had gone down and the users are the ones who are just using the product that people

Starting point is 00:04:08 were actually maintaining and creating new code but contributors had dropped down to depending on how you're counting maybe three people were actually like

Starting point is 00:04:16 working on it from a high of something like seven so it was never really that high and the community around JS the people that have built modules

Starting point is 00:04:24 on top of it we'd actually done a lot of experiments in how do you grow sustainable contributors over time in this new GitHub kind of ecosystem

Starting point is 00:04:31 So we had some really good reference material and some strong opinions about how to do this. Also, some of the people that had been contributing to known for a long time were unhappy with the way the joint was running it at that time, had some disagreements. And so we took those disagreements and said, okay, we're going to fork the project under a different kind of contribution model where we get people more involved. Because it wasn't a technical disagreement, later joint put Node into a foundation. They needed kind of an open governance plan. We were able to merge the project back together. So you put it into the Linux Foundation. The Node Foundation is an independent foundation.

Starting point is 00:05:01 the Linux Foundation is essentially hired to run it, to, to administrate it. And so it is a Linux Foundation collaborative project. But Joyne had brought Node and created this foundation around it. We brought kind of a governance model in a lot of the contributors, and we were able to merge all that together. And so, I mean, at the point that we, you know, that we had this disagreement, we were down to, you know, maybe a high of seven committers. Today, about a year and a half later, we have 90 committers. Wow. That's amazing. So the reason for that you believe is because you changed the governance model of it. We started thinking about contributing to the project differently.

Starting point is 00:05:36 I mean, so for instance, that 90, that's just a core itself. If you look at the website and localizations and everything else, we actually have like over 400 people that have committed rights. So this ties so much into your research and thinking about sustaining open source communities. First of all, why does it even matter? Because honestly, as a consumer, as a user, I don't care as long as I have a product. So why do I care if there's three people working on it or 400? Everything is great while it works.

Starting point is 00:05:59 And when it doesn't, then suddenly it doesn't. And there are a lot of people who use open source products who then are trying to ask, hey, like, can we get this type of feature in or like this isn't really working? And if you don't hear feedback because nobody is maintaining it, then you have a problem. It would be as though there's like a bunch of volunteers working on Facebook or something. And it's like, well, I really hope Facebook works because there's only like 10 volunteers working on it. That's a good analogy. I think that there is like a somewhat laissez-faire reaction that's like, well, if people don't work on it,

Starting point is 00:06:28 then people don't care about it, and then it'll just go away. And what Nadi has found and actually demonstrated with real data is that there really is no connection between the number of users and the number of people actually maintaining a project. Let's pause on that for a moment. There's no connection between the number of users and the number of people maintaining a project. What's the significance of that?

Starting point is 00:06:47 So if a project goes into the state of disrepair, that doesn't mean that people stop using it. In fact, I mean, Heartbleed is like the best example of this where you have, I mean, basically nobody working on Open SSL or maybe like a couple people. people that aren't even paid full-time to work on it. And, you know, the majority of the internet depending on it. Yeah, and not just software, but, like, hospitals and banks and stuff that are using it. And, like, you have two people that are working on.

Starting point is 00:07:09 It doesn't make any sense. Right. So what are some of the other interesting things your research and sustainability of open sources has found? Some of it has just been around, like, trying to put vocabulary to what is going on. So about, you know, how you can have someone, people using this project, tons of people using the project and not that many people maintaining it. We need vocabulary to actually explain those two different things.

Starting point is 00:07:28 Right? Because right now I think a lot of people talk about projects as big or small, and big doesn't really explain what it means for a project to be big. So I've tried using terms like popular versus healthy. Tell me about popular versus healthy. Why does that distinction matter so much? So popular can refer to like lots of people are using the project and healthy might mean is the community behind it or the governance or like how many people are maintaining it. I guess the back end part of the project is that in a good state. So you can have projects like OpenScel might be a project that was really, really really popular. Lots of people use it, but not actually healthy. Until we separate those things out, then you have the problem of people saying, well, if it's, you know, if no one's maintaining it, then it's clearly not a great project. It's like, no, that's just two different metrics, right? And we have to look at one and the other separately. I mean, it strikes me that you can use the analogy of an organism to describe the community, like a human body or any other organism, and that you can have, like, this ecosystem of all these different parts and players. And then if you're healthy, you're functioning well. And if you're popular, you're like working really hard. But it doesn't necessarily mean that

Starting point is 00:08:28 you're in good shape. And that has all kinds of implications. Right. That's super interesting. One thing that I found interesting is because the dialogue tends to be set by popular projects and then you, and those developers and their problems tend to dominate the story about this, you, you have these words and vocabulary like drive-by contributions, right? Oh, right. Like these drive-by contributors. These assholes just keep showing up and giving us code. Like, don't they understand that I'm too busy to look at their code? It's crazy, right? But that that is like a lot of the dialogue around it, Whereas, like, you know, thinking of them as casual contributors and people that, like, show up and have value to add and, like, really what you need to figure out is how do you capture that value? How do you encourage it? How do you level people up? How do you know, retain people? So it's not a drive-by, but it's actually ephemeral. It's not so. It's an opportunity and it does have value. And the real problem is that, like, you don't have enough people that are maintaining it. And one of the reason they don't have enough people maintaining it's because you're not leveling up any of these people that come by.

Starting point is 00:09:24 That actually reminds me of some of the intergenerational problems in getting through the open source communities. I mean, when I think about the early days of like how, I mean, Jim Zemlin has described to me like, you know, the existence of the foundation, the evolution of the foundation. It kind of blew my mind that you have Linus Terwolds and then you have like this entire foundation of people. So it's not just a cult of personality. And then you have the sort of old world of open source and new world of open source, which is probably not a good way of describing it. But Michael, you're actually the person who brought that to my awareness when we did an. an op-ed years ago on how GitHub makes everyone essentially an open source. Yeah.

Starting point is 00:09:59 One of the things that's been like really undervalued is the degree to which in older open source, part of the barrier to entry that people went through before they were ever identifiable to any contributor was an acclamation to the culture and an acclamation to the tool chain and all of this stuff. And one of the things that GitHub has done is completely removed all of that cultural acclimation. Like there is one tool chain that you lose, that you use to contribute to any project. And then when you show up, you don't have.

Starting point is 00:10:24 have all of this cultural knowledge. You haven't like bought into any of these ideals about open source necessarily. You're just there to contribute and it's, uh, and we actually need to, you know, work with that. And there's just more like natural cross-pollination. I think that happens between GitHub projects and there was before because you can just be on this one platform and very easily move between different projects and kind of glance around. I just think in general, the more you can take inspiration from other places and easily link to them and point to them and have exposure to them, the more likely you're going to learn and iterate on your own. of these, there's like a positive way and a negative way to look at it. So like the negative thing

Starting point is 00:10:57 that I was here is that like GitHub is just a bunch of people dicking around with their own thing and they don't care about contributing to projects that are established, right? Which is like actually not true. Like there's there's a lot that a person gets out of contributing to a project that's popular and there's a lot of draw for that. The issue is that competition for people's attention is really high. And so unless you're a nice place to come and contribute, people don't care. A lot of established contributors that are used to just people showing up because they're a popular project, they're not getting any people because they're actually not a very nice place to contribute.

Starting point is 00:11:26 Well, so I have to ask a question, which is, does healthy necessarily mean nice? Now it does. You mean, contributors, something? Or in the community? Because, I mean, is niceness a quality of a healthy community? Because don't you want sort of a creative friction and collaboration? How do you sort of navigate that? I would say that in modern open source, in like the whole GitHub generation, they are the

Starting point is 00:11:47 same thing. If you're going to continue to sustain your project, you're going to be, need to need to to get people out of this giant pool of contributors. And many of them need to feel invited. And you're competing with a lot of other projects that are nice and inviting. And there's a balance between, like, I mean, there are projects that maybe almost over-invest into building really, really healthy contributor communities. But then someone's also got to use them.

Starting point is 00:12:09 Or else it just kind of becomes this really nice experiment in, like, what it looks like to have a healthy community. What are the qualities of a healthy open-source community? I mean, this is very tied to your notion of sustaining them. Yeah. I think just making it clear, like really, really easy. people to join, like first off, not scaring them away is really important. A lot of that is in documentation. So it's not just, here's how you do it, like steps one, two, and three, but even

Starting point is 00:12:32 just human language around, hey, like, so glad you're on this page, really excited for you to contribute. Like, if somebody is not sure if they want to contribute and they read that, then they'll immediately feel more welcome. And then when someone shows a little of interest, trying to, like, encourage and nudge them along, I think it's really important. So it really is more of like an active investment into what people are doing. I mean, is it also like a more formal onboarding? Is there even an onboarding right now? The reality is that some projects are complicated enough that you have to. But hopefully you can get around it or find inventive ways.

Starting point is 00:12:59 I mean, one of the things that we've noticed in the Node project is like we've broken up things that you can get involved in. So if you just have the skills to work on a website, you can actually work on the Node.js website. And we see people transition from that into core because there was kind of a cultural barrier to entry that they're now passed, that they're comfortable contributing to the project. So, you know, there is no formal lobbying process for the website. It's easy enough to contribute to. But then when they get over to Node Core, like, yes, there is because it's just a little bit more difficult. It's more critical. Yeah, yeah.

Starting point is 00:13:25 You have to have a slightly higher bar. Well, and not, I mean, not everybody makes that transition. That's not why we have a website project is just to get people into core. It's more about, you know, healthy open source projects value all of the skill sets that they're trying to encourage. So if we want a nice website, if we want nice documentation, if we want good tests, we actually have to have the same kind of path for those sorts of contributors, right? Like they need to eventually own that work, become commiters to. it. You know, we have people in the, you know, formal governance body around core that mostly have worked on tests, and they know the test system very well. And the same with

Starting point is 00:13:59 documentation, right? Like, these are core values, so they need to have the same, basically growth path as anybody else does, even if they're on, you know, deeply technical stuff. Code by itself does not make an open source project. You have to have all these other types of skill sets. And that's, like, one of the biggest issues that I've seen where people don't really understand the value of a healthy community. That's great. What is some of the other qualities of a healthy open source community. We started off with like the welcoming and the moment they join the community. Then even just beyond like how do you get like new contributors in or how do you up level

Starting point is 00:14:29 contributions or keep people around? It's also like how do you deal with issues as they arise? How do you talk to each other? Yeah. How do you actually resolve conflict? I actually really want to get to the bottom of this one. What are some of the negotiations that happen both in the actual commit and in the actual verbalization?

Starting point is 00:14:44 So one of the things that I've been a big fan of is is inverting this whole notion. Usually you'll have like a small group of people, whether the commitors or a smaller body of the commiters that are making a lot of decisions, right? And usually you put this in terms of like their gatekeepers. They have to make sure that every commit lands, right? They have to get agreement about that. That just doesn't scale. Like there are too many contributions that need to land for that to be the case. So what we do in Node and what we've actually encouraged other projects to do is invert that so that the default mode is for something to land.

Starting point is 00:15:14 And you may make corrections to it. you may need to get them to change things, but everything is going to land. And things only escalate into these, like, people to make a formal decision if there is a conflict around it. Oh, that's interesting. So it's almost like the default is it's going to work. Well, and 95% of the commits that we get into court do just land without ever having to go to the CTC, which is the governance body.

Starting point is 00:15:36 Do you think that your model of inverting that is what makes people hold to a higher bar so they're not sloppy? Like, do you think people are more sloppy when they know they have to go through a gatekeeper? No, I think that, like, the reason. why it's not very sloppy is because we dramatically increase the number of committers. So like there are 90 people that can review this. Nothing is

Starting point is 00:15:55 going to make it in unless it's pretty nice. But the reality is like, you know, a fix to a test, a small adjustment here, a bug fix there, these are not issues that need to get decided upon by a formal body. Like they're clearly valuable as nobody's going to object to them. Let's just let them get in. And then, you know, when

Starting point is 00:16:11 things are controversial, when people can't agree, that's when we escalated. And we have a We have a consensus seeking process. So it's actually a majority vote, but we try to reach a consensus if we can. To me, actually mirrors how we think about like workplaces or interactions with people in general. Humans are just humans no matter what they're doing. But, yeah, I mean, if you think about like evolving manager strategies now in workplaces where it's like wanting to default to trust of the people that you manage and not say I need to micromanage every single little thing you do, but I want to trust that you are on your own skill to handle this. and if anything is wrong, then I can stop it, but otherwise I want to just empower you to do what you're doing.

Starting point is 00:16:49 I think it's actually like very in line with like broader evolution of like how we think about human behavior and how we manage. I love that because I think that also reinforces this idea of these communities as sort of new organisms, the new nature of companies, because I'm really fascinated by decentralized companies and decentralized organizations and open service is one of the vectors to get there. But it's also interesting because going back to the human side, I remember Jim telling me a story about Linux Foundation where in the early days, one of the biggest lessons they learned was sometimes you just have to pick up the phone and talk to a person directly, just human to human. Yeah, forget even kind of battling it out, like, you know, in code. Yeah, yeah, the CTC, the governance body around node. We actually like to discuss things. But I like that. So in startup land, everybody likes to talk about ask for forgiveness rather than permission.

Starting point is 00:17:36 But the standard in all open source is you're constantly asking for permission. and we guard this commit bit like so strongly. And a lot of that comes down to like the history of the tool chain, right? Like with CVS and with subversion, like you could make pretty bad mistakes that were very hard to recover from that really took like an expert in the tool. But Git isn't like that. Git is very forgiving. You really can't mess it up too much. And so what we've been pushing on is sort of liberalizing that commit access.

Starting point is 00:18:04 Like once you get one thing in that is valuable, like we will onboard you as a committer very quickly. Well, and that move from subversion to Git was also interesting because of how it decentralized or actually now create a new identity for the developers, for the people contributing that code. GitHub is a general kind of collaborative platform, and they are essentially the identity manager for collaboration online, particularly code collaboration. They've won that battle. There might be another battle for other spaces. We'll see. Yeah, I mean, it's cool. I mean, like, if you think about Gits only been around for 10 years-ish, it's not unusual to think that when you have new tools in the system,

Starting point is 00:18:39 then the culture of how you work is going to chand. We believe that for everything else, why would we not believe that for open source? And I still, I think that we're just in this sort of like transition period from open source practices that worked in like the 90s or early 2000s or whatever pre-Git life and have to like recognize that some things are just not the same anymore. Well, I have to ask you a question following up on this idea of that shift. You once argued that there should be no my in open source.

Starting point is 00:19:06 And if you could share with us what that argument was and why you made it. There is no mind. Open Source refers to the legal position of what open source is and just kind of speaks to the tension that we're feeling today from a new generation of people. So historically, you think about open source as being like the code is the institution that we must protect and protect its freedom at all costs. I do not own the code because the code legally is out there in public demand. It's like out there for anybody to use, a copy to modify. That's the definition of open source. And so instead of having a possessive mine where you say like this is my bike, you have. have an associate of my, which is, this is my friend.

Starting point is 00:19:42 Oh, that's interesting. Possessive versus an associate. I even thought about that as a shift in the might. And I have to credit Carl Fogle, who was one of the original authors of Subversion for coming up with that and helping me think through that. But right now, like, as more and more people are creating and contribute to open source and don't have the same attachment to, let's say, the legal battles of the 90s or the early 2000s, because everyone releases their stuff as open source, whatever, it's not a big deal. And they don't think about. the fact that it's still it's not your project once you make it open source it is actually like

Starting point is 00:20:12 out there in the public for anybody to copy and use yeah we had carl on the podcast and and he he just had this like this idea of open source from the initial morals not from you know what the law actually says because all the legal stuff is just a hack in the law so that we can get to this place where we're all working on this thing together oh and by that podcast you mean request for commits your guys podcast where you talk about all things open source that's so interesting it's literally a way to get around it. Yeah, yeah. And because they don't have this long onboarding process where they have to acclimate to the culture and this giant tool chain, they don't think about these kinds of ideals the way that everybody who's involved in open source in the 90s did, right? It was just one

Starting point is 00:20:48 of the things that you went through in the onboarding process, sort of informally, you acclimated to the culture. Where that becomes awkward today is that so many different pieces of software now depend on other open source projects, which wasn't actually true, like, you know, 10 or 20 years ago, but now it's really prevalent. So entire businesses depend on everything. Right. Right. Open source projects. Virtually every business. And all of society. Like, again, we tend to think about like software companies depending on, but it's also like banks and hospitals and whatever.

Starting point is 00:21:15 I mean, it scares me when you mentioned the heart bleed and the SSL. That really drives it home. There was like a very critical bug that was found in OpenSSL. And the question was, well, why did nobody find this before? And the answer was because there were like two, there's one paid person and there's like 10 volunteers that are working on this. Like, of course they missed a bug. Sorry. And that led to this bigger thing from Linux Foundation.

Starting point is 00:21:36 and other organizations that were saying, like, how do we actually support these types of projects, that they have the resources they need to protect all of the world's information. Right now, today, with so many different dependencies, the question of whether you have this possessive MI or associate of MI is important because if you want to take down your piece of code, you can't take down your version that you put up, but you can't actually take it down from public domain. Once it's out and it's been licensed a certain way, it's out there. Like, anyone else can take it and modify it and make it their own. own. And that's like terrifying to some people because it's like, wait, that's my project.

Starting point is 00:22:10 You can't have my project. And it's like, well, because it's not your project because it's open source. And that's where the tension lies today. The funny thing is, I remember when we're talking to Carl, he has this view of, as long as it has an open source license, it doesn't matter how dysfunctional the project is because we as a community always have this ability to fork it, right? And we didn't agree with him on this because just the practical reality of working a project is such a huge overhaul. And you don't necessarily have the right people to do it in any particular time. And what you actually want are the healthy communities that have healthy practices. You want to be able to reform them and to keep them going. I think of it as like we can technically impeach

Starting point is 00:22:45 our president if we have to, but we probably want a healthy democracy thing. And that's a great analogy. So what are the incentives for people to contribute to open source? Well, this I think is the biggest change that we really need to change in people's conception because people still go back to the cathedral in the bazaar. And you describe that, by the way, because that's a really popular concept. Yeah. So the Cathedral in Nazar is a very, very old Ericus Raymond essay on like basically describing open source, especially early open source. And at one point he does get into like the incentives that people have. And the incentives he describes in that text are just no longer true. Like that's not why people get involved in open source. And what were those incentives? Admitting that we're stereotyping a little here, but just in broad strokes. Like how would you sort of paint the picture of what was the picture then and now? The people that he was. describing were technically oriented people, whether they were programmers or not, who, you know, in their own time, wanted to go and mess around with something. And, you know, because they wanted

Starting point is 00:23:44 to, you know, get recognition, because they wanted technical towns, whatever. Like that, that was their motivation and that was kind of where they were coming from. Whereas today, open source runs every business, every technology. Everybody is involved in it in some capacity if they're developing software. They contribute to and move around the open source software community as a contributor, as part of their work, as part of their social life, as part of like any kind of side project they do. And it's really usually not about recognition and about ego. I mean, all the people that are highly recognizable

Starting point is 00:24:16 in modern open source communities would trade it for three more people to help them merge patches. Like there, some of this is really inverted. And some of those just dovetails with software itself and the process of making it is so much more accessible in the last five years than ever has been before. Now, you can see this happening even in, like, startups where we used to have this archetypal like, I don't know, college hacker or whatever

Starting point is 00:24:41 who became the founder. And now we are groaning about having these like more MBA types or whatever that are coming in. Part of it is just because it's becoming a lot easier to start a company. And part of why it's easier to start a company is because we have open source software. Democratize entrepreneurship. Yeah. You don't have to actually write as much code yourself to get something up and running. You can just use other people's tools.

Starting point is 00:25:02 And those tools are the open source tools. But where does a vision come from? I'm not saying there has to be a cult of personality necessarily, but it's kind of amazing when there's sort of a driving person, a driving force that sort of motivates people into a new worldview, like whether it's Vitalik for Ethereum or, you know, Mike Kern in the early days of Bitcoin, Gavin, Bitcoin, whoever it is. Linus Torval's for Linux, you know, like we can just keep going. So I think that one of the things that GitHub solved was they made it very low cost to have a lot

Starting point is 00:25:31 of smaller projects. And so what you're seeing is that basically large projects, large applications are assembled out of many, many tiny components. When you have these tiny components, they're scoped very well, right? Like they do this one or two things. They're not going to grow exponentially out of control. Whereas an older open source, when you were building a database, when you were building an operating system, there are a million potential directions that you can go in.

Starting point is 00:25:52 There's a million ideas of what the scope of this should be by everybody else. And because it's so hard to set up the infrastructure for an open source project and get it going, there was a lot of incentive to try and get every feature ever into these projects. But that goes away and it actually becomes a lot easier to manage projects when they're much smaller scope. Sort of like the decentralization of anything creator related these days, right? Like we used to have like 10 internet memes that were really funny. And now like there could be a meme that got like three million views or whatever and like no one even knows it exists. Smaller projects might be really wildly popular, but it just solved like one small piece or

Starting point is 00:26:30 have their own size audience that's big enough for them, but doesn't have to be like the same sort of cultural personality we used to have. Does this then leave the domain of like the really big visionary projects to come out of academia, like the way Spark came out of Amplab, Apache Spark, where you have an entire new set of companies being built? I mean, they like now have had like multiple conferences like since like, you know, that keep growing and growing. For me, this is like one of the big questions around sustainability is not just how to we support the projects that already exists, but where are all the new things going to come from that are really, really big when you don't have any sort of, honestly, like any sort of incentive for it, which I think

Starting point is 00:27:04 government and academic institutions have traditionally done for software, and they aren't necessarily participating in right now. So do you have an answer to that question? No. That's what we're going to do. I tend to take the long view. Like, when I see larger projects like that, or in general, what you would call, like, a framework, where you're usually, what it usually is is there's a new use case.

Starting point is 00:27:24 And in order to really fulfill that use case, somebody wants to take responsibility for the entire problem, not a piece of it. So they build a very large stack, a very large project to go after that. Once, after like a few years, though, you start to recognize what are the good ideas in that stack and one of the bad ones. How do you recognize that? I think it varies. But like you can take a few examples like, so React is like a very big JavaScript framework right now from Facebook. It's actually assembled out of many tiny components. But it's really easy to, for me at least, to poke in there and say, like, okay, what are the ideas in here that are going to last way beyond when anybody's using this framework?

Starting point is 00:28:00 Like, they have this notion of DOM diffing and applying the differences to the DOM instead of just applying all the updates or replacing entire sections of the DOM. And, like, that's really powerful. And there's already a dozen libraries to do that in different contexts. But once we move on to a new use case after that one use case, it's very hard for these frameworks to add things that help them into that use case. So what we end up doing is we break apart all of the good ideas and the smaller components. are more reusable. So you're saying that's almost the inevitable evolution of every successful project. I'm a little bit biased, but also like when I look at newer frameworks for a lot of this stuff,

Starting point is 00:28:33 especially like React, they're actually assembled out of many tiny components now. So even our bigger projects are broken in tiny components, just because they're easier to manage, to be honest. I mean, honestly, it does feel like the natural evolution of things, that everything breaks down to these micro components. I think so too. Microservices, micro work, micro hours, micro everything. Yeah. I mean, I think of it as having like all these easily accessible little Legos and you can just kind of turn them into one building and you break them apart and you build something else with it or whatever. If the world can function that smoothly, then that would be great.

Starting point is 00:29:02 That's an ideal to aspire to. You still need people to think about like, why are we building it this way or what does the actual system look like? And that role is actually kind of being filled lately by companies like Google or Facebook that have the resources to make big strides the way that academic institutions used to. That can also lead to like a bleak future if we take it to its fullest extent. So far, they've been contributing a ton of things. They've been open sourcing their thing. Because I think they recognize selfishly and unselfishly that for a lot of the most successful things, you need to create ecosystems around them.

Starting point is 00:29:32 And that's a really important piece. I mean, even open sourcing TensorFlow. Totally. Yeah. But I'm a little bit more critical of those projects in that they are open source technology. And, well, that's enough for Carl Fogel. It's not quite enough for me. Like, I would like to see them under either open governance or just like having

Starting point is 00:29:48 contributors that don't work for that one company, right? or having like, like, I would like to know that the sustainability of this project is not dependent on how much money that they want to put into it. Because I've seen it just happen too many times where, you know, this ends up being more useful than that company has use for it. And it becomes harder and harder for them to justify the continued investment that it takes for this growing community and growing number of use cases. I mean, like, you know, their projects like go at Google where they can continue to flow money into it because they're using it so much internally. But at some point, if they continue to be popular in the community, it is. is going to, you know, be bigger than just Google and how... Right.

Starting point is 00:30:24 But isn't there also been a historic precedent where then a lot of those companies actually kind of gift it to a foundation or a community? Sometimes I think gifting kind of means it's like sending your dog away to the farm upstate. Like, I don't know. Tell me more ways. Like sometimes people go, we're really excited to announce that this is now open source, meaning we don't want to take care of it anymore. So go live over there.

Starting point is 00:30:45 We'll give it to the community except they haven't actually identified anyone in the community who wants to take care of it. Yeah, there's some dumping going on. Yeah, it's basically dumping. And sometimes they'll even try to retain some level of control even without investment, which is really bad. But they're a counter examples. I mean, Google just gave Kubernetes over to the Cloud Native Computing Foundation. And that's like an up-and-coming project that's getting lots of contributors and lots of new adoption.

Starting point is 00:31:08 And that was just because for it to be a de facto standard, it needs to be a neutral body, right? So there's some recognition. That is the evolution of computing until now. Yeah, yeah. So clearly you guys are lovers of open source and passionate about everything. represents the potential and the possibility. So why Nadia, have you actually said in the past that you hate the term open source? Oh, I said I hate the term open source, which admittedly was a little bit inflammatory to say that.

Starting point is 00:31:31 I felt very, I felt this tension coming in as an outsider and talking to some people who strongly believe this one thing is definitely a core value of open source. They need to turn and talk to other people and they're like, no, this exact opposite thing is also a core term of source. And it started to feel like the term open source is just sort of meaningless. Or it just creates all these religious debates clearly. Totally. Yeah. And like, you know, there are also people who don't use the term open source because they want to use the term free software. And I think I just felt sort of frustrated. I used to edit Richard Stallman. I know. Oh, my gosh. Wow. And by the way, he doesn't even like the word free. It has been Libra. He's very specific about this. And it's just, there's just, there's so much focus on like what are all these different terms and what do they mean and what is my affiliation. And I just sort of like. There's a lot of identity politics. It's like religion. It really is like religion. A lot of it is historical. The open source branding kind of helped open source win. And then when open source won, I think that a lot of. the free software people went, well, that's not necessarily our values. We're going to glob onto this other identity. But then now the people that kind of stayed on the open source side of that also had a bunch of identity and a bunch of values associated with it. And their assumption is that

Starting point is 00:32:31 everyone who comes to work on open source needs to acclimate to these values. And with this whole GitHub generation, these people are not grabbing those values before they contribute. They're contributing for a whole host of other reasons and we shouldn't expect them to share all these exact values. The GitHub generation, as you dub it, open source is the default. There's nothing to push against. So it really is just about being a regular person going about your day than about being an open source. And to be fair, in a nod to the older generations, they don't see all that partially because there were previous generations that were fighting for all this stuff to say, like, oh, now you can just like copy paste this license and you're good. But there was a lot

Starting point is 00:33:09 of work that had to be done to even though. Yeah. We were standing on the shoulders of giants. But even that, like, I feel like, you know, people are taking the MIT license. It gets a way to say, I'm opting out of these identity politics. Yeah, it's saying, I don't care. What's a license that we're talking about? The MIT license. So the MIT is a liberal license, similar to, like, the BSD license. It's now, I think, the most popular license.

Starting point is 00:33:27 It's a better license. And the Apache 2 license is a better license. But there's a lot of stuff going on with Apache as an identity and a lot of, like, identity politics around open source. And so I think really, really, like, why people have been taking MIT is it's a way to say, I just don't want to have that argument. Let me do my work. And that's what the, I think the GitHub generation is much more interesting.

Starting point is 00:33:46 it in, like, workflow, collaboration process side of open source and the legal side of it. It's just, like, almost less relevant to someone. Also, the legal stuff still does exist and patent protection is a big deal. There's a lot. It's still happening and evolving. And also, like, companies that are now using open source and, like, wonders and compliance. We haven't even talked about Oracle and Google. Like, what the fuck?

Starting point is 00:34:05 That's, that's been great for Node.js, though. It's just another reason not to use Java, I guess. I don't have Sarah on this podcast, and she literally live tweeted the entire thing from the courtroom. Oh, that was brilliant. Yeah. watching that. That was so good. So Oracle acquired Sun. Sun owned, basically all the intellectual property associated with Java. They then claimed that the API, which not the implementation,

Starting point is 00:34:29 but the actual API surface. Yeah, I remember doing an app that on whether you can patent an API. Yeah, you can't. If you can, then virtually everything that we've built open source on kind of doesn't work. And a lot of like our entire industry falls over. So no, like, you have to pretend that that legal precedent wasn't said, even though it kind of was. And then, yeah, so they sued Google for infringing upon that API. And then they actually won a case that said, yes, you can patent an API, even though that's crazy. And then, but they lost an appeal that was very awkward, but eventually won. Google did not have to pay them in the end.

Starting point is 00:35:04 But in the meantime, you know, Java's predominantly used by enterprise customers. They're not happy that the underlying IP they've been building on is suspect. Yeah. I mean, this actually goes to your idea, Nadia, about there's no my and open source. It plays out very differently when the my is an enterprise. Totally. Yeah. And it goes back to your guys' ideas about what happens about the good motives of the Google, Facebook's, Twitters, who then open source their internal tools. Yeah, yeah. I mean, it just, it made me think, like, I'm not going to invest in a platform that is not, like, in a neutral body, right? But isn't that also a little idealistic for you to say a lot of people have to invest in platforms that are not that neutral? As a programming platform, those are choices that you can make. But yes, like, sometimes you have to deal with. with the App Store or whatever.

Starting point is 00:35:46 Yeah, I think it's actually going to be one of the most interesting battles in open source moving forward. What is the role of a company is going to be in open source moving forward? Because to briefly summarize history of open source, there was a time where companies were like, oh, we don't really want to use it because we don't think it's reliable. Then tons of startups got built using open source because, you know, big established companies didn't want to use it. They were like, and startups said, we'll use it. You know, made tons of money. Now those starts are huge companies themselves.

Starting point is 00:36:10 So just to wrap up then, what are some of the other things for what you guys think are ahead, whether there are battles or things to pay attention to on the horizon. What else is up ahead? Working for a foundation now, I've come to respect some of the institutional infrastructure that you can get behind things. And I think that as we start to think of open source projects as infrastructure, you need some kind of institutional support for that. But it runs a little bit counter to this trend of everything getting smaller

Starting point is 00:36:34 and more broken up and more distributed. Well, maybe the institutions themselves can be that way. You need just a little bit of institutional oversight to then let people do what they want to do. That was when you talked about the side of the JASB. That is all very true. but it is very complicated to implement. Especially as we get better at managing open source projects without institutional infrastructure, people become more resistant to it. Because it always adds something, right?

Starting point is 00:36:57 It's always another thing to think about or to deal with. And I think that people really like to live in a world where they don't have to worry about a lot of those concerns. Well, it just reminds me what happened with even like holocracy in the organizational sense, right? But I don't think it's saying that you need institution in the traditional way. It just means that you can't just completely dismiss it. Yeah, there's a balance. You don't want to micromanage people, and you also can't have a completely decentralized system. You have just enough management somewhere in there.

Starting point is 00:37:20 Okay, anything else you guys want to add on the what's next trends? Things are top of mind. Just personally, I've been mainly interested in the distributed web and a lot of the new stuff going on in the kind of peer-to-peer distributed web. And it's everything from IPFS to just to tour to like blockchain is kind of in there. IPFS is a interplanetary file system. It's basically a way to, in a distributed fashion, store file. and serve them out, and eventually potentially even kind of replace HTTP as a transport for web-like applications. And then peer-to-peer in general is just, you know, everything from BitTorrent to, yeah.

Starting point is 00:37:55 But there are some new web standards that really help bring a lot of this along, like WebRTC. And I really like the intersection of this along with sort of like repressive governments and regimes and people who have poor access to information. Like there's actually a lot of benefits to sometimes online, sometimes offline. distributed systems that they can really do a lot for people. I find coming back to sort of like the holistic look at open source, like I'm really interested in seeing how org structures for open source projects themselves is going to evolve, where it has been so lopsided to developers and code. But the only really way to, I think, like, have sustainable projects and sustainable organizations

Starting point is 00:38:33 is to bring in other types of skills to support all the things. And by other types of skills, you mean? People that can, you know, write good documentation, people who can do project management. I would even have design, by the way, to do. Because this is my number one complaint about open source projects. It's how fucking over the interfaces always are. I was blown away when we talked to Jan Larnhardt from the hoodie project. And he said...

Starting point is 00:38:53 What's the hoody project? It's a... It's a JavaScript library that has probably about as many contributors as users. They've done a very good job of building a great community that way. But it's sort of for building like online offline applications on top of like CouchDB and things like that. Great community. But he was saying that in their community, they actually have a team of people that work on the marketing and actually talk to analysts on behalf

Starting point is 00:39:16 of the project. So the project itself is essentially as a marketing department. Yes, but they're all volunteers. They're all part of the community. Interesting. So even adding marketing as a capability, that's actually great.

Starting point is 00:39:27 They have an editorial team. I mean, that's actually pretty great. I mean, that's a natural evolution. If you're saying that this is a wave of the future and already even is here, then why shouldn't it then take on the forms and functions of every other previous successful organization and company before it?

Starting point is 00:39:42 And ditched the ones that didn't work. Exactly. Okay, you guys. Well, thank you for joining the A6 and Z podcast. That was a lot of fun. Thank you.

Your Ad Here

a16z Podcast - a16z Podcast: The Changing Culture of Open Source

There aren't comments yet for this episode. Click on any sentence in the transcript to leave a comment.