 Okay, good morning everyone. I hope everyone's having a good open source summit. This is my first time, I believe, talking in the Ospo contract. I'm really excited because I've been in Ospo's for a while now. Due to a technical mishap, my next slide is my previous slide. So if you want to follow along, the slides and notes are already published at bit.ly transparency-ossu-mnit. This lets you reference anything later as well as read things at your own pace. So we'll go back to the title So I've fooled you all into thinking that this is an Ospo specific talk. It's not. It is very relevant, in my opinion, so hopefully it'll be useful for you in your work. I have been on this kind of transparency kick for some time now because it struck me as super counterintuitive that open source, in part, is about transparency of code, but the transparency of process, the transparency of everything else, not so much. The way that I have observed the open source evolution over time is there's something increasingly secretive about open source development. There's a lot that's ostensibly in the open, but maybe falling a little bit short, we often talk about these shadow networks within open source projects where decisions get made, but no one knows where they are or who is in the room when those decisions were made. And I think it somehow stems from what seems to be kind of a fear of the establishment, which kind of makes sense given open source's history. So I've kind of here to this talk is not about lessons learned. It is not a proposed solution. This is a journey and a thought experiment. So hi, I haven't met many of you, I've met some of you. My name is Julia Farioli, and my official title is open source technical leader at Cisco, which I think is a really cool title, to be honest. I'm pleased with that. I also co-lead opensourcestories.org that's aimed at capturing narratives in open source, and we've been running that for a bit over a year now. And I hold an ever-increasing interest in the evolution of open source and how the decisions and the behaviors that we have changed the practice of open source software. But 40 minutes, just like 40 years, flies by very rapidly. So let's dive in. This completely meaningless chart over here that I made up shows us what we want to see and up and to the right trend. And we've seen the open source marketing campaign over the years that many of us have pushed for has worked. We've convinced our companies that open source is good, that secure, and that it's this thriving ecosystem that has been doing amazing work since its inception. None of that is false. So go us. We've seen the headlines. Open source says one, but we've also created a little bit of a problem for ourselves. And that's the idea that open source is a resource waiting to be. And as the demands on open source grow, so do the demands on the maintainers of open source, the creators, the facilitators, and they have increased faster than the support that we're able to give them. We've spent so much time and effort talking about the value of open source, but we haven't talked about the cost and the obligation. So our obligatory framing, I have to do this because it's in my contract, I'm pretty sure, is open source freezing pizza? I'm not going to turn down a free pizza. Pizza's delicious. There's very little cost in me consuming a slice of pizza, unless I consume like two or three pizzas. Or is it freezing beer? Not going to turn that down either, but might leave me not feeling so great in the morning. So in that case, in that sense, it might be more appropriate. But the one that's gained the most traction over the years is open sources, free as a puppy. Adorable, rewarding. Sometimes a handful. Sometimes they destroy your furniture. Sometimes they need to go to the vet because they've eaten the squeaker out of that toy. This is my dog. So I can I can say terrible things about her. And this one in particular is very needy. And you know, I could say that, but I love her. And there's an obligation. There's a contractual obligation between myself and my dog. So open source is free as a puppy seems to make the most sense for folks. That's harder to sell internally. So it's the eternal question. Open source is at least a bi-directional relationship. And because it's a relationship, we do have to ask what do we owe each other in it? Any fans of The Good Place Here? It's a good show. I'm not getting a commission. And we're seeing, especially from the Ospo side, a lot more effort in fulfilling our obligations as consumers of open source. We see where we do a lot of investment in helping our respective companies be good players in the open source space. But is there more? And that's a leading question. One of my colleagues, Josh Simmons, asked way back in 2019, pre-COVID, what are the big companies doing to facilitate open source contribution? What are we doing to give back? And this was not a new question. It's not a solved question, either. And we see it all stand really still and not move. There's tension between the creators and the consumers of open source. And I'm making very deliberate decisions about what words to use. I will interchangeably say creators, maintainers, contributors. And I tend to deliberately use consumer of open source rather than user because that has a slightly negative connotation when you think about it. So a consumer can be a company, can be another open source project, anybody who adopts open source. But we do see this tension. And with the increasing adoption of open source and the increasing scrutiny and the increasing visibility of security incidents, we get things like this. This was perfectly worded, in my opinion, in a letter that Daniel, an open source maintainer, received in the wake of Log4J. I'll actually read this because it's perfect. If you are a multi-million dollar company and are concerned about Log4J, why not just email open source authors, you never paid anything, and demand a response for free within 24 hours with lots of info. And this is something I think we've all seen in various forms, in various levels of severity, with the fundamental misunderstanding of an open source project's obligation to you, to us, as well as ours to them. And that sucks because we do this because we love it for a lot of us anyway, although if I were to win the lottery, I might retire. I'm not going to lie. But we don't ever want to put the projects in a position where they regret being open, where they regret being open source, where they take their toys and go home. And we've seen that a number of times. We've seen maintainers, creators, take their stuff off the internet and disappear because it's not rewarding. And for all we talk about empathy these days, when it comes down to understanding each other's perspectives, we don't do a very good job. Oftentimes we see the finished project without all the work that went into it. Or we perceive an outsized benefit from the hard work we've done without any sort of appreciation for it. So without describing any sort of blame or judgment, these are some things that I've heard from maintainers and companies alike. Hey, it's a free support channel. Cool. I don't have to pay for support. I can just ask the maintainers and ask the community. Or, hey, you know, we have day jobs too. Like, I do this on the nights and weekends instead of making dinner. I'm at my computer We're trying to get this issue fixed, but the maintainers are not being super responsive. No one's answered my issue. No one's answered my pull request, merge request. Or why am I here? Where's the joy? Where is the reason that I got into open source in the first place? And I think these are extremely relatable questions and statements from both sides of the issue. But we can easily reframe these statements from the other perspective. We need to understand how to use open source better. We need to communicate better. We need to be engaged, invested in this ecosystem that we're benefiting from. At the end of the day, it's a shared responsibility. The solution doesn't come from the project side. It doesn't come from the company side. It's a shared responsibility. We've seen existing efforts to close some of these gaps. And we see their benefits and where they fall short. There's very little in general that crosses the maintainer consumer divide. Though initiatives such as Indeed's FOSS fund have made good strides towards it. But in many cases, what the problem becomes is that we're not meeting maintainers where they are. And we don't consider the long-term consequences of providing short-term help. So how do we change our perspective? How can we go from playing tug of war with each other to walking in the same direction? And that's kind of what I've been grappling with for a while. And so this is some simple thoughts. So let's start by examining some of the core issues at play. These are by no means the only issues. But again, 40 minutes is not very long. We could probably spend a whole day. On one hand, we have unrealistic and potentially unwritten expectations from both the maintainers and consumers alike. We know that all participants in these relationships have unmet needs, from income to reliability to sheer infrastructure needs. For today, at least, we have insufficient communication. All of these issues raise the cost of consuming, running and participating in these open source ecosystems. And when I say cost, it's not just financial. It's not just risk. It's also burnout. It's toil. It's time. It's loss of joy. It's loss of enthusiasm. But the problem becomes is that this is not something you can automate away. It requires manual intervention to reconcile some of these core issues. And that's part of the problem. But not resolving them, not trying, results in sustainability and reliability issues. And the unfortunate part is that when that sustainability and reliability issue affects a company, oftentimes the maintainer is to blame or gets blamed. That was a severe misstatement on my part. Often the maintainer gets blamed. So where does transparency figure in? We can start to untangle these issues, but we can only start. There is no end point. There is no winning. There is no job done. Open source is an ever-evolving ecosystem. And as such, our approaches always have to change. They always have to be reexamined. Along the way. What are some ways to aid and transparency? One of the biggest disconnects that I often see is what is the project's goal in being open source? Now, what type of project it is? What function does it serve? But what is its goal in the act of open source? In being part of the open source ecosystem? And these are just like some goals that I can identify. There are undoubtedly many more. Generally speaking, this isn't explicit anywhere. Sometimes it might be buried in a readme, but it will often revolve around functionality instead of intent. And while adapting an open source project to suit your needs is fine and encouraged. Hey, it's open source, right? That's what we do. Having someone adopt your project that's a toy or a proof of concept and then expecting a fully formed governance model can lead to frustration all around. But that also depends upon people hearing it. When we are evaluating taking on open source dependencies, are we listening to the goals of the project? Taking a strict dependency upon one that doesn't line up with your goals can introduce risks into your supply chain. And switching away at a later point is expensive. Who has had to yank out an open source dependency and wholesale replace it once it's been embedded into? Yeah. Is it fun? Do you enjoy it? No? Okay. I was worried we had at least one person who would say yes, throw the whole talk off. But by listening to the goals of the project, you can create risk evaluation frameworks to guide the decisions. And in open source programs offices, this is something we're asked, like is this a project that I should be considering? And the answer to that is it depends. And you go through this complex flowchart of various things that should help your teams decide whether to use an open source project or not. A project that was meant to be a proof of concept probably shouldn't be used in production going on all in there. Probably as it's going to be static, never receive updates. But a project that's a utility that was, you know, the flags library and go, right? Probably is going to be something that you can rely upon because it's there to facilitate the usage of technology. And it will likely be more responsive to your needs as a company. And I'm saying us and we and all of these things with the understanding that we live in the open source ecosystem and we also live on the company side as well. So apologies for any confusion that my language is causing. In our open source ecosystem, there's a lot of effort these days to fund projects that you rely upon. It's an important part of sustainability, especially for a system that has relied on volunteer labor with little to no compensation for the vast majority of open sources inception. But funding isn't everything. Maintainers can't use money to buy time. You can disagree with me on that. They can't use it to buy skills and expertise. Expecting them to means that you also expect them to have the time and expertise to hire chicken and egg problem. The introduction of funding can sometimes actually be a severe source of stress for maintainers given the inherent transactional nature of money. Even if you say that it's do whatever you want with it, there's still an obligation there. Instead, if projects can tell you what they need and how they need it, they reduce the cost to themselves of accepting help and thereby reduce the cost of maintainership overall. And oddly, who here has had to pay or accept money for their non-job stuff? What does it mean? Like you have to figure out how to actually accept the money. You have to figure out what it means tax-wise. What are your obligations? Is there a contract that you need to sign? There's a lot of different places accepting money can imply an intent of support as well. When we talk about needs from the company side, oftentimes what companies actually want to know is, is this project sustainable? Is this safe to use? What is safe? Every day for the past, like now I think it's three weeks, I've said what do words even mean here? What does safe mean? What is health? What is sustainability? So how do you know if it's safe to take a project on as a dependency? You can't just look at activity or dependency graph as those are metrics in search of a lot like questions or theories or baselines. But if you think about it similarly to evaluating if you want to buy a particular brand of appliance, what do you look for? Is the brand reputable? Are there a lot of people out there who know how to fix it when it gets broken? What's the cost of replacing parts? It gets a little bit easier to judge the safeness of that appliance. But the most important one would be to me is, is that brand going to be discontinued soon? And looking at it from a project perspective, looking at the needs of the project can help guide companies into whether something is, quote unquote, safe. If it has mostly met needs, then it's probably a safer project to take a dependency on. Unmet needs, maybe you want to wait, maybe you want to step in and meet those needs. But it all hinges upon listening to the stated needs and respecting them. You don't want to create an ask for obligations. Like the introduction, we're just talking about this the other day, the introduction of a new feature seems like a gift except who's going to maintain it forever and ever and ever. Probably not the person who submitted the merge request, right? So what about communication? Who has heard of the golden rule? The golden rule is due unto others as you would have done unto you. I really hate the golden rule. I think it's terrible. It's egocentric and lazy. It's the, I don't want to take the time to learn and listen about others' needs. What's good enough for me is good enough for them. But the improved version of that is the platinum rule, which is due unto others as they would have done unto them or stated in a less circuitous fashion. Treat people how they want to be treated. This is the meet people where they are philosophy. So what's the platinum rule of open source? As a maintainer, as a project, it's telling people how you want to be interacted with. It's saying file issues here, not here. It's providing issue templates. It's telling people how they should reach you and how they shouldn't. It's giving them guardrails for what's going to get them a response and what's going to get them the exponential back off treatment. It's helping Daniel from one of the first slides not have to post something in shame on Twitter. And so spending a little bit of effort here saves you the practical and tedious job of redirecting people, the emotional labor. The flip side, of course, is listening to it and respecting it. And this is all part of, hey, transparency only works. If you're looking through the same window, so filing an issue or opening a merge request isn't always the right approach. But that has been ingrained in people within this ecosystem for so long that as projects set up boundaries and guardrails, we need to surface them as auspos to our contributors within our companies. So education is the key to helping people respect the transparency that's being offered to them. I had a really spicy take in there, but I removed it. So if you want to know, you can come up and ask me later. So isn't the information already there? Isn't it already in the readme? Creators put a lot of effort into creating documentation and readmeads and guides. But where does it actually live? If it's all there, how is it discoverable? Is it on the website? Is it in the repo itself? In the docs? Is there a standard place for it? Talking about standard stuff, a lot. You can take a non-trivial amount of time to locate. And then once you do find it, is it in a wording, a language that you understand what do words mean? Is it accurate? Or is it incredibly out of date? There's a lot of inference that you have to do when reading and evaluating open source in order to respect the goals of a project, to respect the communication, and the mores of a project. And that's for everyone that works in the ecosystem. The people who consume, the people who create, the people who contribute. It's hard to be a contributor in open source these days. And this is the point where I ordinarily present a solution, but I don't have one. So what I do have is some areas where I think we can make some progress. We need to provide information, and we need to understand how to do that so that it can be surfaced and relied upon. And that means acknowledging that people are going to have their own ways of doing things and their own solutions built on top of that information. So it will need to be a standard format. But those words, come back to those words, words are problems. We need to agree on definitions of things. It seems so straightforward. But I bet if I asked every one of you what open source means, you'd tell me something different. It doesn't have to be perfect. Like I said, these will have to evolve indefinitely. But they do have to be defined and documented. And where do we find it? How do systems find this documentation? We've agreed upon locations for so many things, like license files and readmeals and security.mds. Could we do the same with this sort of information? We need to figure out how to make this a know-op to maintainers. I don't want to increase the burden on maintainers. And if it's not apparent, this is a machine-readable thing that we specify. It's a spec. And we all know those are really easy to create and agree upon and ship. By the time we get out of the talk, okay, cool. But why? Running a project is a lot of work. It oftentimes starts as a labor of love. But slowly as the cost of maintenance rises, the joy just seeps out of it. And I often say that open source is one of the few areas where success is more problematic than failure. Can we fix that by giving projects enforceable boundaries? Can we give them space and tools to bring back that joy? And as companies, that transparency to us is a gift that we can, in turn, give back to the ecosystem by respecting it, by supporting it. So this is Aspocon. So what do we have to do with it? We live straddling the divide. We've seen stuff. We've seen patterns. We've seen anti-patterns. We've seen good behavior and bad behavior. All behavior in between. We understand the long-term consequences of good and bad decisions. We understand the ripple effects that they can have in the overall ecosystem. We take the long view. And I don't know if you know this, but we're kind of loud. We like to talk, but most of all we care. I care probably too much sometimes. I don't know where we go, though I have theories. But I do know that it requires everyone. It can't be a one-sided push. It has to be bi-directional. And we can't rush it through with badges or gamification mechanisms. So if this is something that you want to talk about, I am, as they say, extremely online and eager to talk. So thanks. And I think I have no time for questions, so I'm sorry about that.