 I have started my timer. Hello everyone, hello friends, colleagues, lend me your ears. So thanks for coming to, at the end of the day, what is a very vague, nebulous, and experimental talk? Almost not sure what I wanna say, honestly. It's my first in-person talk in quite some time. So this whole having interactivity with an audience is new or renewed. So before we get started, you can access the slides directly at this bit.ly link. It's bit.ly slash social dash model dash O-S-S-U-M-M-I-T. Those are case-sensitive, bit.ly links are case-sensitive. So all of that is lower case, and this means that all of the images that you'll see in this presentation have alt text that if you want to see the, or want to hear the image descriptions. A social model of open source, what is that? I don't know. But I have some thoughts, and that's kind of where we're gonna go today. So this is me, I'm Julia. I am your friendly open source human. I am a multi-tool in a good sense of the word, I guess. So I code, I write policy, I do what needs to be done in open source, and that's pretty much it. I pride myself on not having deleted all of the GitHub orgs that I have access to, and I know that my manager, Stephen, is very thankful for that as well, because I'm new to Cisco in their open source programs office. And I am the co-founder of Open Source Stories, which is a narrative gathering project to raise the visibility of typically uncredited and unrecognized contributions to open source backed up by StoryCorps. And yeah, I will stop my identity crisis. We're gonna do some basic stuff right now. This is the complete history of open source part one. And by that, I mean, it's a very incomplete history that is cherry-picked. But when open source first started in ethos, not in definition, was the domain of researchers, it was the domain of universities and trading code just happened, right? It was code was treated like public domain, but in 1974, what happened? Anybody know? Software becomes copyrightable. You can read the court case. It is scintillating. And everything kind of changed then. We started having more conversations about what open source meant, like how could we regain this sort of freedom that we had before that point? Lots of stuff happened. And in 1998, if we jump forward many years, we saw the founding of the OSI and the creation of the open source definition. Pivotal points in open source history. We'll come back to this. So what is open source? We're gonna do this rapid fire because there's a lot of material. So technically, most of us have seen the open source definition. You need to make it open and sourcy. You need to be able to redistribute it, modify it, and it has to be technology neutral. Protect people's integrity. Distribute the license. Don't do these things. Don't discriminate. Don't restrict software. So technically, this is what you gotta do to be considered open source. And I'm coming at this from both the perspective of somebody who has had to manage open source software at various companies and make sure that we're being good stewards of the open source community and also from somebody who has been invested in the open source community since, well, I don't think I've been this tall for quite some time, but when I had fewer gray hair, so this is what I mean when I talk about the technical model of open source. This open source definition, like what are the criteria that you must satisfy in order to technically be called open source? In all likelihood, when you think about open source, you mean you're not talking necessarily about the license. The license is important, right? Not gonna deny that. The definition is important. Not going to deny that. But when you think about open source, what's a word that comes into your mind? Innovation. Community. Anyone else? Collaboration. Sharing. Sharing is caring. Ecosystem, activism, philosophy, education. There are so many words that can pop into people's minds as part of this wonderful candy bowl that we're in in open source. There is no, I have no candy actually, I'm sorry. Should've brought M&Ms. So whatever motivated you to join the ecosystem, and in my case, it was research. I was doing machine learning research and that was my first introduction to being able to modify code and create new algorithms based on the knowledge of people who came before me. That was magical. Our different motivations are what make open source this multifaceted and dynamic place that we like to spend our time in. So when I think about open source, this is what pops into my head. This is a graph. It's got nodes, it's got collections of nodes. It's got arrows going in between the nodes. Sometimes they're connected in directional ways, in bi-directional ways, self-referential ways. And if we think of each of those circles inside the larger blob as a project with different components, we can kind of get a sense of, okay, well, how did the different projects interact with each other? Are they based on an open source language? Are they contributing back? Are they taking one as a dependency of the other? Are there similar collaborators on different projects? But this is actually way too simplistic. I'm sorry to say. The connections aren't necessarily the same. Sometimes it's about a learning relationship. Sometimes it's a collaboration relationship. There are so many ways that we interact with each other within open source. And the relationships between the projects and the parties in them aren't always uniform and they're not always static. They change over time. This is actually not right either because it's more complicated because they're humans in the mix. People are an integral part of the open source ecosystem. Without people, open source doesn't exist. And I don't know about you, but after years and years of therapy, I have realized I'm a very complex person. So I come with my own baggage and I come with my own modes of interaction as well. And humans make things complicated. But we're also what make this ecosystem tick. But our system got more complex and we're not done because it's not just humans. It's not just software. It's also companies, nonprofits, universities, governments, foundations, utilities. All of these entities have a place in the open source ecosystem. It makes everything so complex, but it makes it really, really fascinating. So open sources, it's complicated. I was looking for a picture that, and I believe my search string was Knitter's Worst Nightmare. To illustrate this, and I couldn't find one licensed the way that I needed, but open source is a complex system. And one of the things that if you talk to me long enough, you'll hear me say is that it's a socio-technical system. And we often focus on the technical to the detriment of the socio side of things. And I'm thankful for this opportunity to talk to all of you about the socio, the social side of open source. How can we do the relationships, all of the different relationships that open source has to deal with is the wrong phrase, but handle, how can we do them justice? How can we make sure that we are bringing the best of ourselves to this incredibly complex system? And that's kind of why I started maybe like a year or two ago really thinking about what would a social model of open source look like? How do we capture the information that everyone needs in order to participate in the open source ecosystem the way that they want to and the way that empowers them? How do we increase the transparency? How do we bring the openness that we bring to our code to the rest of how open source functions? So there are two words that I will probably use more than I should. And that's empowerment and transparency. And that's because that's the motivation behind all of this. So some things to note, this is nascent. It is very naive. It is very, very much not finished. And I do not have time in the amount of time I have allotted to me to cover all the different aspects because we have a complex system that is growing ever more complex while we're in this talk. So what are our goals? Not for this talk, just for the model, for a model. Well, it's understanding. We all come at open source with a different concept of what it is. Who here has seen some sort of interaction where someone's talking about an open source project and someone else says, that's not really open source. And they'll justify why they don't think it's open source. And that's because we have a different understanding of what those words mean, what that term means. So can we arrive at a shared understanding? Can we figure out how to formalize it? And can we help the people that want to engage in a project do so in a way that simplifies things for them, that gives them the context and understanding that they need in order to have fun. You can't quantify fun, but you can try, I guess. And we do have this problem in open source right now about sustainability, maintainer burnout, supply chain security, it all connects. And right now we're seeing a lot of interesting approaches that are coming at it from the technical angle, but we also need to come at it from the social side of things because people are a critical part of the system. So what don't we want to do? I don't want to tell you what to do, except for this slide. I'll tell you what to do here. I'm not gonna tell you that I have all of the answers because I don't, and that's kind of a weird place to becoming to give a talk is usually I talk about stuff I know, not what I don't. So I'm not gonna tell you that there's a wrong or a right way to do open source. I'm not here to pass judgment on you, and I'm not here to relitigate what is or isn't open source. So we can take that one off the table. So going back to the, oh, that's not open source. I hear that a lot, especially with, I worked in developer relations for a time and developer relations releases a lot of open source code, but you hear that's not really open source. They're not growing an ecosystem around it. It's not, they're not looking to actually accept contributions, they're just looking to bring people in and use APIs. I'm like, actually no, it is open source. It's actually right in line with the open source ethos. So when we talk about, okay, what is or isn't open source? Well, maybe we actually need to be having more nuanced conversation about what kind of open source are we talking about? What's the type? Which leads us to why is something open source? Like the first one, I wanna work with other people. That's like kind of, I don't wanna say universal, but that's a common thread. The second one we're seeing more and more, I want to do something that's gonna land me a job because recruiters have found GitHub. You must have 20 years of Kubernetes experience for this job. I wanna get early feedback, right? This is something that's really hard for me. So this talk is really hard for me. And of course, putting the corporate hat on, I want to use this as part of my business strategy. Or I wanna win a bet. I have actually seen that. And if you haven't, I'm pretty sure you're lying. So examining why something is open source can help determine how can we classify? How can we categorize the types of open source? What function does it serve? And these are some initial ones that I've kind of seen happen over and over again. And I'm not going to go into every one of them. But there are a couple up here, the validation and demonstration categories that you'll note are called out as being static often. They don't change. And let's go into the validation category. So is anyone here from academia? We've got three and a half, yeah. So if you're writing a paper, whether it's in computer science, bioinformatics, anything that uses a software, we know that reproducibility is a conversation that's happening more and more and more, right? We've seen a lot of papers in the past whose results have been called into question because they are not able to be reproduced. So a lot of publications, academic publications are asking for the code used. How are you gonna publish that code? How are you gonna publish it in a way that other people can use it and reproduce your results? Is this what's typically thought of as open source? Probably not. It's probably not what you have in your head. But it is a great use of the technical model of open source. But we need to set the expectation amongst contributors, amongst users that actually note this thing, this project that I've released needs to remain static and that is to keep the integrity of the publication. No, I'm not gonna fix issues. If there's a bug, it's gotta stay there because you need to be able to reproduce my bug. So by figuring out the general shape of your open source project and putting a name to it, being very explicit, you can help set the expectations. Oh, well, this was a research project that accompanied a publication. So you know what, maybe that's not something I take a dependency on because they're not gonna fix anything. Or this is an experiment. This is the, I want to win my bet. Okay, that's probably not gonna be ready for production anytime soon. It's fun, but the outlining the general shape of things can help us arrive at a good understanding of what to expect out of your open source project. So let's talk about people. I'm gonna put you on the spot because I can't because I'm in person and I can see all of you. It's great. How long, if I gave you an arbitrary open source project, would it take you to find the complete list of maintainers of that project? Is that five minutes, five hours, or five days? Five minutes, okay? Anyone else? Seconds. Was that for any project? I thought that was going for any project. For an arbitrary project, it depends. How about the complete core team, active core team? What about the security contact or the community stewards? This is not straightforward. It's not straightforward. And I've tried to do this for some arbitrary projects. And I've found myself in loops. I've found myself in the mess of get archeology, because I do that a lot. And so when you're a person coming into a project and you want to figure out, hey, is this something I want to take a dependency on? Is this actively developed? Is there more than one maintainer? If this maintainer wins the lottery, is this project going to be abandoned? It can add up. And those minutes, seconds, days, I've heard even months can slow you down when you are trying to fix a security concern, raise a concern, security issue. So being transparent about who is on these teams, who is responsible or empowered to make decisions and take actions for the project can really help both the people coming in as contributors, the people using it, and the people making evaluations about the project. And it can also help identify when a particular project needs help. When are they at risk of burnout? Maintainer burnout is a big thing. So if you've got a highly critical project that has one maintainer, how do you know that? And how do you find that out and monitor it? Operations, I don't like talking about operations, but I have to. So governance model is something we talk about a lot. These are various governance models. The BDFL is your, it is a governance model. That's all I will say. Is it run by a single company? Is it run by a foundation? And understanding the governance model and documenting it somewhere explicitly, easy to find, is really important. So people know how to engage with the project. If this looks too small to read, it's meant to be. So who runs the project? There are many folks, especially in actually in corporate space and individual space, there's a healthy amount of skepticism for good reasons on various sides to want to stay away or gravitate towards community run projects or corporate run projects and transparency about who backs the project. It's not just the governance model, but who is actually the creator, who holds the original authority, original influence, is important and can factor into your own personal evaluation framework. So running a project is expensive. Did you know that? Like it adds up, I'm feeling that right now. And we've got more ways than ever before to accept money into projects. We've got open collective, we've got GitHub sponsors, we've got Patreon, we've got all these different ways of accepting money for projects, but aggregated. It's hard to tell when a project is overfunded or underfunded. One of the responsible things to do in open source when we're talking about allocating funding is to make sure people have what they need. And if we're transparent about how much we need and how much we're getting and what our runway is, then we can actually do better at preventing financial crises in open source than if we wait to react. Can we predict? Can we prevent? I'll quickly go through resources. And I took my inspiration for this section from the chicken talk, which if you haven't seen the chicken talk, I will tweet it out later. You need docs, but you need different types of docs. Docs, docs, docs, chicken, chicken, chicken. There are different audiences for different types of documentation, but it's not always clear how to find them or where to go. So do the docs, all the docs. But also, not everybody uses GitHub or GitLab as an issue tracker. Who uses something else as an issue tracker? What do you use? Red Mine, Todo's? Yeah, Jira, yeah, we've got a bunch of different types. It's not always the place you expect and it's not always specified. Do you file bugs on the website, the same place you file bugs on the project for the website? Do you file accessibility bugs the same place that you file security bugs? Where do you file the bugs? Bugs, bugs, bugs, bunny. No, I don't know why I said that. So, and then also how do people progress through the project? Like how do you retain people? And the CNCF actually has a contributor ladder that I think does a great job at establishing a framework. Can someone gain trust and responsibility in your project? Where do they go to find that? So why care? This is stuff you know, right? Like why do you care about any of this? So we wanna bring the open source ethos beyond the code, beyond the license, but also who remembers this? Who remembers this? Heartbleed and shell shock. Heartbleed is my canonical go-to when I talk about being able to identify who is responsible for a project. Cause it actually took a while to realize how prepared OpenSSL was. And that is not to pick on OpenSSL at all. Major respect. But they were under maintained. And it took a while to realize that the person, person, primarily person, maybe a couple of persons responsible didn't have time. They couldn't quit their job or take an extended leave of absence to go fix OpenSSL. Can we prevent that from happening? Can we arrive there sooner? So if we go back to the history of open source, there are a lot of inflection points. The specific ones aren't terribly important, but at least for the context of this talk. But we've used a ton of things to work on OpenSource over the years. We've got ARPANET. I traded source code on floppy disks. We've got SourceForge, which was my original introduction to the wonderful world of Weka. I can't believe I pulled that off. Cool. We've emailed patches back and forth. We've discussed things on Usenet. And that is a screenshot of GitHub from 2008 when OpenSource was not their original mission. So the only constant we've got is change. Got to throw a paradox in. So the question becomes, what do we do with any of this? What do we do with any of this information? Well, not telling you that you need another YAML file, but maybe, how do we capture this information in a way that's useful, that we can build tools on top of? How do we make it so that when the next great thing comes along, not gonna say when we move on from GitHub, because of course that will never happen, but how do we make migration easy? How do we make data portability easy? How do we make discovery easy? And OpenSSF Day and emphasized the importance of not burying your security MD file, five pages in on some random place in your docs. How can we make it explicit? How can we point people to where they need to go easily? I don't have all the answers. There are tons of open questions. This is not nearly a complete model. Like there's lots of stuff I didn't talk about. But the biggest open question to me is, how can we make something like this easy and zero effort for maintainers? Because the last thing they need to do is maintain another metadata file, right? How can we make it sufficiently flexible? Does it do what we want? And are there unintended consequences here that need to be fought through? Could you abuse a funding information? Yes, absolutely, yes you could. How could you do it? Lots of different ways. But I do think we could do a lot with this. We could give people the frameworks they need to make the decisions based on the criteria that are important to them. We could empower people through greater transparency. We could give people the resources that they need to be successful. I think something like this may have legs, I don't know, maybe. We keep doing this. We keep growing. This is what we do. We keep experimenting. We have these conversations. So I know like I have absolutely no time for questions, but here are some resources and I would love to chat with anyone three minutes. It should be a red sign, not a green one. But here are some resources that I've found useful, including some of my own. And if you're interested in kind of chatting about this, please, I'm aggressively online. So thank you. Again, these are the slides and here's some of the writing as well. So with that in mind, appreciate your time. And coming on this weird journey with me, so I think we have time for like one question, two questions. Any questions? Or is this way too nebulous to even have questions? I didn't even plant a question with you. What's your question? He's my colleague, by the way. So you had mentioned you wanted to be able to automate this instead of having to have the developers maintain this metadata document. Do you have some ideas how we could potentially do that? Yes, did you want more? As much as you're willing to elaborate on it. Well, I think it's gonna be a bunch of different tools. Because it's not, the way that it exists in my head at this point in time, you shouldn't have to specify everything because there's a lot that's not gonna apply to various different types of projects. So I think it's about creating automatic tooling for updating maintainer lists or developer lists based on who's contributing. I think it's going to be a lot of aggregating different data sources and making it super pluggable so that when the next funding platform comes along, you don't have to do a lot of updates. This is no small task. But coming from a corporate perspective, being able to get these metadata files and evaluate it based on your own framework, gotta do it. I don't know how. We're gonna figure it out. We've got, I think we have time for one more question. On that topic of metadata files that describe the social graph of a project. Two-part question. First is to guess, no, the second one's longer. Did you find some project communities, language groups, et cetera? I'm thinking of, say, stuff on Launchpad or PyPI or older stuff where it was tracked in consistent ways. And if so, because my experience is that it's always inconsistent across those. One group might do it. This way, a different group does it. A different way and other groups don't do it at all. How might we bridge that gap? So yes, and I think to your first question, the one that I found that came closest in my evaluation is actually the Apache Software Foundation. So if you look on the Apache Software Foundation's project list and they do have a schema, but it is inconsistently filled out even across projects within the Apache Foundation, the Software Foundation. So there's most definitely prior art here. And I think the biggest challenge is how do we come together as an ecosystem and agree because I'm pretty sure I don't agree with myself. So getting a consensus is of course going to be a challenge. And we're seeing that echoed in other initiatives as well. And I'm sure as one of the founders, creators of Gitbom, you are grappling with this as well. So I would love to join forces maybe. Thank you. Basically, well be your thoughts and stay tuned, I guess.