 Hi everybody. My name is Luis Villa. I'm the co-founder of Tidelift, a programmer turned attorney. Some of you may know me from prior hits such as Mozilla, Wikipedia, and brief stops at Red Hat in the year, the first year of the Linux desktop at Zimian and the GNOME project. I'm here to talk today about security, but in particular what security means in a new era of maturity or sometimes what we call professionalism in open source. And so somewhat jokingly, but somewhat deadly seriously, I want to talk to you about what expect when you're expecting professionalism. There's only a 15 minute talk. Hopefully we don't really need a TLDR, but nevertheless, I want to really, if you take away nothing else from this talk, if you hang up right now, I want to say there's really three things here. We, I think there's a critical distinction between maturing open source and professionalizing it. It's not necessarily a bad thing, but there are differences that we need to think about as a broad community that about the implications of the things we're doing. The second thing is that, well, I guess I just sort of preview this. This professionalization is likely to have real impacts on participation and impact or effectiveness of new initiatives that we take as a community. And finally, third, I want to say that we all need to be thinking about the impact of incentives and complexity. Too often, of late in our community, we've said, oh, incentives, complexity, those are someone else's problems. And we all, at all different levels, and I'll close with some called actions around this, need to be thinking about our role in creating increased complexity, our role in demanding and expecting increased professionalization, and what that means about the incentives that people need to participate in the open source as it exists in the 2020s. To go to walk you through how we're going to structure this in the talk. First, when I say professionalism, what do I mean by professionalism? Second, what are the downsides? What are the weaknesses or stresses of this new professionalism? Part three, when let's walk specifically through the example of security, because of time limits, I will really only focus on security today. But I think it's really critical to say that this new professionalism also applies to other things like licensing, codes of conduct, et cetera, but we'll focus today primarily on security. And then part four, why does security feel so different? What has changed over the past three, five years, maybe even the past 18 months to make this feel different in a way that is really impactful for our projects? And finally, part five are to do, what are the called actions that we all need to take away in order to make this really work? So first, the new open professionalism. So why do I use this term professionalism? You know, I think there are a few reasons. This, these are some definitions off the interwebs conduct behavior attitude of someone in a work or business environment. And I called this one out specifically because we so many of us are now employed to do open source in a worker business environment, but many, many, many more of us are not yet, right. We wrote a tidelift of one post called the boss factor. It turns out for many open source developers, what really channels their commitment to open source has a lot to do with their work. But not necessarily in a, it's a full time job sense. It may be in a sense of the boss looks the other way while I do 10% here. Or my boss has me work on Java, but suddenly we've switched to become a Python shop. My Java projects are now abandoned. So things are not when open source is done that way in that sort of informal sort of on the clock but sort of off the clock way. The expectations have historically been very different. Are those, are those expectations changing because so many of us are employed, and perhaps sometimes forgetting about the constraints and factors that drive the people who are not employed to do this in a full time sense. I, when I go to an open source conference as a professional, I'm expected to wear a collar, not everybody is and it's important to realize that there is that distinction. Similarly, another great definition of professionalism, this sense of being reliable setting your own high standards showing that you care about every aspect of your job. All of these things are really good and important. And in some sense we should all strive to be doing more of this kind of thing in open source, yet at the same time. Again, for some of us this is very possible it is literally our day job, our nine to five or let's be honest, usually much more than our nine to five. And that gives us the time energy focus to be reliable to set those high standards to show that you care about every aspect. And as we'll get to there are a lot of aspects these days. But not everybody has that luxury not everybody has that privilege. And so what does that mean, as the boundaries of professionalism and the expectations again the title what to expect when you're expecting professionalism. These are often increasingly expecting this level of commitment, and it's not possible for everybody to have it. And so, hopefully what we'll explore today some is where that tension comes into play. Do want to contrast in particular two terms, one maturity. I think of maturity when we talk about maturity in the open source space as being a sort of gradual layering of skills, wisdom. This is very related to but distinct from professionalism, right, you can be a mature open source maintainer, but your maturity may come with the wisdom of saying, you know what, I don't have to respond to everything in a timely manner. These things are going to be water under the bridge. That's a very distinct from a professional attitude, which may be, Oh my goodness, I have to respond to all these things right maturity often in software means knowing what not to do. And that's in some tension with professionalism. Similarly, amateurism. I think this is probably something most of us in open source have heard at some point or another. But amateurism comes from the Greek root, ama to love right, it doesn't necessarily mean that you're doing it badly. But it does mean you're doing it out of a different set of motivations it means you're doing it because of a love of what it is that you're doing. And let's be honest, some of the things that we're asking open source maintainers to do these days are not things people do for the love of it. They are very often essentially paperwork. They're important paperwork. And I again want to stress this is not an attack on some of the new security standards licensing standards, etc. It's really to think about how those new standards that new very well intentioned paperwork might interplay with people whose motivations are a little more a little more personal. So why now look professionalism has been increasingly with us in open source since the late 1990s, the first time red hat handed out IPO checks, professionalism was a real thing. But my thesis here is that increased security demands and other causes that we won't get into today are driving a new wave of expectations of professionalism of timeliness of thoroughness and completeness. And that that is really going to impact how we do open source in both the near and long term futures. I'll give you a little bit more detail on what I mean when I say for when I say professionalization in this sense, one critical thing about professionalization professions are hyper specialized, and they are formalized. One thing that we used to not have and I'll get into this a little bit more in the next section is a little bit sense of informality right if you let something slide it was okay. I'm expecting extreme formalization. Everything has to be properly formatted metadata. We need to be signing all our changes, and this really impacts things. You need to use specific standards tools, or you're not a professional. And that's a big change from it's a gradual change but it's an important change in what we expect out of open source. There's an increased expectation of response time again professionals. I'm a lawyer. There is very much an expectation in my profession that you pick up the phone at all days and at all hours of the night. And that's something that we're increasingly seeing and is increasingly wearing on open source maintainers. Finally and critically, unlike most professions. When we professionalized open source so far there's no directly correlated increase in compensation. There are a lot of ways to turn professionalism, or maybe maturity. into compensation, but it's not a one to one thing. If you're a lawyer you're only expected to be professional when you're on the clock. That is not necessarily the case in modern open source and that's a really critical problem. So what are the limits of professionalism. First, you know I want to talk about the upsides of professionalism. There are informal. There are a lot of things about informal amateur practices. They're inconsistent. They're hard to review, right, because you sort of have to have a lot of tacit knowledge. And it's especially hard to do at the scale that we all operate at now of thousands or tens of thousands of packages on the flip side formal structured professional practices tend to be more consistent tend to be more reviewable. Even as we're increasingly seeing in the security space certifiable you can literally have a certifying body that says these people did it the right way. On the flip side, downsides of professionalism, the informal amateur practice practices have a low barrier to entry, they're flexible in time and manner that means you can do them on weekends you can take a week off when you want. You can do them on your own servers you can do them with your own scripts your own tools. And we know for a fact that these amateur practices scale across the long tail. We all, of course, here at this conference we're often talking about things like Kubernetes and the Linux kernel. We're all using thousands of long tail packages to build our products and services, and we know that these informal amateur practices scale in some sense, certainly not all across that long tail. On the flip side, formal professional bear practices, high barrier to entry, inflexible about how we implement them, and we don't necessarily know that they're going to scale across the entire long tail open source. You know, I think it's really important to say here by the way that the impact of the new professionalism varies across project types, depending a lot on funding access to training and upskilling, etc. Right, so Nadia eggballs typology of toys clubs stadiums and federations federations, the biggest projects that Kubernetes the Linux kernel, they're, they're having and are often driving this new professionalism right things like SLSA the new security stuff out of Google. That's going to be stuff that Kubernetes, I would guess, very likely to not just tolerate but to actively embrace because as a federation they have access to a lot of resources on the flip side toys may be literally almost by definition excluded from SLSA, because often those are one person shops, and at least the highest levels of SLSA, you literally need two people where the median number as we know on GitHub is one. Similarly the Mozilla open tech strategies, typology of open source, be to be multi vendor infrastructures, these things are going to do well in a new professionalized world. These multi libraries often maintained by only one person upstream dependencies often maintained by only a small number of people. They are going to face a lot more challenges from this new professionalism. So let's get into the nuts and bolts of security, and is it professional. Is it now professional. Currently security is often informal CVs have no metadata structure you literally have to parse them by hand. They are consistently reported so upstream may not even know about them. CVs are not integrated into package manager so if you've got a project with a CV still going to be available on the package manager still going to be you're still going to be able to upload it. Because I would say currently don't really fall into the rubric of professionalism for most of open source. This is in some sense a very good thing it allows security non experts to participate in open source. Also, obviously it allows for a lot of security problems. Yeah, in other words it's possible to be an open source maintainer today without being a security expert, because these loose edges of CVS bomb signature processes allow you to participate even if you aren't a guru. I think it's an open question how much that's going to be possible in the future. The trend obviously is going in a very clear direction here in response to lots of security problems we're getting a lot of pushes for new formal structured obligations. The US government is pushing S bombs everywhere. SLSA level for as I mentioned is requiring two plus sign offs where the medium project literally only has one contributor. What's that going to mean for that long tail. There's a lot of automated scanning now, which is good. But on the flip side means a lot of maintainers seeing an avalanche of you have a problem you have a problem you have a problem. You know, many of these, I think it's critical to note here again getting back to that point about different types of projects being impacted to different ways. Many of these new specifications do not acknowledge the existence of multiple projects types or the varying developer motivations. If this is your day job, you can tell your boss, you know what, there's new requirements. I need to take some time to learn these new requirements, build some tooling. If this is something you do on weekends and it's competing with spending time with your kids for your puppies. That's a real problem. And the reality is, even though we all think about the brand names, Kubernetes Linux kernel, etc. that have a lot of those paid folks. All of our stack depends on those unpaid folks as well. Another little detail in this question of is security now professional. I think it we cannot have a frank discussion about this without saying anything. There's a lot of money in this ecosystem now. Google has pledged $10 billion companies like sneak are, you know, multiple levels of unicorn. I saw just in my friends network on Twitter, two new startups in the space just this week. We professionalism is not directly tied to money, but on the flip side, as I said earlier, it's also a somewhat unusual situation in our culture where the high expectations of professionalism are not necessarily tied to high expectations of remuneration. So why is security somewhat different again from what's gone before in open source? I think there are two key things that make security very different that we have to think about in a very serious way. One, there is a weakest link problem. If we don't get professional or what somebody on Twitter yesterday called industrial coverage, in other words, complete coverage of our entire stacks, our weakest links are still going to be real problems for us. Previously in open source, we for for things like this, we would say, for example, spdx. Well, the Linux kernel, if we get the Linux kernel all XP DX, that's really going to reduce a lot of our risk and yeah, there will be a lot of licensing risk down in the long tail, but we can learn to live with that risk down in the long tail. With security, we may not be able to learn to live with that risk down in the long tail. All it takes is one package being adopted by a blockchain miner or an advanced state actor to really torpedo the whole enterprise. And so that's a difference. We used to be able to say, eh, good enough. In security, we may not be able to do that anymore because of this weakest link problem. Similarly, there's an end to end problem. We have often relied in our space of on the top packages will be taken care of by systems integrators or by big players like red hat. In other words, maybe the licensing wasn't perfect upstream, but somebody would clean it up package it and give it to us as enterprises. It's especially in the security context, but I think increasingly in licensing as well. It's going to be hard to create and maintain data accurately without participation at all levels of the chain, including maintainers. A great example of this is the move to signatures insecurity signatures in the build process are not something you can add after the facts. It's something that the that the upstream maintainer has to participate in for them to have their full value. And again, this is an assumption that we've had in this industry for a long time that may no longer be holding true. And I think we need to think about what the implications are of that for what does it mean for us to be going truly and and including the maintainers. That's something that we've sometimes sort of skipped over. And I don't think we're going to be able to do that for that much longer. And I think we're actually pretty much going to end on time since we started a little late. What are my calls to action here. You know, because I think I really want to stress again that this is not. This is not a call to stop doing what we're doing in security, only an idiot would deny that we have deep security issues in open source and that some of this new structure is really going to be critical for how we deal with it. At the same time, I do think we need to think about professionalization. What does it mean for all of us motivation incentives. How are we going to address some of these. And that's how what I want to talk about in this final section about the call to action. If you're a spec writer. There's a lot of us out there right now Eva. You may some of you may have seen put a document in the CNCF slack that was simply pretty much just a listing and overview of all the various security specifications and proposals out there. And it was multiple pages when I last looked at it a month and some ago, and I'm sure it's much longer now. So if you are one of the many folks thinking about about security specifications or other types of specifications as well for example if you're in the S bomb space. I would strongly urge you to explicitly consider how is your specification going to work across all project types, because remember, we have a weakest link problem. If your specification is only going to make sense for the Kubernetes and Linux kernels of the world. Then you need to go back to the drawing board. This may mean that you need to partner with platforms like GitHub. It may mean that you need to think about things like developer incentives. How are we going to pay maintainers to do this stuff that feels like paperwork. And that's going to vary across project type and if you only tackle one type of project. It's not going to succeed. Similarly related, I want you to explicitly consider developer motivation. If you write a specification that doesn't talk about why developers are going to do this work. Then you've missed the boat, you do not have a 1.0 until you've explicitly considered this. Remember, and this is I think a really critical point, you need to put yourself in other open source maintainer shoes. If you are writing a security spec you are highly likely to work for a centibillion dollar company, or a trillion dollar company. You are not a typical open source developer. It's true that you can come here to an event like this and have drinks. Lovely drinks. Thank you Microsoft for those on Monday night before I got sick. You are not that you can you can attend an event like this and only talk to other employees of 70 billion dollar companies. But that does not mean that this is representative of all of open source that long tail means that you are very atypical Kubernetes Linux etc are not typical of open source projects. So ask yourself and answer in your specification process. Why are the projects and developers you target going to implement your spec. I explicitly call out the proposal for project alpha slash Omega that's been going around CNCF via some folks at Microsoft, they considered this stuff from day one. And I really think that that's something admirable and important and more of a should model. They called out both different types of projects and developer motivations. I think that's really critical and really honorable. On the flip side, I really want to say part of why I'm giving this talk now is because too many times I've been told, Oh yeah, we'll figure it out. I feel honestly like an asshole at this point because I'm the one who sits in the back of these rooms and says, Okay, but why are developers going to do this in the late 90s early 2000s. We, you know, the early open source folks academics would be like, Oh, so if we just put it under an open source license, magical things where it happened and we'll be like, No, that's not. I mean, yes, but no. And now I feel like often we are the one saying, Oh yeah, if we just put this specification out there. If it's going to happen developers will adopt it if it's a good enough spec. And developers are overloaded developers are stressed. We can't just take that for granted anymore we have to think proactively about it. And frankly, I, I'm just sick of the one of the being the only one who stands up and ask these questions at conferences. So that's enough about specs enterprise consumers. When you are considering whether your company should adopt or implement an enterprise security spec of some sort, or an S bomb spec or something like that, consider whether the spec advocates have a theory of change that is more than our spec is good. That isn't enough for overloaded maintainers. You need to not just considering your own adoption but you need to tell specification authors. Hey, we don't see how this is going to work in practice. Yes, it's a very nice XML specification. Yes, it's a very nice Jason specification. That's a great database you've developed and I like your blockchain. But why are people going to do it. And if they don't have an answer for that you need to tell them that's not acceptable. And I need you to consider how to support people who are doing the work, not just the people advocating for doing the work. Again, it's lovely that we have all these 501 C sixes who are pushing a lot of these things. But if we're not helping the developers actually get it done. It's not going to be effective it's not going to solve the problems this is not just a moral thing of like, Oh, we should really pay the maintainers. It's a practical thing, which is that if we do not help the overloaded maintainers, either through paying them, paving the way with extremely good work work on our platforms, or some other magical thing, it's just not going to work. It's going to be a practical failure on our parts. Finally, if you're a maintainer and you're listening to this talk, consider how to be cooperative with other maintainers while not burning yourself out. How can you, you know, how can you build tools how can you build scripts. You shouldn't have to take this all on yourself. There must be ways for other people to help for people to band together and help each other do this. You should consider how to coordinate with others. Frankly, I think we'd be a lot better off if a lot more maintainers often stopped and said no, not just out of a selfish. Okay, we want our slice of the pie. In fact, I hesitate to even call that selfish. But because often feedback from maintainers, especially small maintainers will really help improve these things and make them more practical make us all more secure and better licensed and better COC over time. Finally, I want to stress again, this is not a call to despair. This is not a call to lower our standards. It is a call to rethink how we raise our standards and on whose backs whose labor, are we building those standards. With that, thank you very much for your time this morning. If you want to find me, I'm Lewis at tidalip.com or I'm Lewis and be on Twitter.