 All right, we're here to talk about defaulting to open. Let me give you a little bit of introduction to where I work. I work for Percona. So Percona has been around for 15 years. They focus on open-source database software services and solutions. We have our own versions of MySQL, Postgres, MongoDB, and Postgres happens to have the elephant logo and have a Postgres talk later. So a little bit of self-shameless promotion here with the hat. But we also have been doing the open-source, active in members in the open-source space for years, even before Percona was founded. So I am Matt Yankovic. I'm the Haas head of open-source strategy. I have been with Percona for over 12 years, various roles. I was chief customer officer, chief experience officer, now I'm head of open-source strategy. I have a podcast, The Haas Talks Faas, where we just talk about open-source. So if you're interested in getting a whole bunch of interesting insights from all kinds of different people, stop on by and give it a listen. Come on in. It's fine. So what I want to talk to you a little bit about is defaulting to open. Now we talk about open and open is an interesting term, because everyone has a little bit different definition of open. If you were here in the previous talk with Stormy Peters, she was talking about some of the different components of the OSPO office and what they have to serve. When you talk about open-source program offices, when you talk about doing open-source, everyone has a little bit different definition of what that means for them. It's important to understand that it's not just about saying, hey, I'm an open-source company, I have an open-source program office, it has to be about matching the goals of what that is. So if we look out here, there's probably different people. How many people here are actually building open-source to monetize it? Is there nobody? We kind of are. So we'll say one or two. How many people here are at a corporation who's trying to just implement and use open-source? A couple. So the two different people have two different outcomes and goals. We have to understand that some people are trying to leverage open-source, some people are trying to build it, some people want contributors, some people want something else. This is where you have to understand the why you're starting an open-source program office, why you're getting into the open-source space, what is your purpose? Sometimes that purpose for you individually isn't the same as it is for the company. Sometimes the company's goals, the company's outcomes are very different than your own. When you look at those differences, sometimes you'll hear, and maybe you've heard this internally, where, hey, I want more contributors to our projects. That's what I want. That's our goal. That's our main goal, that's our main metric, that's what we're going to measure. But you can have someone else who says, I just want more adoption. I want more people to use open-source software so I don't have to spend money on licensing. Or it could be, I want more adoption of my open-source projects so that I can make more money. Right? All of these things are the reasons why people start to do this. Ultimately, people just want more usage, more adoption, more of what they're looking for. So a lot of what we have to do is help them get that more. So that's what we're going to be talking about. So I mentioned open doesn't always mean the same to everybody. So if you look at the different open signs, all of these say that they're open, but they're all slightly different versions of open. That's something that is incredibly important because as you start to think about how open you're going to be as an organization, are you going to put your bug database open? Some people do, some people don't. I know open-source companies that don't because they don't want to expose some of what's going on behind the scenes, especially for enterprise customers. Right? Do internal teams be open or are they externally very opaque? So internally we're going to share, we're going to have this very open culture, but then externally we're not going to share anything. Some people do that because they want the benefits of open-source without having to share externally. Right? You might hear inner-source sometimes or other terms around that. Do you allow your engineers to talk at conferences? Some people don't allow that. It's interesting where some of the people that I've worked with, big corporations, Fortune 500s, where they'll have huge open-source program offices, lots of open-source usage, but no engineers are allowed to ever speak at a conference. That's weird. So some people here would be like, wait, how is that open? But for them, that's their definition. So they're starting to do that. Do you can participate in competitors' events? So we've invited all of our competitors for years to our events, some come, some don't. We're very open because we're about collaboration. It's not about competing, it's about how do we make open-source better? How do we make more people adopt open-source? But again, everybody's a little different and your definition of open is going to color everything else that you do. Now, the first step in defining that openness and how open you're willing to be is determine where the lines are. So you want to ask people internally, what are we comfortable with? Are we comfortable with sending those engineers? Are we comfortable with exposing some of our dirty laundry once in a while to the external user base? These are things that you need to understand and define upfront because these are going to be battlegrounds that come back to bite you later on. Because if you're thinking, hey, I'm going to be this really open company, some companies share salaries externally, some companies give all kinds of internally available data. If you try that and the company's not ready for it, that could set you up for failure or some really not nice conversations. But transparency is really crucial. The most transparency that you can give, the better off you're going to be. So if you can share your roadmap, share what you're going to do, you want everybody to understand where you're going and where you want to take them. So ultimately though, I view the role that we have in what I do is connecting people. It is all about people. And so every time that we talk about the open source program office, whether it's in a commercial entity or an open source entity or somewhere in between, it's about connecting people, right? And you have to understand that just because you build this program office doesn't mean they will come to it. Doesn't mean that you will get the contributors, it doesn't mean that you will get people who are interested in your project. And there's a fallacy that goes around just because we're going to be more open means we're going to get more. There are a lot of projects out there, a lot of companies out there that struggle with this. They turn to open source, they don't get whatever their why is, which could be revenue, could be user adoption, and then they change their focus. How many people have seen the license changes and all that fun stuff over the last few years, right? Companies aren't getting the outcomes they expected. And so, hey, whatever their program was, whatever they were trying to get, whatever they were trying to achieve out of their open source journey didn't materialize. And that happens more often than you want. Even if you have the best documentation, even if you have the best setup, it's not necessarily going to guarantee success because it really boils down to people. Internally, it starts with people, right? So at your companies, how many people buy into the philosophy of being open? How many people buy into the philosophy of open source? Do you have people who are very zealot about it? Do you have people who are mildly okay with it? Or do you have people who hate it? And the definition and how you flow between those is important. So winning the hearts and minds of people and having them understand the power of what you can do with an open culture is super important. And you have to be very clear about what you're trying to achieve. And this is where that openness comes in. Can you share your goals? Can you articulate them? Can you articulate why it's important to you? Because if you can, you can get other people excited about it. You can make it easy for them to contribute, make it easy for them to be part of this journey. And that's gonna lead to success. But you also need to be mindful that you need to be part of their teams. So I know people in the open source program offices who never attended engineering meeting. I mean, I don't know, maybe you guys don't. But if you wanna be part of that engineering process, going to those meetings, going to their team get-togethers, understanding what their pain points are, it's incredibly helpful because you wanna be part of their team, not a blocker to it, or not some stumbling block. Super important. But externally, when we talk about the external side of things, it's also about the people. Because you want contributors, you want feedback. We heard earlier about how it's not just about code in a previous session, right? It's also about those other contributions that go beyond that. And so how do you embrace your contributors, not only the code contributors, but those users of your product or of the project that you're trying to put out there. Are you friendly? Are you willing to talk to them about why you denied a PR request? Can you have an open conversation with them and do they feel comfortable bringing to you their issues and their challenges? It's the golden rule, right? Treat your users how you want to be treated. And how you treat them matters a lot. And that's gonna help grow. But you also have to have some common sense rules because even though we all have policies at our companies on what we do to contribute and give open source to our users, the external users don't necessarily have those same policies and philosophies. So we have to understand that there's a two sides of the coin. You're trying to protect your business and you're trying to protect people who are using open source internally. But as you get external contributors, they might not have the same goals or the same thought processes to implement some of your processes and procedures. And another important point when we talk about openness is people like to connect with people, okay? And I don't know if you've helped your neighbors recently, but if you know them, you're more willing to help them. And if you don't know them, you're kind of like, oh wow, that was bad that that happened over there. I'm just gonna go do my thing. Because you wanna connect with human beings. And part of what we do is connecting, right? We're here at a conference. We're connecting. We're meeting each other. We're talking to people. Once you know them, you're more willing to go up and say, hey, how was your day? You know, hey, you wanna go grab a coffee. You wanna go grab a drink something, right? But if you don't know people, that's something that's gonna block people from contributing, block people from using. So how do you put the face, the human face on the projects and the things that you're doing to attract more people? Now, this all starts in my opinion with your willingness to share. And this is part of this open philosophy. How much are you willing to share externally? How much are you willing to give back? And I know we have a lot of different roles. And like I said, everyone has a little bit different definition of how they're implementing their program office. Everyone's doing open source, just slightly different depending on their goals. But it all starts with how much you're willing to share externally, how much you're willing to open up and show people what you're trying to do. Bring them along on that journey, right? And this is before any code changes hand. You don't even need them to write code. You need them to understand what the project is, why it's important, how you're going to use this to change their lives, right? And how you're present in the community really does matter. So being here at the conference is great. Talking at a conference even better. Doesn't have to be this conference, it could be others. Share your journey, share what you're doing because that's gonna be really important to attract people. It's gonna attract new ideas. People are gonna come up and talk to you, ask you questions about why you did this. Did you ever consider this? You want that feedback, you want them to participate. You want people to feel heard, there we go. And it has to be regular and consistent contact, right? So you don't want just this once a year you come out from the gates of your office and you work around the common folk and talk to them, like, hello, you don't want that. You wanna be able to always be there for your users and make sure that they feel like they have channels internally and that's not gonna always be you personally but someone on your team has to be able to do that. And so how do you make that happen? And that goes to providing help, right? Forums, how many of you have like discord, Slack, something for your external communities, right? How often do posts go unanswered for more than like, a day to a week, a month. It happens because everybody's so busy, especially when they've got their own internal users. But we have to start to think, how do we use these external folks as an extension of our teams and treat them that way. Now, clear contribution guidelines are super, super important. Now, when we talk about policy, some people go, oh, guidelines, oh. But they are important and the easier we can make them and the more plain language we can use, the better off we'll all be because we want those external users who may, again, may not have the same sort of background that your teams have to be able to say like, oh yeah, this interests me. How do I contribute this? How do I get this in? How do I start? I've talked to everyone, all the different booths. I stopped by, I talked to people. You know, one of the things that I heard a lot was they're focused on making things easy for their users because the barrier to entry is just getting lower and lower and the expectation is it's just click a button and it's ready to go or you can get the code and you can start contributing day one. So how do you lower that? Strive for that easy, super easy, easy to understand, easy to use. Now, we need that alignment across all of those people, internal, external, management, you know, individual contributors so they all understand so we can all make the journey very easy for all of us and that's an important thing for all of us to consider. Now, as we start to do this, we need to understand again, as humans, we need to uncover and understand each other's passions and kind of like, get that tickle in the back of your brain going where it's like, ooh, I have an itch and I need to scratch that itch on something that you're trying to do and uncovering that passion is incredibly important and that's why while you have a lot of focus across the Ospo land in the governance and process, there's a lot of Ospo's and a lot of companies that just implement the governance side and never think about the evangelism and we're not just talking about like an external evangelist who goes from conference to conference and like talks about how awesome their software is. No, no, you need evangelism internally as well because that alignment and as you try to adopt more software as you try to move more into different channels, it's important for people to understand the whys but also get excited about the possibilities and so how do you get them excited about those possibilities? That is a critical thing and that Ospo role that is a classic role with that governance has to be kind of merged with someone who's out there and can talk to the developers, talk to the end users as a member of their community and get them excited because if you can do that, you're gonna totally move mountains. So how do you get that passion? And these two roles are often two different skill sets, right? I am not good at like following process. My two bosses are here, they can probably tell you that. You know, like I'm great at getting people excited about stuff, you know, but you know, I can come up with a process, I can't follow a process, right? But when you understand that a program or a process is in place, it's better. So how do you get them to understand that, right? You need people who want to contribute and are active contributors themselves in a lot of cases, right? You need to walk people through those amazing things and then you can worry about like, let's do those amazing things legally, right? We don't wanna do anything illegal, we don't wanna get in trouble with compliance. I don't like to get in trouble with compliance, I don't know about you guys, it's not a good day when that happens but we wanna make it easy for everybody. Sorry, I went one through. So realize you're also gonna be dealing with a lot of competing worlds. So as we start to evolve into a more open culture that shares more, you're going to have very different worlds at play and you're going to have to walk the line on what sort of people you're working with at your company. There are going to be a lot of diverse people that you're gonna work with and meet. There are gonna be people who have never ever touched open source in their lives and you're gonna find that there are people who get scared by some of the things we try to do because they're gonna look at that as we don't share that information, how can you give that externally? That's gonna give our competitors an advantage. So you're going to have this push and pull and the larger the organization, the more you get that. And as you get larger, larger and larger, that's gonna become more of a problem. So how do you walk the line with being able to be open, being able to be part of that open source community as well as have good relationships with those people who are critical to your businesses? That relationship, that people building is very, very important. And it's a lot of breaking down silos, especially as these different groups and these different factions internally could potentially build because everybody has their own projects, own things that they're working on. How do you get time? And you have to be able to, like I said, be part of that team so each individual department, each individual person knows how they're impacting one another. I mean, even in the most open cultures, we have people who, Team A is really busy so they can't contribute and they don't work with Team B and they're really busy and they go off and do two separate things and then how do you get those back together? That's a problem that exists in every company. And so breaking that down and understanding those competing priorities is really important and working with them. Now, because there are those competing priorities, we often get into the philosophy and the thought process that everyone knows that we're doing this open source thing. Everyone knows that we're trying to do the open thing. Everyone knows this is what we're trying to accomplish. I can tell you that assumptions are the death of most projects, right? Especially when you've got multiple competing factions and multiple competing groups that are all working on their own independent goals as well as the company goals. That doesn't necessarily mean they know what you're trying to accomplish. I can go out there and I can say, I want to evangelize to everyone that development matters. Like that, hey, your design impacts your performance two, three years down the road, but if the marketing team is overdoing something else, I can assume that they know. That doesn't mean they know. So I have to be very transparent about what I'm doing. We have to be very open. We have to over communicate in a lot of cases. So avoid those assumptions. Now, this one is always a touchy subject. And so I'll tell you, when I worked back at MySQL, AB, my first day in, they were having a debate on open core. So it was probably the first open core model that was out there. And so the passions ran really, really high. In fact, I remember there was an email distribution where Martin Mecos was being called. All kinds of names, not very nice names. People saying that he belonged in hell or going to places you don't want to go. There was some really passionate, hot headed debate there. Doesn't necessarily mean that that was a bad thing. In fact, I remember telling my wife, I go, hey, I'm shocked because I wasn't in the open source. I mean, who's gonna get fired over this? Look at these people, what they said, over open communication channels. Now, that was a bit extreme. But I remember having a conversation with my manager and hearing from Martin himself that he welcomes passionate debate. Doesn't mean it's gonna be open forever. Doesn't mean they're gonna get their way. But everybody has an opinion and you want people to feel heard. So you're gonna have people who are very passionate who don't agree with you. How you deal with them? That's gonna define a lot of how your community grows. And so you want to make sure that you give that passion of voice, but avoid toxicity at all costs. There's a fine line there, right? You can have a debate. I can yell at someone and say you're wrong and I can try and convince them 10 ways to Sunday. But if you can go out after that and have a beer and be best friends again, that's what you want, right? If you say like I never want to speak to that guy again, we've probably got a toxic environment. So you want to avoid that. So when we talk about the foundations for collaboration, cooperation and this openness, really you have to understand that it starts with your outcomes. The why, why you're doing this, what you're trying to accomplish. Focusing on the people first. Why the people? Because that's who you're really trying to attract. That's what's going to grow your community. And it's going to get people excited. You want to get people excited about what they're doing. You want to share your passion and ignite their passion. Because if you can do that, you can build that community quicker. Be open, transparent and consistent. So everyone doesn't make those assumptions that I mentioned that are going to kill your projects and be understanding that not everyone shares your same worldview or the same open source background and pedigree that you have. Because that's going to be critical as well. Because you have to work with these people on a daily basis. So you don't want to burn those bridges. And that's me with a hat on. And I'm talking on post Chris a little later. So if you want to reach me at Matt at Percona or on Twitter, you can. So feel free to reach me. So any questions? Anything anybody wants to ask? Great. Well, so a lot of it has to do with, again, it's igniting those passions. What makes them passionate? So I did a small stint at a company called Mattermost. Their booth is here. And they do open source Slack, basically, like messaging. And I remember talking to one of their contributors. And he contributed because he thought, hey, he wanted to run his own little server for his friends. But his big thing was he wanted to develop an app where he could track the feeding schedule for his snakes through a Slack messaging type app. Why would you want to do that? Who knows? But for him, it was like, this is really cool. I can get it on my phone. I could say, hey, bot, is Ralphie the snake fed? And it would say, yes, you fed him at X days. And this is what you fed him. And he was like, this is awesome. And so for each individual person, it might be a very different why from a contributor path. But a lot of times what you have to understand is when we talk contributors, many companies are thinking, how do I get hardcore code contributors? So maybe stuff written in C, you're written in Go. Whereas probably you're going to get more use, at least initially when you're starting out a project, getting user contributions where they're taking what's already built and figuring out new ways and just slightly different hackery things to move the project forward that could really open up to a whole new world. So it's the users who are using your project. You want more of them. And if you can ignite their passions and then you're like, there's just one thing. If it did this one thing, this would be the perfect solution for me. And if you can show that one person how to make that one thing happen, make it a reality, that's really going to drive a lot more contributions. So what does different collaboration between different OSPOs look like? Are you talking internally or externally? OK, so externally. So you're talking company to company. This is where you're talking a lot more on partnerships, how do you work together? How do you bring two software products together? That type of a relationship? OK, so I think a lot of that is about first discovering the common goals, the common passions, being able to talk to people about, like, oh, your product does this. This is really cool. How do you do this? Start asking the questions and be that really inquisitive person. You want to understand the other person's technology, how you might be able to work together. And then I think it's about sharing as much as you can about what your roadmaps are and how you could potentially collaborate and work together. I think that's an important thing for you to focus on is, where are the touch points that naturally occur and where do those puzzle pieces fit together? Now, there could be a lot of other stuff you could do. But a lot of times what happens when you talk to another open source maintainer, you talk to another project, you come up with this laundry list of things that are so awesome. You wish you had the time to do these and, like, oh, my god, if we could do these things, they would be so great. And so you go out there and you try and do those things. But they're not on the roadmap. There isn't more than just kind of that passing interest, and then they kind of go away after six months. So how do you find those puzzle pieces? How do you fit them together? Absolutely. Well, so this is an interesting one. So there's all kinds of different methods that you can try. Some of the ones that I'm a fan of, and I've seen implemented in different things, you can say, hey, every new hire across your organization has to do one Git commit. Finance, yes. Tech support, yes. Marketing, yes. It doesn't have to be code. It could be a documentation change. Oh, look, you misspelled this. But get people to understand what you're trying to do. That's one thing that you could do. That's just an example. But again, about relaying what's important about this project, why the contributions matter, what you're trying to do, if you can pitch the vision, and this is where that evangelism, this is where the getting the people excited matters, if you can explain to finance or sales how they're going to make x% more dollars if they do this, they're going to be on board. Whereas if you talk to engineering, if you say, hey, this is going to be really cool, you're going to do all kinds of cool stuff, you're going to change the world, they're going to be, OK, I'm all on board. So it depends on your audience, but everyone's going to have a slightly different pitch. But you've got to figure out what they want and what they're really focused on and then try and give them that. Great. Well, thank you everybody for coming. Appreciate it. And swing by our booth or my talk later on, where I'll wear the hat again. So.