 OK, so we're back again with another great talk towards a sustainable solution to open source sustainability. The speaker today is Toby. And he is the founder of Unlock Open, a firm that helps large organizations build a strong open source culture with clients such as Google, Mozilla, and Intel. He's also the facilitator of AMP's advisory committee, member of the OpenJS Foundation, and on the advisory council of Oasis Open Projects. He is known for having it go maintain the prototype JavaScript framework. He's also edited a number of web standards. So we have a great speaker here with us today. Over to you, Toby. Well, thank you very much. Can you all hear me? It sounds like so. Well, thank you for having me today. I just had a power cycle issue and just literally got back on time to do the talk. So if I'm a bit out of breath, that's going to cool as the talk goes in. So today I want to talk to you about the question of open source sustainability. And for this, I want to start with something that happened now a while ago. I don't know if any of you are familiar with this logo here. That is the logo for the Heartbleed Bug. And what is the Heartbleed Bug? Well, it was a critical vulnerability that affected the OpenSSL library in 2014. And what was really important about this bug was the fact that because the OpenSSL library is responsible for something really important, securing network communications in Unix systems, and because Unix systems are ubiquitous, OpenSSL and that vulnerability essentially impacted roughly about 2-thirds of the web. And the outcome of that bug was, like a number of really large issues, the estimate cost to the industry was about half a billion dollars. And it had some really bad impact, for example, and that's just only one example, 4 and 1 half million medical records of US patients were compromised. So the reason I'm talking about this particular bug today is because it's a pivotal moment where the tech industry suddenly realized that OpenSSL, this critical library, was an open source library that everyone was relying on and well, 2-thirds of active sites were relying on and that it was an open source library and that it was critically underfunded. This really important piece of software essentially had one full-time maintainer and really had this tiny budget on which it was functioning, which was roughly $2,000 a year. So when you think about the amount of transactions and really important communications that go across OpenSSL, that seems to be like this huge discrepancy here. And that kind of triggered a moment where the industry really realized how underfunded and how unsustainable this whole infrastructure on top of which so many things today are built actually was. And that's when we really started hearing about the problem of open source maintainer burnout and really that really raised and put a spotlight on the question of open source sustainability. And we really started seeing the community sort of talk about these issues more broadly in the industry, really, considering them seriously. And so this triggered a number of responses. And what I want to do in this first part of the talk is actually discuss some of those. So one of them, the first thing that happened really quickly is the core infrastructure initiative. And this was an industry-wide effort led by the Linux Foundation and backed by some of the largest players in the tech field. And it had a multimillion-dollar fund that was administered by the Linux Foundation and a steering committee of industry security experts. And the goal was really to make sure that we wouldn't ever again have to deal with something like the hard-blade bug. And so really clarifying what the core infrastructure of the internet was in terms of open source projects and to make sure that they had the necessary funds and resources to operate in a sustainable way. What's important to notice here, however, is that this infrastructure was really focused on, I mean, sorry, this effort was really focused on core infrastructure. And as we all know, open source is way, way broader than just a few important libraries that are everywhere. And so now that the floodgates were open, people and the community and the maintainers and contributors had still a strong desire to solve that problem, not just for a subset of libraries that were everywhere, but more generally, from a more systemic perspective, if you will. And so we started seeing a lot of experimentation. Here, you see Avenue, who is one of the first open source developers who relied on Patreon, a solution originally designed for artist, musicians, and writers to create for himself a revenue so that he could be able to work on view.js. And because sustainability is often a question of essentially resources, you'll see that in this talk, we're going to talk a lot of money. I know this is unusual in the engineering and development space, but I think it's really critical to start building that perspective of how open source interacts with resources, how it creates value, and who captures that value. So that's why you'll see a lot of really talking about dollar amounts. So he was able to make roughly $17,000 a month through that system, which is a really decent amount of money to build a sustainable, self-owned business. And the question is, is this reproducible? And it feels like there aren't that many cases of individuals having been able to create such a system for themselves that is sustainable. We saw lots of other efforts of that similar nature. Gitcoin is one interesting such example. So it was essentially an originally an issue market where the idea was to be able to make it easy for people to come and contribute to a project and get money instead for their work. So you would have open an issue, add a bounty to that issue, and then people would come. You would help them figure out what the issue was exactly. They would solve the problem. The probe across would be merged and they would be paid. So that was blockchain-based. And there was a reasonable amount of money that was sort of exchanged on that platform in 2018. I don't know the latest numbers. But I don't think it has dramatically picked up. But there's still this decent amount of money. And what's interesting with Gitcoin is that there's a whole ecosystem. There was an ad network that now has disappeared. And also there's a patron-like solution called Grants. So Code Fund was an ad network designed to help open-source maintainers make money by advertising, creating contextual privacy-focused ads on readme's or on the project's web pages, really focused on hiring developers. So that could be privacy-aware, because you didn't really need to track people. And that had a roughly $6,000 per month revenue distributed to maintainers out of $10,000 that were made. It's being closed, and Code Fund now suggests people instead go rely on ethical ads, which is doing something fairly similar and has a similar origin story, which was relative fund-sustainable open-source development. And they've served a lot of ads. We don't have details on how much money that is, but it's also sort of an interesting way to attempt to make open-source development sustainable. We've also seen a lot of VC interest, and increasingly so. A big fund is OSS Capital. And there is increasingly considerations of open-source software as venues to build businesses on top of. But of course, that doesn't address the whole set of open-source and sort of the different types of open-source projects and people involved. We've seen numerous crypto-based solutions, too. That's really, there's a lot of interest right now in trying to somehow have corns attached to, commit. And there's a lot of work going on. There's nothing really specific or particularly successful that we can point to. Some people have even suggested using NFTs for that kind of stuff. So there's work in that space. Nothing really highly conclusive for now, but it's certainly something that we want to pay attention to. Of course, open-collective has been doing a lot of very successful work in the space. What is open-collective? Well, it essentially provides non-profit status to open-source projects, which they don't have otherwise. And that helps them, makes it easier for them to be able to receive money and share that money. So there's real success stories for open-collective. For example, Webpack has been making substantial amounts of money from it for a long time. But as most of these solutions, there's really a long-tail problem, which is that the bigger projects get all of the money and the smaller ones really get crumbs. And so because we have all of these dependencies, open-source projects that are more underlying libraries tend not to really be easy to fund. And so that's a problem. And that is a problem that open-collective has been trying to address was Back Your Stack, which essentially helps organizations and even open-source projects themselves to identify not only their open-source dependencies, but the dependencies of these dependencies. And as a result, sort of try to fund the whole tree of dependencies that they have. So that's an effort in that direction. And there is something similar that is being attempted by TitleLift, which is trying to bring Red Hat's business model, but for this long-tail. And the idea here is that it provides the kind of security and peace of mind in terms of security and compliance to companies building on top of open-source software for a fee and it uses the money that it receives to fund itself, obviously, but also to pay the maintainers to actually be maintaining the projects and making sure that they stay secure and stay up-to-date. Well, we've seen also GitHub sponsors more recently take off. And so there's a lot of things happening in the industry quite clearly to try to help this problem. And now I have talked about a lot of the exciting things. I also wanna start giving a broader perspective and really sort of ask the fundamental question of like, is this really, are we moving towards a sustainable solution to open-source sustainability? And so as you can see from this, like there was, yes to some degree, but we're like very, like these are the very first steps in the long journey. So here are four key limitations of addressing open-source sustainability through this notion of helping to fund open-source projects, right? So the first question is, does it scale? The second question is, well, is really money what's missing from these projects? The third question is, well, even if that solution scales and money is missing, is this a desirable outcome? Like, is this idea of having corporations build a proprietary software on one end and sort of fund open-source software on the other and have this real split between developers writing sort of glue code in proprietary systems and open-source developers building like critical infrastructure on the other a good solution. And then the last thing I wanna touch upon is what is the real value of open-source and isn't it time for us to stop just considering the software itself and have a broader perspective on the value of open-source? So let's start with, does it scale? And for this, I'm going to use a set of picture, well, diagrams really that come from the monocracy that he was allowed to use. So, you know, this is a $100 bill, right? And so when you put $100 times a $100 bill together and mix this nice little stack of $1 bills and that's $10,000 and that corresponds to roughly the monthly revenue of Code Fund, the ad solution that I've talked to you earlier on. Now, if you take a hundred of those you get a million dollars, right? And this was, some of that data is a bit old at this point, but this was the amount of money spent, well, collected by Open Collective in 2018, I think it's more today, but not that much more. And it's the amount that TitleLift committed to pay developers from the funding it received. That's a million dollars. So, let's quickly jump to look at what the worldwide developer population looks like and try to do a comparison here between how big developing and software development in the world is compared to how much money we're trying to fund open source was. So, that data from the Worldwide Developer Census in 2018 shows that there's roughly 20 million developers in the world, about half of which are full-time and about a quarter of which are part-time and then another quarter, roughly speaking, as non-professionals. So, let's do a quick back of the envelope math here to get a sense of the overall market. So, if we'll look at 12 million full-time developers and give them a $65,000 average cost for a year, that's really low for Silicon Valley, really high for other parts of the world. This is really back of the envelope math, so bear with me, right? That's, it creates a yearly sort of cost to the industry of $780 billion, right? Now, if you add to that, about 6 million part-time developers estimate the cost of those at $35,000 a year, that adds another $210 billion, which makes a total of $1 trillion spent by the industry, yearly on developers, essentially, building software. So, going back to $1 million, let's look at what $1 trillion is gonna look like. Put 100 of those stacks together, you have like this nice crate, was $100 million of those. Get 10 of those together, that is $1 billion, right? Now, if you put 100 of those crates together, you get $10 billion, and you can see for scale the truck and the little person down there. And in order to move to $1 trillion, you really have to stack 100 of those together, right? And that is what a trillion dollar looks like. So this is roughly the amount of money that the industry spends on engineers building code on a yearly basis, right? And when we're talking about funding of open source, you can look at that tiny person down that money skyscraper, and that is that small stack here is a million dollar. So we're roughly talking about spending, you know, five, 10, maybe even 20 of those million dollars. And so there's this massive discrepancy that we can't not acknowledge. Okay, so secondly, is money what's even missing? And so if you look at developers working on open source software, what you realize, and that depends on the kind of projects, but there are projects that we have really good data for. Here is the Linux kernel, sort of an outsider in that space, but it's really important to notice that 93% of contributors in 2016 were actually employed to work on this project. So, you know, by throwing money at developers, are we actually really solving the problem here? It's not so sure, right? Okay, so, you know, we're not spending enough money, clearly we're not sure that money is actually the right solution to that problem. Let's look at, you know, whether this is actually a desirable outcome, you know, for the space or not. And so I wanna actually quote here something, a quote by David D. H. Hage that is a number of years old at this point, which I think gives an interesting perspective on considerations that we should have here despite some of the latest issues that has happened in the space was some of what D. H. H. H. and Base Camp have been going onwards. I'm probably gonna remove this slide in the future, so apologies for being here today. But I think that the quote still stands as something that's important, which is that part of the reason much of open source is so good and often so superior to closed source commercial projects is the natural boundaries of constraints. If you're not being paid otherwise compensated directly for your work, you're less likely to needlessly embellish it. You're solving the problems for you and your mates. Let's see, here's a problematic term, likely in the simplest way you could so you can get back to whatever you originally intended to do before starting to shave the yak. And what's interesting here to me is this notion that open source is really good when the people building it are actually building tools that they need to solve the problems that they are facing right now and that it is better to have this back and forth of engineers working on the specific problems and on open source parts to solve parts of those problems rather than really split up. I have open source developers on one side and commercial developers on the other. So the last thing I really wanna touch on is what is the real value of open source? And if you ask what the value of open source is to people in general and corporations in particular, you will have the answer that it is the code itself. And so the idea is essentially like corporations use open source and they use open source that's in the pool of commons and then they fund open source by essentially giving money or throwing money at the problem, right? Was to hope that then all of these developers that receive money are going to continue contributing to the commons. And so the perceived value is really the code. In reality, what we know about open source and what everyone who is involved in open source projects is fairly familiar with is that a lot of value comes actually not so much from the code itself but from the practice of building that code and from the interactions, the confrontation of different requirements, different needs, different cultures, different use cases that come from working together on a broad, was a broad set of engineers on this problem. And so really a lot of the value is in helping those engineers that participating in open source grow, learn from each other. And there's a lot of data today that really backs up the fact that working in open source is actually highly beneficial for engineers in terms of both technical skills but also in the soft skills, the network and their ability and their career essentially. And so right now what happens is all of this value goes away and is not really captured by those corporations that are actually hoping to do so. And it goes away while it goes to the developers, the open source developers that are involved, right? But corporations are actually not on these like entities, separate entities, they are full of engineers themselves, right? And if we start getting these engineers to contribute to this pool of commons, like we saw was the Linux kernel before, they start getting these interactions with the broader community and they start benefiting growing from that and bringing that value back to their corporations. And I think really the key to open source sustainability is not just throwing money at the problem, is making sure that the industry, the broad industry understands that there is a lot of value for them as organizations, as companies working in that space to actively participate in open source and benefit from building those networks, building that reputation in the field, becoming more attractive to developers and essentially leveling up their engineers as a result, right? So really again, charity like funding alone is not the solution. The real way forward is to normalize engineers contributing to open source as part of their day job. And the question to how well again, it's to make organizations really understand the return on investment of contributing to open source. And that concludes this talk. I think we have a few minutes. I don't know if we can take questions, but I'd love to do that if that was the case. Hi, Toby. So we do not have any questions right now. However, the audience does have a lot of remarks on the talk. Like I think everyone found it pretty engaging. If there are questions, we can wait right now. And I will post the questions here if they show up. Otherwise, I think the audience and you can like chat in the breakout room. That sounds great. Yeah, I'm fine with both. And I mean, I'm happy to wait a couple of seconds if there is a question. And if not, really, I'll let you handle this as you want. Okay. I saw no question. That was me not editing it. But yeah, we do have a question. Let me just bring it up here and okay. So someone's asking, what's the best way to start with your first contribution? That is a great question actually. To go back to this point, I was trying to make in the middle that there was a lot of value in bridging the work that you're doing for the application that you're working on and open source. I think the best way to start your first contribution is actually to go solve a real problem that you have was an open source library that you're relying on and to build whatever it is that you're building for your work or for yourself. So really, really link that first contribution to your work rather than have this completely split story where you're working your work on one side and then the other, you try to find a good first issue in a project. So really for me, like incurring this in your actual day-to-day work and sort of creating, fuzzing the frontier between what is work and what is open source and making sure that you're able to move from one to the other is really the best way to get in this kind of like the right mindset and the right culture. So that's what I would recommend. Of course, that's not always possible to do. And if that's not possible, I would suggest finding a project that is closely related to something that you care about and then seeing if that project is welcoming and welcomes new contributors and then attempting to solve a really simple problem. And to tell a quick personal story here, I started in open source now like close to two decades ago because I loved a JavaScript project called the prototype JavaScript framework. And there was no documentation for it. And I didn't know how to code JavaScript. I didn't know how to do software development at all. And so what I did was looked at the code and started documenting it. And by doing that, I learned how to code really. I shared that documentation that created value and really sort of like started my career in open source. So it's not only code contributions that are valuable and it's just way broader than that. And it really is about focusing on something that is achievable for you, lightweight and brings value. Okay, so thank you for that answer. We have another question that has been asked by many of our viewers and we do have a minute to take it. So... Let's have a try. How do I convince my boss to let me work on OS? That's the biggest problem. Again, I would start with small steps. Try to identify one place where doing so would actually create value for the company. Maybe you're maintaining a fork of something because there's like a tiny feature that you need on top of it. Try to explain how much easier it would be and how much easier it would be to keep that fork up to date and secure if you just upstream that little bug. Start small, small steps and really build from small steps and try to grow from there. Okay, thank you so much. You're welcome. It's been a great talk and the audience has loved it. So yeah, let's... Wonderful. Well, I'm happy to take more questions in the chat. In the breakout room. Yeah, in the breakout, absolutely. Thank you so much.