 Gallwch chi a ddechrau y cyfrifur ar roi awr chi gefnogaeth am y cyfrifur a i chi'n gallu anodd ni yw wneud yn bwysig hon i chi'n gweld. Felly, rwy'n gweithio byrddwch y cwrwm ar fy gwestiynau, byrddwch ar wyeb y cyfrifur ar y cyfrifur. Rhywbodd yn oed yn gweithio ddwybr yn gysylltu'r gafodol, o ffwrdd, sgu weld cyfrifirwyr, o'r log ffordd deolпа, o'r log ffordd deolpa. Gweithio byrwyd yn gwneud gan ein bod nhw'n gweithio byrdd y grant, ond rydyn ni wneud y gallwch yn rhywbeth yn eich problem. Rydyn ni'n rwy'n meddwl, yn gyflawn i'r ysgolwyd, ac yn ei wneud i ni i ddaeth y cyfrifio a'r ysgolwyddennig yn ysgrifennu ei wneud i'r ysgolwyd yn cyfrifio o'r ysgolwyd. Yn rywbeth, rydyn ni'n rhan o'r random. Rydyn ni'n rhan o'r ysgolwyd cyfrifio yn gyfrifio. Rydyn ni wedi yw hwnnw'n neud yn gweithio i'r cyfrifio, mae'n bydd y defacto web server mewn node. Felly mae'n ystod ychydig yn fawr. Felly mae'n gwneud yn y ffigurau yno, mae'n fawr o'r 50,000... Mae'r byddoch yn fawr yn fawr. Mae'n fawr o'r 50,000 ystod o'r ddod o github. Mae'n ddod o 14 miliwn ydy yn cymdeithas. Felly mae'n fawr o'r byddoch yn fawr. Mae'n ddod o phobl yn fawr. Mae'n ddod o fawr o'r fawr, mae'n ddod o fawr o'r wneud ydw i'n fawr, about ExpressJS, and see what I find. So, to start off, I downloaded it, started using it, and funnily enough, I was happy. It's a fantastic tool, it's very mature, and it's free, what's not to love, you know, it's brilliant. But, you know, being a responsible developer, I wanted to do a little bit of due diligence on the project. I wanted to pick it apart and have a look at are there any particular security challenges here? Are there any particular licensing challenges? So, let's take a look under the covers of ExpressJS. So, the first thing I did was I downloaded a lot of the project metadata, and I wanted to look at how this particular project had evolved over time. So, this is the number of different dependencies of ExpressJS over a 10-year period. So, what you see is, way back at the beginning, Express was composed of, you know, a small handful of modules. Over time, the complexity of ExpressJS grew. So, the project itself is not a single project. It's an ecosystem of projects. And what happens is, over time it gets more and more complex, and then what often happens is, at major releases, they consolidate, they rationalise, and the number of projects decreases. This is pretty typical stuff. Almost every project you use these days is not one project. It's typically tens of projects, or maybe even hundreds of projects. So, I guess that's kind of fine. That's the way things are these days. But at this point, I'm starting to feel a little bit uneasy, because at the outset, I was looking at ExpressJS. I was trying to understand whether it's well maintained. What are the security issues? Now I'm not checking one project. I've now got to check 49 projects. So, my project has just, my problem has just got a lot bigger. So, for example, I can do some simple checks. I can check the licences of these 49 projects. In this case, all of them had relatively traditional, permissive, open source licences. That was fine. Funnily enough, I did this a few years ago with a project called Electron. You're probably all using Electron. If you use Microsoft Teams, if you use Spotify, you'll be using Electron. At that time, when I checked it, one of the thousand dependencies didn't have a licence at all, which meant you're not actually allowed to use it. And the comment in it said, I've just copied this code from someone else. I thought it was hilarious. But it's a growing problem. However, the problem is actually a lot more complicated than that. ExpressJS has 49 dependencies. So, when you deploy it to node, you're deploying 49 different projects. However, Express itself, the project has 195 dependencies. So, where do all these other ones come from? These dependencies are the development dependencies. These are the dependencies that Express itself uses to create Express. This is the tool chain itself that's used to form Express. So, why should we care about this? Does that really matter? Well, these days, it actually matters quite a lot. You will have probably heard of the concept of software supply chain attacks. Now, if I want to do something malicious through Express, I can get a vulnerability. I can sneak in and attack through one of the 49 dependencies. I can also sneak in attack through one of the 195 development dependencies. I can add malicious code to the software supply chain. And this does happen. And it's happening increasingly. So, okay. So, the complexity of this is starting to make me a little bit nervous. My initial goal of checking one project has now meant I've got to check 195 projects. Whenever I install Express, I'm installing all of this code onto my machine. So, the next question I wanted to ask myself is, when I install it, is it the same as when you install it? Is it the same as when I installed it last week or the week before? Funnily enough, it's not. Between Express 14.16.4 and 14.17, Express itself changed 33 times, which might seem a little bit odd. What's happened is, as developers, we've come up with this fantastic concept called semantic versioning, where our dependencies are somewhat woolly. We basically say, I'm happy with version 1.1 of this project, maybe 1.2, 1.3, but not version 2. When you have a complex web of dependencies, what that actually means is your deployed configuration changes a surprising number of times. Now I'm getting a little bit scared. I've got 195 dependencies, and they keep changing under my feet. How on earth am I going to work out whether this is a sustainable and secure project? And the other thing that it got me wondering is, who are the people that hold the keys to all these projects? Who are the people who determine whether this is an official release of all of these dependencies? So I started taking a look at that. And I found out that in the direct dependencies, the ecosystem of 49 dependencies, there are actually 88 maintainers who have the ability to push a new release. So I am now dependent on the good practices of these 88 maintainers. Interestingly, NPM, which is the repository that people use to release JavaScript code, only 9% of developers use two-factor authentication. 91% use a simple single-factor, which is their password. The vast majority of people recycle passwords, and I now have the email addresses of these 88 maintainers. You may have heard of a guy called Troy Hunt, he's a very famous security researcher. He publishes a website which indicates, which allows you to look up via an email address whether one of their accounts has been compromised. I can pretty much guarantee if I run these 88 email addresses through his website, I will find one that's been compromised, and I will find a password, and there's a very good likelihood that they will have reused that password. So what I'm saying is, if I wanted to attack Express, I've actually got a pretty good chance of finding a route in. Okay, I'm going to get a bit scared now. This isn't what I was hoping to find. I think we've gone quite far down this rabbit hole, and I think it's time to come up for air. Surely there is someone at the top of this all, the sort of benevolent maintainer of ExpressJS who's worrying about all of this on my behalf. Maybe there's a whole team of people working on ExpressJS worrying about this on my behalf. Ah, no, there isn't. Actually ExpressJS that's downloaded 14 million times every week is maintained by a single individual. They're doing all this feature development, making it wonderful. They probably don't have time for all of the problems that I've just been talking about. Interestingly, I had to look at the history of ExpressJS. In its 10-year history, it's been through two sole maintainers. The very first maintainer approximately five years ago decided he had enough and sold the project to a company called Strongloop. So it's an open source project that he sold to a startup. And a lot of people in the open source community went, hang on, you can't do that. And he said, yeah, I can. It's not a license violation for me to sell this open source project. So the community had a bit of a fallout, but this is something to bear in mind just because something is free and open source now doesn't mean that it's going to be free and open source in the future. Now fortunately in this case, the startup Strongloop were acquired by IBM and one of the things they did when they acquired Strongloop is they took the decision that ExpressJS should be a community project. So they moved it under OpenJS, which is part of Linux Foundation. So that sounds like a happy ending. And after TJ, the original author, abandoned it, sold it and Strongloop then were bought by IBM and it moved into OpenJS, a new maintainer took over. And that didn't go terribly well either. Again, they were in the position of having a sole maintainer. And what happened this time round was there was a particular security vulnerability and this was an interesting one. It was a security vulnerability which had an element of interpretation to it. And if you've ever looked at, if you've ever been involved in security issues, more often than not they're black and white, there's a gray area with respect to the responsibility of each of the parts of your platform and the system. For various reasons the maintainer interpreted a particular requirement in one way and a security vendor, a prominent security vendor interpreted it another way. They released a CVE which was distributed to tens of thousands of their clients who immediately landed on the ExpressJS GitHub repository and said, you have to fix this thing for me now. And the maintainer who doesn't get paid for this quite rightly said, I'm out of here. I'm not enjoying this anymore. Thankfully he stepped back in after a while. Now, to be honest, I wasn't expecting to find any of this. I honestly picked ExpressJS at random. I was astonished at the level of complexity that I uncovered and I was equally astonished at the story, the timeline of ExpressJS, the project itself. It was entirely picked by random which makes me think if I pick another project I may well find a similar story. So, what are the solutions to this problem? First one, yeah, money. Money's the answer to everything, isn't it? Surely there's nothing you can't solve by throwing a decent slug of money at it. So I thought, let's have a look at the relationship between ExpressJS and money. So I looked at the dependencies of ExpressJS, all 195 of them to determine whether any of them had a funding model and I found one. It's a project called ESLint. So ESLint is a tool that helps create a consistent format for JavaScript code. It's really quite popular. And ESLint has funding through a website called Open Collective. So that took me down the next rabbit hole. I thought, okay, that's great. At least part of the Express ecosystem is funded. Let's have a look at Open Collective, see how that's going. So I looked at the 30 most popular and most funded projects on Open Collective. You can see their annual budgets and I converted those annual budgets into full-time employee equivalents. How much developer time would this fund? I found that the top five projects were able to fund one or more developers. ESLint is in the fortunate position that it can fund around about 1.2 developers full time. Open Collective has thousands of projects that are funded through their mechanisms. The vast majority sit on the long tail. In the first 30, you can already see that a number of them can only fund 0.1 full-time equivalents. Whilst I think Open Collective does a fantastic job and I don't want to knock what they do, I really do like them and I use them myself, they are only addressing a tiny fraction of what needs to be done. If we look at Open Source in general, Open UK published a report a couple of years ago where they had some economists to determine the overall value of Open Source to the UK economy. They estimated it contributing around about 43 billion annually to our GDP. Open Collective collects about 0.5 million each year. Tiedlift is the largest entity that's running an Open Source funding model. They distributed about 40 million in funds in the same year. The difference here is many orders of magnitude. There's a huge mismatch between the value that Open Source delivers and the money that it collects. So, how do we solve this? Well, funny enough, most large enterprises take a somewhat medieval approach to the problem. Rather than fixing the problems that they observe, what they more often than not, they spend their time and their funds on building up their own defences. The kind of defences I'm talking about here are paying third parties to do your vulnerability scanning, paying for tooling that protects you from some of the challenges that you see within Open Source. This is big business. Black Duck sold for 500 million just a few years ago. This is, and again, so a company that helps protect you from the challenges of Open Source sold for far... many orders of magnitude more money than the funds that people put into Open Source. We're starting to see an imbalance here. And it does actually cause damage. There was an interesting blog post I read from someone who was a prominent Open Source maintainer who went to an Open Source conference. And, funny enough, a lot of the vendors at Open Source conferences are providing security services to companies. And he was chatting away to one of them and thought, hang on, they charge a 50-person start-up $30,000 a year to help them feel safe using the code that authors like me have been giving away for free. It kind of doesn't make sense anymore, does it? From my perspective, we need to have a radical rethink around our relationship with Open Source in order to fix these problems. And the first thing you need to do when you're having a big rethink is to gain a better understanding and have empathy with the Open Source community. Now, this is a huge topic of itself. If you haven't read this book or seen this book before, I very much encourage you to get a copy of it. It's called Working in Public and it's by a lady called Nadir Egbull and she spent a lot of time immersing herself within the Open Source community and culture to understand and empathise with it. Some of the things that really jumped out at me is GitHub has had a fantastic effect on the community in that it has centralised the community. It's a world-class platform for creating Open Source. However, it's also resulted in a fairly significant challenge. It's much easier now to contribute to Open Source than it was before. Historically, Open Source was behind closed doors tight-knit communities whereas now it's more often than not people having fleeting relationships with projects. She called it the stadium model. You have an Open Source maintainer who is working with thousands of people who have very brief fleeting relationships with their projects and that itself is creating challenges. Probably the most important thing that I read in this book is the most prized assets of most Open Source maintainers is their attention. It's not money, it's attention. They want to be able to spend their time, often their own personal time, doing the thing that excites them most. What I want to do is give you an example of how this can go horribly wrong if you do not understand this. You may have heard of a thing called Hacktoberfest. It's a competition that digital ocean run every year and on the surface of it, it sounds really quite good. Every year, they give away a whole load of t-shirts to people who contribute to Open Source. Again, on the surface, that sounds pretty good. Open Source contribution is good. T-shirts, yeah, people like t-shirts. Unfortunately, what happened a couple of years ago is there was a significant rise in the number of people providing incredibly low quality contributions to Open Source projects just to get a t-shirt. A number of Open Source maintainers actually termed this a distributed denial of service attack on Open Source as a whole. Unfortunately, because digital ocean didn't understand that attention is the most prized asset of a maintainer, they didn't understand the negative impact of the Hacktoberfest project. Now, it's still running and they're trying to address these challenges. But again, you really need to understand the community in order to propose a good fix. So where do we go from there? One of the things I think we need to do is change the terminology. I don't think Open Source is a terribly good term for describing what it is that we are working with and what it is we need to maintain. Commons is something that we're already familiar with. The concept of commons is something we're familiar with from the world around us. The commons is the cultural and natural resources accessible to all members of society, including air, water, habitable earth. These resources are held in common, not privately owned. You probably personally benefit from environmental commons. I know where I live. We've got a dean, for example. There's common land which we all benefit from and we all understand our shared responsibility. Now, with a little tweak, 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 privately owned. I'm not the first person to draw this parallel. There's a term that's slowly starting to gain traction, which is that of digital commons. Digital commons actually addresses more than just Open Source. It encompasses things like Wikipedia. I think the term digital commons is a much better way of getting non-technical people to understand that there is this fragile and precious resource that we all have a shared responsibility for maintaining. Once we have an understanding of our shared responsibility, we can start to look at some of the techniques and tools that are already at our disposal to fix this problem. This is what gets us onto the subject of corporate social responsibility. This isn't a new thing. This term emerged in the 60s and it's becoming increasingly important as part of legislation. For example, government procurement contracts of a certain size are only awarded if you have a carbon reduction plan. Corporate social responsibility, or CSR, is becoming a growing concern. I won't go into it in any great detail. A very simplified view of corporate social responsibility can be conveyed by a thing called Carol's Pyramid. At the very bottom, as a business, you have an economic responsibility. Your economic responsibility for most for-profit businesses is to maintain profitability so that you can pay your staff. The next level up of the pyramid is legal, your obligation to obey the law, whether that's regulatory requirements in financial services industry or whether that's employment law. You have a requirement to do so. Next up is your ethical responsibility. Now, this isn't mandatory. It's a choice whether, as a business, you want to operate in an ethical fashion, although legislation is creeping in to the ethical layer. This is your responsibility to be fair, to be reasonable, to do no harm. At the very top of the pyramid is the philanthropy, giving back to the community that you take from, being a net positive contributor as a business. More and more businesses are waking up to the need to be ethical and philanthropic. So, how do you relate this to open source? Well, if we start to draw parallels, a parallel to the economic responsibility is that of consumption. Consumption is simply the fact that you're having... There's an economic benefit to consuming free software. There's a direct relationship between the two. Legal obligations, yes. Within open source software, there are legal obligations obeying the licensing restrictions, trademarks, copyrights. At this point, the parallels seem to end. What I'm arguing is that in the same way businesses should be considering their ethical responsibility and their philanthropic responsibility, I believe there are strong parallels to those within the open source community. Once you change the language to that of the digital commons and understand your responsibility towards the commons, you should start being able to elevate higher up Carroll's Pyramid. So, the final thing I want to do is talk a little bit about turning principle into practice. It's all very good for me to stand up here and be very preachy and say, you know, whichever business you may work in, you should be considering your responsibility to the digital commons. What I wanted to do is talk a little bit about the company I work for, Scott Logic, and how we are looking at embedding open source sustainability into what we do. Now, I'm not going to go into a whole lot of detail, but most businesses will have vision and mission and purpose. You'll probably have language that you use to talk about your purpose to your clients, to your employees. And Scott Logic is similar to most businesses in that regard. Our purpose is to create opportunity and sustainable prosperity through technical innovation. We also have a client mission and an economic mission. I'm not going to go through those. The interesting one here is we have a social mission and that is to operate the company in a way that actively recognizes the role that businesses play in society by initiating innovative ways to create opportunity in our community and to safeguard the future of the natural environment. Now, this social mission has not been written from the perspective of a technologist. However, I would argue and what we are doing in Scott Logic is we are starting to leverage our social mission to better understand our responsibility to the digital commons and our digital environment in the same way that we have a responsibility to maintaining our natural environment. What we're doing in practice is we're looking at some of the consultancy work we're doing for our clients and we are finding areas where we are relying on open source projects that are struggling. Those where we see that the foundations to the products and platforms we're building for our clients where those foundations are fragile and we are actively contributing back to them. We're not making financial contributions. We're looking at how we can spend our time, our developer effort in solving some of the sustainability problems that we see in front of us and that's something I'd encourage you all to do. So in summary, our open source commons are valuable, precious, but fundamentally highly fragile and this is becoming increasingly apparent. What I'd advise is that you need to better understand the community, better understand the motives, better understand the people behind the projects that you're relying upon. And finally, come to a realisation that it's your responsibility, our responsibility to formalise a commitment to sustaining open source. Thank you very much.