 Let me introduce you. Sure. This is Duane O'Brien. He works at Indeed in the open source program's office. And we're here today to talk to you about, see now it looks bad. There's no sustainability problem in FOSS, except that there is. So we actually, the name, the title sustainability is actually in our slide. And so we actually wanted to see if we could get some ideas about things that have been called sustainability problems recently. We have, is there any way we can get it to present on? What, you want that? Well, no, it's just, it's off the screen. Oh, I'm sorry. It's okay. That's off the screen? Yeah. No, man, left side, left side, problem. Interesting. Okay, fair with us one moment. Yeah, it's not, it's the- It was fine when we, let's just take it out and present our mug. Okay. Sorry, guys, just one sec. It's actually kind of hard to see. Yeah, I can't actually see where this is. There we are. Technology. Just present. And I think it'll auto-scale. Yes, that looks so much better. Okay, thank you. I'm glad we took that second. So we wanted to talk about things that have been called sustainability problems in our ecosystem. So we highlighted some news articles here that we've seen blog posts. This open source and sustainability blog post from the open source initiative is published in 2008, if you can't see that. So people have been having this conversation for quite a long time and in quite a lot of different ways in a lot of different contexts. So have people, are people familiar with the sustainability conversation? Have you heard it come up in news? Have you read articles? Have you had conversations with other people about sustainability? Can I see just approximate hands? All right, so quite a few people. Anybody want to hazard a guess or hazard their own definition for what that means? What does it mean when you are talking to someone about sustainability? We're friendly. It's an interactive. Say again? Consistent availability of participant time. Who has a completely different definition of sustainability than that? Right there. Money, all right. So it's not about time, it's about money. Who has something that isn't time or money? Ability to remain consistent, it sounds like. Okay, okay. A third, fourth, fifth? Devin's a cheater, but yeah. So ability to depend on our infrastructure, maybe it's done or maybe it's not. So as you can see from all the different answers in the room, there's no one consistent definition. There's no one consistent way people are talking about it and there's no shared understanding. However, there are lots of conversations happening around sustainability and there's lots of programs that are meant to address sustainability problems. And we would even go so far as to say this is actually diminishing the problem. Because there is no consistent definition and because we're often trying to apply one hammer to a bunch of different kinds of nails, we're ending up in a situation where we're calling a lot of different things sustainability and it's actually unhelpful to the conversation entirely. There's also no one particular solution. There might be different solutions to different kinds of sustainability problems and depending on your understanding and depending on the remedies that might be appropriate. So the previous talk queued up some events or issues that have come up in recent years. There's a chance that they will come up in every talk so they're gonna come up in ours too. It's this one, I'm gonna close this. All right, so we're talking a little bit about Heartbleed, we're gonna talk a little bit about Left Pad, we're gonna talk a little bit about Event Stream as well. And I'm gonna give a super redacted version of the events for each one of these and we'll take a look at are they sustainability problems, are they problems or are they issues that came up because of sustainability or are they something else? I also wanted to point out on this slide just some of the headlines and how exclamatory they are. One programmer almost broke the internet by deleting 11 lines of code. Hacker Backdoor's popular JavaScript library. What Heartbleed taught the tech world, the entire world has apparently learned from Heartbleed or maybe not. So obviously not only is this conversation happening, there's a lot of different kinds of conversations happening about sustainability, but people are scared. People are fearful and I think that's also colorant. We also think that's coloring the debate as well. Sorry. All right, so the shortest possible version of events that I can give for Left Pad is a developer got angry. They deleted their projects from NPM and the internet breaks. Now that was the headline we saw on the previous article and it was actually the way it was categorized in the previous talk as well. The entire internet broke when Left Pad was taken down. That's a little dramatic. The entire internet didn't break. But this was the shortest possible versions of events and the nature of the actual disagreement came about because there was a conflict about the namespace the developer was using and NPM had come down on the side of the trademark holder. So is this a sustainability problem? Yeah, so this actually was a dispute about an entirely different package than Left Pad. The developer actually ended up taking down all of his published NPM packages after this dispute. But it ended up being the case. We all found out in hindsight that hundreds, thousands, tens of thousands, millions of people had depended on these 11 lines of code. And so when he took down these packages and huffed all the people who depended on it or maybe didn't even know they were depending on it ended up in a difficult situation. Is this a sustainability problem? So a lot of enterprises, a lot of really big companies were affected by the Left Pad events. And a lot of companies were very upset that someone would take down NPM they were depending on and first of all, could they have written those 11 lines of codes themselves if it was so crucial to their infrastructure? And if we had applied more money, more time, more developers, more resources to Left Pad, would that have actually solved the problem? Would that have prevented people from having taken the dependency on the thing and then having it unpublished? No, he would have unpublished it no matter. It's, I would pause it. He would have unpublished it no matter how much time, money, energy, resources he probably wouldn't have if NPM had sided with him but that's not a sustainability problem and it probably likely has a different solution than the other ones we're going to talk about. Oh, sorry, yeah, business responsibility. So like I was saying, enterprises are all dependent on Left Pad. If you're an enterprise that's dependent on 11 lines of code that if it's taken down will take down your infrastructure. Whose fault is that? Whose problem is that? I would go so far as to say you made a poor business decision far, far, far before that Left Pad package came down that maybe you're kicking yourself about. Maybe you're quite upset that that package actually ended up causing some kind of problem to your infrastructure depending on the urgency but even still, why were you depending on it if it was so crucial to your infrastructure? Why didn't you have potential remedies and fail safes for those things being taken down in the first place? That's not the open source community's problem to fix. So that is a business decision, business risk analysis you needed to make. So the good news is that clearly we learned something from Left Pad because later on we had Event Stream. And I'm being maybe a little facetious there but I do actually mean it. We did learn something from Left Pad and that is demonstrated by Event Stream. So the shortest possible version of events is there was a stable node module, the maintainer was no longer interested in it, a stranger showed up and offered to take over the project and the maintainer said yes, and then the stranger used the project for malicious purposes. Now the reason I say that we learned from Left Pad and we can see that in Event Stream is that for the most part, this didn't break the internet, that wasn't the headline. It was there, check your repose, there might be sneaky crypto stealing code in there. So that's an improvement, it's still a sensational set of headlines but I will once again, is this a sustainability problem? So this I would say is a divested responsibility problem which is if there are vulnerabilities, if there are problems in other packages, you have a responsibility in depending on them to apply responsibility appropriately here. Again, this is a question of would more time, more money, more developers applied to this particular situation to have actually solved the problem. Well, there's another aspect of this that is, this was a poor judgment on the maintainer's part and I had a personal issue with some of the response from the maintainer because they took the position that they weren't getting paid for it and what do you expect and seemed to not feel like they had borne a sense of responsibility for it. So maybe not a good judgment on their part but let's entertain for a moment the idea that had this been done by a well-supported, well-maintained, well-supported, well-financed, very healthy work-life balance maintainer, had they just decided one day that they wanted to put crypto mining code into all of their JavaScript dependencies, nothing about this would have been prevented, right? So there's nothing about sustainability that created that particular problem, right? And the only thing really preventing a good actor from changing into a bad actor and doing this, we're just kind of taking this on faith, right? So not really a sustainability problem, maybe some judgment, but not a thing that would have been prevented by pouring more money or time into the project. And heart bleed, and I was probably kinder to this one, there was a widely used library, it had an undiscovered vulnerability, one that had been there for over two years. And the discovery and awareness around it created a huge, huge initiative to drive hundreds of thousands of updates onto public web servers, it was kind of a big deal. And in the process of doing this, of course, the project skits heavily scrutinized, we recognize that it has maintained as a limited volunteer effort, famously two guys named Steve, right? From responsible for securing the internet is a headline that was going around. Was heart bleed a sustainability problem? So I would actually say that of the three cases that we've presented, this is likely the most, the one I would most want to call a sustainability problem because it highlights our interdependency on each other and the fact that one vulnerability introduced into the system can actually affect all of us and that even if we take good remediation, good caution around those things that we can still be subject to these things. And in fact, we're living in the FOS ecosystem in a world in which one thing can affect many, many, many of us. And in this case, as Dwayne said, this was a vulnerability that had been in this for two years and if there had been more security research applied to this, maybe it would have found, maybe not, but there could have been time and potentially developer resources applied to this and potentially it might have been mitigated if not avoided entirely. But this is a much different problem than the other two that we've mentioned and a potential solution would look much different to this than it would to the previous two as well. I think we're just on the next slide. Okay, so there isn't one, there isn't a sustainability problem in FOS. There are many, right? There are dozens of different categories of problems that may be related to sustainability. And there are other issues in the ecosystem that have nothing to do with sustainability that often get thrown into that same bucket. I remember the thought that I was going to raise about interdependency, one of the problems that we encounter as people who work in open source program offices is the problem of trying to balance the signal to noise ratio, so here's what I mean. I have a compliance tool that runs on a regular basis that tells us, in addition to the license obligations that we have, the kinds of things that we are using, there are thousands and thousands of direct dependencies in this list. Which of them should I help? Which of them need help? Which of the updates are most important for us to be paying attention to? There's a tremendous amount of information there. And I think funding is a really interesting thing to talk about for the person who raised it as money, right? There are thousands and thousands of dependencies in this list. Do I give all of them $10,000? That's very quickly cost prohibitive. And I know for a fact that many of them don't want that. Some of them might want five from coffee, right? So trying to figure out in this vast sea of information, like which projects want what kind of help and need what kind of help is a very big problem that is only felt from inside the context of an organization that is highly dependent on a wide array of open source projects, especially across different ecosystems. And so just to underline that, and what we need to do is we need to have many different kinds of solutions to the nuanced conversation about sustainability. So if all you have is a hammer of money to apply to FOS liberally, fair enough, that that might actually be the answer for some things. Maybe more money into security research and to vulnerabilities in a particular ecosystem or a particular language, what have you, might actually solve some problems. But that's not going to work for all of them. In fact, it may be the case, as Dwayne said, that they actually actively don't want the money. And we need to find multiple kinds of hammers for multiple kinds of nails. And we also need to be having the nuanced conversation recognizing the places where it's not about sustainability that making poor decisions for yourself is also part of this conversation, making poor business decisions is part of this conversation. And then our interdependency is also important to recognize as well. So I want to unpack just a little bit of what's on the slide here, right? Because without any additional context, these might look harsh or unkind and that's never their desire. If there is a maintainer who has a job and is also maintaining a bunch of projects in their own personal time and finds that they are pouring so much time into those personal projects that they're burning out, in addition to there being some other kind of problem, there are problems around boundary setting for the project and the maintainer, right? As a maintainer, you are not obligated to say yes to anything, right? What will be helpful is for the project to clearly state these are the, this is the scope of the project and these are the, this is the level of commitment that I have to this project right now so that adopters who show up to use it understand what they're getting. So maintainer burnout because they're overinvesting personal time in their projects is at least as much about boundary setting as it is the other factors that come into that. There are definitely projects that have grown much, much faster than the support structure around them, right, in popularity and in usage and consumption and we could debate and Carol and I have at times about the role the company should play in establishing some policies around the technology that is adopted there so that you're not adopting technology that is growing faster than it's getting support but for projects that have grown faster than the supports, those are important for us to mobilize in support if they're that important. I cannot say there is not a problem with companies over consuming open source and under giving back, right? So we definitely should be working within our companies across the board to make sure that we are giving back in some amount of proportion to the value that we're deriving from those projects. Signal to noise I've already talked about a little bit and there's also a problem for the company's bare responsibility for where the emphasis put so much on developing features and pushing out new product that there is no time allotted for developers to maintain and support the things that they have brought into the company, right? If a company is running on seriously outdated free and open source software, the odds are they have prioritized feature work which is profitable over the maintenance work which is equally important and that is a problem of balance that we have to shift. Yeah, we have a couple of minutes for questions and I will repeat the question for the folks on live streaming, yeah? So the question was of the five that we have up here which one would be kind of the low hanging fruit or most prolific? I'll take a swing at that. Like it kind of depends on what tree you're standing next to, right? From my position running an open source program office the lowest hanging fruits, the things that I have most immediate ability to impact is our company's role in supporting and maintaining our dependencies and it's sort of been the focus of the work that I've been doing there for the last couple of years. That is a very different tree to a maintainer, right? So it might be a bit of a cop out because I'm not gonna give you my opinion but my challenge then is to figure out which tree is closest to you that you can affect and mobilize the people who like you can affect that particular tree. That would be my answer. Other questions? So the question is if we for a second set aside in event stream the good actor versus bad actor how is that different from Heartbleed and therefore probably a sustainability problem that you would apply resources to? I'm not sure. I'm not gonna come down either way on answering like maybe it's no different or maybe it is but there is a thing that I'll say. There was some conversation in the previous talk about automated dependency updating and tooling to enable that. Tools like Renovate, tools like Dependabot and Green Keeper and David and there are a number of others that sometimes are ecosystem specific and so on because it's seeking to reduce the toil of getting on top of this ever growing tens and thousands of dependencies problem of keeping things up to date, right? If all they're doing is making it easy to update it doesn't really solve the problem. Does anybody have automated dependency updating going on a project right now? Okay, a few of it. Anything built into that process to see what the nature of those different, what the difference is between the thing you're updating from the thing you're updating to, is it just, yeah. Without that, event stream probably would have hit a lot more people, right? We automatically updated to this thing even if it went through the code paths and said, hey, the code paths that we have in here have coverage. It doesn't mean that it's gonna prevent it from doing what it was already doing and also this other little thing that you didn't know about. So it is a big complicated problem. We can apply more research to it and apply more either effort from security or dollars to security, but I will also come back to that question of the thousands of dependencies in my inventory. Which ones are, I can get pretty close to which ones are most important to start by how often they show up, but we know that figuring out which ones of those are really critical for us to be taking a look at is a hard problem if it wasn't we'd have found it already. I was just gonna add onto that, that I think that really highlights that this is a very nuanced conversation and we need to have it in a nuanced way, which is if we, we have to look at each of these problems and consider that there could be multiple ways to have solved it or to have avoided it and that some might look like others, some might be solvable by money, some might be solvable by having more developers, some might be solvable by more contributions upstream, whatever the case may be, and that it might be the case that they look very similar, but that we need to have the nuanced conversation to understand the nuance and the potential solutions. We still have time to take a couple more questions, so if you have one, by all means put your head up, head up, hand up. One of the things, one of the points that we didn't make but wanted to make was that painting everything with the broad brush of sustainability makes it difficult to know what we're really talking about, so if the only thing that you do after this talk is when someone says there's a sustainability problem, if you say, what specifically do you mean you can at least make sure you're on the right page and then I saw a couple hands. Having that relationship with the dependencies to me is the strongest way to avoid this problem. Sure, how many developers work at Microsoft? Best guess? 60,000. That's how, right? You could do it, maybe I could do it. And maybe there's 600 different projects and maybe they break down into teams of six and you can establish a policy that you shouldn't consume anything that you don't know, but even if you're only talking about direct dependencies, the odds of that really happening, I think, are low, right? It's a good place to be. It's a good place to attack. I'm sorry? I agree with you that that's a good place to start. And there's some validity to that, right? If you have 25 different libraries that are managing date formatting, you can probably do better than that, right? Are there other questions? Well, we have two minutes. I think we should probably, okay, one last question. Okay. Thank you. Thank you very much. Thank you.