 Thanks, thanks everyone, coming along. So I'm going to be talking about open source sustainability through corporate social responsibility. Yeah, I know, it's going to be a bit preachy. So bear with me. The first thing I want to talk about is sustainability. So you may or may not have heard, but there, there is a sustainability issue within open source in general. And it's something that I've, I've heard about, I've read about, but I wanted to explore myself to find out, you know, just what, what are the issues and just how real is it? So what I did was I picked a project, a project that I know well that I've used a great many times and I started asking myself some of the difficult questions. So the project I picked was Express.js. If you haven't heard of it before, it's basically the de facto web server for Node. It's very widely used 50,000 stars on GitHub, 14 million weekly downloads, 10 years old. It's part of OpenJS Foundation, which is itself part of Linux Foundation. So it's a very well established open source project. So, you know, my first interactions with it were, it's fantastic. It works really well and even better, it's free. You know, what's not to love? However, I thought, okay, it works really well. It's free. If I'm going to build, I don't know, a payments platform on top of Express.js, I'll probably better do a little bit of due diligence and find out a little bit more about who's behind this code? What are the licensing constraints? You know, what am I actually buying into here? So the first thing I did was I started to look at how is Express.js actually composed? Now Express is a single project. However, as a project, it currently has around about 48 dependencies. So by using Express, I'm not just using Express, I'm using 48 open source projects. Interestingly, I downloaded the data and had to look at how the dependencies of Express.js changed over time. So what you can see is over its 10-year history, over time, the number of dependencies grow. It becomes more complex over time. And then at the major version increments, typically, the maintainer or the author will take a look at all these dependencies, and they will do some significant redesign. They will consolidate and they will reduce their dependencies again, only for them to start creeping up. Now, this is a chart for a single open source project. However, I'm going to sort of extrapolate somewhat. From my own personal experience, projects, open source projects are becoming more complicated in nature, more often than not, we are now using not tens of projects in our production code, not hundreds, but more often than not, I'd say, thousands. So yeah, I'm a little bit worried. So rather than now checking Express.js to determine the suitability, I now have to check 50 projects to determine their suitability, because that's basically what I'm buying into now. My problem just got a whole load more complicated. However, that's not the end of the story. Express.js has 49 dependencies. It actually has 195 development dependencies. So if you're not a developer, just to explain this, when Express is maintained and built, the tooling around Express.js is itself open source. So Express is written using languages, using CI tooling that is itself entirely open source. Now, does this matter? Well, actually, it matters quite a lot. You may or may not have heard of software supply chain attacks. This is a growing concern where if I want to do something malicious to Express.js, rather than attack it directly, I can attack the tool chain that's used to build Express.js. And this is a very real issue. There have been some quite high-profile supply chain attacks. There was one quite recently where a cryptocurrency wallet was targeted and a significant amount of cryptocurrency was stolen as a result of a supply chain attack. But cryptocurrency, it's not real money. So what does it matter? I'm starting to get a little bit concerned now. But things get a little bit more complicated. How do I know that the code I'm running is the same as the code you're running? Now, typically, what we use to communicate this is version numbers. However, developers in their infinite wisdom like to make it a little bit more complicated. There's a concept called semantic versioning. What this means is you state, I would like to use version five of that project, but I don't mind if it's 5.1 or 5.2, but don't give me version six. It sounds relatively logical. However, what this means in practice with Express.js specifically, between version 14.16.4 and 14.17, there were actually 33 different configurations within the seven month window. So the chart that I showed you earlier about the dependency graph of Express.js changing over time, replace that with a more complicated graph. Things have got a lot more complicated. And again, what I'm trying to verify here is, is the code that I'm running safe and secure. Now I'm starting to worry, do I know what this code actually is? Yeah, I'm getting a little bit worried now. So the way that you use this code typically is you download it from some external repository. And the next logical question I asked is, who holds the keys? So at the moment, there are 49 dependencies. I went and had a look at how many maintainers are there behind those dependencies who have the privilege to publish a new package. I found that there were 88 of them. Some of the packages had a significant number of maintainers, some of them had far fewer. Again, does this matter? Well, as I mentioned, supply chain attacks are an issue. Also, of these 88 maintainers, I have the email addresses of every single one. What I discovered is the repository that they use npm only 7% of users have two factor authentication turned on. So what that means is in practice for 93% of these 88 people, all I need is their username or email address and password. The very first email address I typed into one of the websites that allows you to determine whether an email address has been compromised in an attack came back positive. So for this, the very first email address I've tried, it had been compromised through LinkedIn, through YouTube, and I think I don't know whether it was Instagram, something like that. So there's a very real possibility that for these 88 maintainers, I will be able to find a password that they've used in a social media account. They don't have two factor authentication turned on, and I bet some of them password recycle. I didn't try it, but I'd be willing to bet that I can find my way into Express.js through its dependency graph. Are you all scared yet? Because you should be. The next thing I wanted to ask is, who's keeping all of this safe on my behalf? It's a great worry of mine. Surely there's a whole team of people that are keeping this safe. Actually, that's not the case. Express.js is maintained by a single individual. Over the past four years, the vast majority in the high 90%, the vast majority of commits on Express.js have been from a single individual. So there's one person bearing the weight of this complex infrastructure, all these attack vectors. This is this is pretty worrying. What's even more worrying is that particular individual is not terribly happy. And I must admit, I wasn't expecting to find this. It may seem a little contrived. I picked Express.js entirely at random. I wasn't expecting to find that it was maintained by a single individual. And that single individual was very close to burnout. Just to get I mean, I've blanked out their name. You can find it. It just didn't feel right putting it up on a slide. Just to give you a bit of context, what happened here is Express.js is a web server. One of the security companies had found a security vulnerability within that web server. And they had released a, what they called CSR or so. Basically, they had they had published a vulnerability that a large number of large organizations had then picked up on. And they descended on mass onto this project and said, you have a critical vulnerability, you really need to fix it now, please. And you need to fix it this way or that way. This one guy, all of a sudden faced with a flood of people telling telling him what he should be doing and why he was causing them problems. Basically, you know, closed his laptop and walked off for a week. He said, I'm not dealing with this anymore. So we have a pretty big problem in open source. And as I said, you know, I picked a project at random. I'm pretty confident if I pick another project at random, I will see similar problems. So what are the current solutions that people are advocating at the moment? Money, it's clearly the solution to pretty much everything. Surely, the problems with open source sustainability can be solved by just throwing a sufficient quantity of money at it. Yeah, makes sense. So what I did was I had a look again at Express.js, I had to look at all of the 195 dependencies to see whether any of them had a funding model out of all those projects. I found one. ESLint. Again, you may or may not have heard it, but head of it. Basically, it's a tour. It's a code style code formatting tool that's really quite well well known. ESLint is funded by a by an organization called Open Collective. It has charitable status in the US. It's a very simple model. You make donations to a project and they make sure that the project maintainer spends it on spends it wisely. You know, you submit invoices and so on. So it's a decent mechanism for allowing you to to fund open source projects. That's great. Well, what I did, you know, I like downloading data. So what I did was I looked at the top 100 projects within Open Collective. I scraped all the data from the website. And what I was fine, trying to find out is how much of an impact does Open Collective realistically make? So what I found was taking the taking the budget for each of these projects, I wanted to turn into full time equivalent. So I wanted to say if this budget was being used to fund the development team, how big a team would you get? ESLint, their funding would pay for around about 1.5 developers. ESLint is the third most funded project. The most funded project will pay for around about five developers. If you look further down, well, if we look at the top 30 projects, the ones lower down the list are pretty much, you know, get a cup of coffee every week. So whilst I think Open Collective is a great idea, it's not really moving the needle. Just to put this into context, it's hard to find good statistics. Well, it's hard to come up with a good methodology for determining the overall value of open source. I've seen varying reports. There was one published by Open UK recently that their methodology pointed to open source contributing 43 billion annually to GDP in the UK. I mean, I don't know whether it's 43 or 40 or 80. Doesn't matter. I'm pretty sure it's going to be in the billions. There's going to be a lot of zeros there. Open Collective in 2020 collected half a million. You know, we've got a few orders of magnitude difference there. The largest funding body I could find was a company called Tiedlift. They've brought in 40 million of VC funding. So it's questionable how much of that will actually get to the open source project. So the funding that exists at the moment is a drop in a much bigger ocean. So that's one potential solution to this problem, money, and clearly it isn't working. I'll tell you the other solution. This is the one that everyone tends to be using. And this is the general concept of build your defences. If there's some nasty stuff going on out there in the world of open source, your best policy is to build a wall around your organization and make sure that this nasty stuff doesn't affect you. And the way that we do that is we tend to pay third party organizations to take away some of the problems and challenges with open source, whether it's licensing, whether it's support, or all these other aspects. And this is generally speaking the way that most banks protect themselves against open source. Again, does that work? Well, it contributes to some pretty big problems in the wider open source community. So these are a couple of interesting quotes I read from a recent blog post. The top one I think is the most sort of eye opening. This was taken from a prominent open source developer who went to an open source conference and walking the floor, most conferences are supported by product vendors. And he walked up to one of them to find out a little bit more about their products and how much it costs to get a license for their products. He walked away coming to the conclusion. So this company charges, say, a 50-person startup $30,000 a year to help them feel safe using the code that open source authors like me have given away for free. So whilst from a selfish perspective, building up your defenses does work, it does have a pretty bad, it results in quite a lot of damage to the wider open source community. And again, burnout becomes a problem. So how do we solve this? You know, I'm not going to be a downer for the entire half hour that you're here. I won't do that to you. I genuinely think that to solve this we need a new direction. And a new direction isn't a different funding model. I think the way to solve this is that we need to change the way that we think about open source. So the first is, you know, fairly obvious. It's understanding and empathy. And a book that I read recently called Working in Public by Nadia Ople is something that is a book that I'd recommend everyone reads. It's a book that really describes the economics but more the social side of open source and asks questions about how does this actually work? How does this sort of fragile ecosystem keep going? And a few very interesting observations that Nadia made is the open source world has changed considerably in the past sort of five years or so. And a lot of that is down to GitHub. Some of it is positive. GitHub is a fantastic tool for open source developers. It's a very good productive platform. I use it all the time. However, what it's done is it's created a highly centralized community. When I first started working on open source, it was actually quite hard to find the communities. Some of them were on listservs. Some of them communicated over IRC. You know, some of you might not even know what that stuff is. But basically the communities were quite hard to find. And what that meant was when people found the communities, they tended to stay within that community. They were quite close near. GitHub has made, has lowered the barrier to entry. But what that unfortunately means is people tend to have very fleeting relationships with the open source projects. People flip from place to place to place. And this has resulted in Nadia describing what she calls a stadium model for open source. What this means is there will be one or two individuals effectively on stage with thousands in the audience. But the quality of the connection between them is very, very poor. So whilst externally, you look back and say, OK, there's, wow, there's 10,000 open source developers. If you look in and you understand that it's a stadium model, it's not, it doesn't have the richness of interaction that you might expect. And the final thing that I thought was really interesting in this book, getting back to the money point. She concluded through many interviews that attention is the most prized asset of most open source maintenance. It's not money. So what this means is they want to focus their attention on specific tasks that they personally enjoy. That's what they want to invest their time in. And anything that takes their time away from anything that subtracts from their attention is damaging to them. And one thing that I found, which was a great example of this going completely wrong, was DigitalOcean. Each year they run a thing called Hacktoberfest. Funnily enough, it started again just a few days ago. What they found, so what the basic idea is DigitalOcean want to encourage open source contributions. That's great. What they did to support that was they gave away t-shirts. Sounds great. What happened was it resulted in a significant number of very low value contributions from people just wanting to get t-shirts. It took away the attention from the maintainers. They found themselves spending a lot of time closing issues, getting into conversations, trying to explain to people that we don't want that stuff. You've got it wrong. They went so far as to call it a distributed denial of service attack on the open source maintainer community. And again, this is what happens if you don't understand the community. DigitalOcean wanted to do the right thing. They didn't want this to happen. But because they misunderstood how the community works and misunderstood that attention is the most prized asset, it all went horribly wrong. Hacktoberfest started again about five days ago. Another thing I want to draw your attention to is the language we use. I've always thought that the phrase open source is a little bit too narrow. And it's it doesn't, to my mind, really describe the community that genuinely exists around open source. A few people talk about open source as our commons. And I think this is a great way of expressing it. So this is, you know, I'm doing what everyone does. This is straight from Wikipedia. The commons is the culture on the natural resources accessible to all members of society, including natural materials such as air, water, habitable earth. These resources are held in common, not owned privately. Most of you will have had experience of commons not just from the air that we breathe, but from things like common land and farm land or fields, areas that you can freely access with a few simple tweaks. It actually works really quite well for open source. So the commons are the software resources accessible to the entire development community, including code, standards and shared infrastructure. These resources are held in common, not owned privately. So the concept that we already have of commons really does work very well for open source software. And I think it's a much better way of describing it than the phrase open source, which is very narrow. It focuses on the code alone. So what can we actually do with this? With a better understanding of the community and a better language, the idea of the commons, can we start, can we take a few steps towards a potential solution to this problem? Can we start asking ourselves what is our responsibility over the open source commons? And this is where we loop back to the idea of corporate social responsibility. Corporate social responsibility originally was a self-regulation, an opt-in concept, where businesses were opting into the idea of some responsibility towards ethical concerns. And corporate social responsibility is a framework that allows you to link ethical concerns with the way that you actually run your business. There's already a model that you can use. Now if we look at corporate social responsibility, this is a thing called Carol's Pyramid, which is a very simple structure for understanding how corporate social responsibility works. So this is effectively in very simple terms, your responsibility as a business. The foundation is economic. Be profitable. That's pretty obvious, whether it's for the sake of your investors, your shareholders, or just simply for the sake of your employees, you have a responsibility to manage your business economically. The next layer up, legal, to obey the law. We all have an obligation to conduct our business in such a way that it doesn't break the law. As we go higher up, this is where these these aspects are optional. The next up is ethical, be fair and responsible. When making business decisions, you're not legally obliged to be fair and responsible, but generally speaking, most people would like to work at a business where they believe that business decisions have an ethical angle to them. Looking back at the previous slides, whilst you could pay $30,000 to a company to protect you from open source vulnerabilities, is that fair and ethical? Should you be diverting that money or the effort equivalent to actually solving the problem? And finally, philanthropic, is my business a net consumer of the resources around me? Or do we give back? So this is the framework that businesses use for corporate social responsibility. So how do we map that onto open source? Well, if we look at the right hand side, starting at the very base of the pyramid, the economic side of things, this is where most businesses evaluate open source from the perspective of consumption. All enjoying the economic benefits of free software, it's pretty much a given the economic model for using open source is really quite easy to understand. And the vast majority of businesses are already bought into that. From the legal side of things, again, this is this is a known entity that the legal side of of consuming open source concerns things like licensing, trademarks, copyright. Again, that's well understood. However, you'll notice there's a gap. There are very few companies that talk about the ethical aspects of open source, the way that we consume open source and use open source, the way that we protect ourselves against some of the challenges in open source. Are we using our resources in an ethical and fair fashion? And then finally, philanthropic philanthropic, I think there are very few businesses that genuinely sit back and say, do we give as much as we take from the open source community? So that's it. I cannot profess to have all of the answers, but hopefully that's some food for thought for you for you all. Thank you very much. Don't know if this time for questions, but I'd be happy to have questions or if you want to chat over coffee, that's fine as well. Oh, we have a question. Cool. Oh, I like the alliteration pyramidal punchline. I'm I'm not a leader of Phinos. I'm a member of Phinos. What do they think about the gaps? I think on a personal level, I know that the leaders of Phinos all care deeply about the wider open source community. It's I think it's I think it's very challenging. It's I think it's taken businesses a long time to understand their ethical and moral responsibility to things like climate change, diversity and inclusion. I think it's going to take another 10 years or more for them to start considering open source as an ethical concern. I just don't I just don't think they're ready for that. Yeah, that's a that's a very good point. And you're quite right. I think a lot of open source projects express maybe one of them node is a great example. Yeah, I think people genuinely a lot of people do this because they want to scratch that creative itch. They do it for the joy of creating. They don't you're right. They don't necessarily want to turn it into a business, but that this is again why I reference Nadi Eggwell's book where to help open source become sustainable, you have to understand that people aren't necessarily motivated by money, they're motivated by different things. And just because they're motivated by different things doesn't mean you cannot help them. It's conversely, it's really weird. It's far easier to get a large organization to write a check than it is to get them to invest some of the time of their people. It's it's weird, but it's a lot easier to do that. Whereas with the likes of node JS, I don't think you should be supporting it by writing a check to help a maintainer focus their attention. You should be doing things like answering issues. You should be doing things like helping them with their documentation. You should be going over to Stack Overflow and helping there. You should be supporting. I mean, I've seen companies help open source maintainers just by giving them travel bursaries so they can go to conferences. There are great many different ways that you can help. But to help you have to have an understanding of what the motivations of those individuals are. It takes time and quite an investment. It's not just writing a check. Cool. All right. Thanks so much, everyone. Cheers for that.