 All right, so we're at 55, so let's get started. As you can see today, we'll talk about open source and leadership in open source, and I'll try to apply a lens of enterprise to this conversation, but really, some of the learning, some of the practices I highlight, and if anything, it's just guidelines, you might apply to your individual projects as well. So it's something I'll discuss today, good food for thought. All right, what do I do? I am an open source developer advocate at Meta. You can find all about our portfolio of 700 or even more open source projects that we focus on on our website. Just search for Meta open source. I work with open source and also familiar apps, so WhatsApp, Instagram, Messenger, like basically anything in between. And more importantly, I'm passionate about open source. I go to conferences quite often. I mean, not so much lately, but in 2019, I used to go to a lot. And these days, I'm glad to see more and more people in person. This is actually one of my first in-person conferences, so I'm very excited. All right, so what are we trying to do today? And I always like to establish expectations, because that's, I think, the key with anything. We will talk about why we need to do open source, why we should, how we do open source. You know, I'll approach it from my experience, but really it's not specific to Meta, it's just broadly for open source. Some of these practices can be used. And we'll talk about some potential open source metrics that will help you define success of your program. All right, so Meta open source. It's what I'm, you know, my experience is based on, but really I'll talk about broadly open source. And what is open source? Of course you are at the open source summit, so me talking about definition of open source is kind of silly, I'd say. At the same time, it never a bad idea to restate the obvious. In this case, you know, it's defined as process of making technology, available for others to use and improve. But what it actually means is that we all work together as one community to improve the particular software or knowledge as a whole. I really like to refer to academia. In academia, the main goal of like doing a PhD or doctorate or anything like that is really to enhance broader knowledge in the world. And I see open source doing kind of the same thing, not necessarily knowledge, but maybe some practical things. So why would we contribute to open source? And again, as I mentioned, I try to apply a lens of the enterprise, but you can apply in a more personal, individual level as well. First is the community. Second is leadership. Third is productivity. And last is branding, which I'm not gonna dive into too much, but really the branding part kind of traverses every other why, every other reason of doing open source. So let's take a look at the first community reason. And the main reason, why I'm actually starting the presentation with this discussion is so for your program to be successful, you need to be honest and clear with your stakeholders, internal and external, why you're doing it. And making it clear for yourself is quite handy too. So community, if community is your goal, in that sense, in the sense of open source, it's really reinstating this approach that people behind open source is really the very core of open source software. And working with that, working with that reason, that goal of yours, implies that you need to focus on the narrative, especially if you have multiple open source projects, how do they work with one another? How do you work with your alternatives? How do you interact with your community at large? And having that narrative down, written down as the company or as an individual team is very important. Defining the roadmap with your community, if you have a largely open source project that is controlled or worked on by your organization for the most part, and you're mostly sharing with the community, giving them insight into what's coming, letting them know what's on the roadmap. At that level of transparency, that if anything with enterprise level open source, I see people looking for the most is transparency. So you're giving them idea of what roadmap looks like is very important for your community at large. Okay, it throws, and I don't remember it by heart. Of course it did. See, and I'm not even doing a demo of this talk, and it's already breaking. Okay, let's slide show. All right, then also content and a larger, let me just turn off this clicker thing. It should work, I have no idea why it's not working. But basically, yeah, the content and engagement is for your community to be successful and not just having silos throughout your project where only the people who created the project know a thing or two about it or can contribute and enhance the project, you need to have a way for new developers, for new contributors to work with you, to work on the project. And for that, you need to have content, you need to have proper documentation, you need to have engagement. Be basically on the channels your audience is at, Slack, email lists, forums, whatever it is. But really, have that funnel built for your community is the way to go if community is your primary goal. Okay, let's just see. Okay, leadership. Let me just see how it works. Leadership is the next reason to do open source and when we work on, Of course it does, and this doesn't work, let's see. If we work on leadership, the type of work we'll do, I wish I had like a sound board, like a drum roll or something. Okay, so for the leadership work in open source, it's, some people also conflate or, you know, have a synonym of governance. You can either perceive yourself as the primary leader in the space but also you can provide governance support in a sense that you help bring people with different expertise, but you overall navigate that space. And what I mean by that is you can approach leadership work through strategic planning. So basically working with your project and your community on overall strategy, where are we going? And more importantly, if anything is a life cycle planning, because everyone is very excited about launch, but how are you gonna land that or how are you going to archive that project or give away to another organization. Thinking of that early on is one of the main ways for a project to be successful, because if you just, you know, try it out without understanding how where they're gonna go, it gets tough. You might not know early on and you might need to pivot, but having those thoughts and discussions early for the entire life cycle is very important. Compliance is extremely important as well. You have the entire tracks here around that with open source licensing, code of conduct, all these areas are extremely important and very important to get right. Fortunately, the open source is exciting because you can connect with others at events like this to ask questions, to inquire how other people do it. And so compliance work is very important if leadership is your goal. But in general, things like code of conduct are non-negotiable, you do have to have that to make sure that open source overall is a safe and comfortable place for all. And by the way, I'll share all these slides on my websites or if you go to my Twitter account, you'll see it there too. So, but more importantly, when it comes to leadership work, it's coordination, right? If you do it yourself as an organization or as part of a foundation, which we might have quite an experience with and you work on coordinating with the entire space on where the project gonna go, or you might have work groups which we experimented and worked on with React quite extensively lately, it all really goes towards that leadership work and leadership goal that companies might have. Productivity is another reason for doing open source. And what I mean by productivity is a very long paragraph that I wrote here, or yeah, this one actually I wrote. But really what that means is by opening up your project to all by making it open source, you can shorten your feedback loop, meaning if developers are your customers as well as users of the software, you can get the feedback from them early on and act on that and improve your project. If you can go through all the stages of Alphabet and GA, actually releasing the project very quickly and early on and open source is fantastic for that. You can improve your workflow, right? Cause open source people can say this CI, this continuous integration, integration we have for that monitoring tool that we use in our company is fantastic. Let's bring it to the open source and then you as an organization see that it was successful for one open source project, you bring it over to another or to your organization. You can also think of new perspective and new use cases. We at MATA had examples where we would release support, let's say for iOS or Android, let's say we release something for Android because that was the use case internally. And then at the later stage the community implemented support for iOS. And you can think of how much the scale of our work improved cause we ultimately then decided to work with iOS as well and bring back that contribution and use it internally. So your productivity externally and internally can increase drastically by working with open source. But productivity work doesn't come for free. You do have to do some, put some effort into that. And that thing, you need to increase collaboration, actually have the interaction with your community. If people are making a pull request or filing an issue, there has to be a two-way street that you need to answer. You can just leave that project laying out there with no activity unless you're clear early on. This is an experimental stage or this is just us sharing the work, making all that clear and making clear collaboration is the key for productivity work reasoning for open source. You can seamlessly integrate new tools into your open source cause especially if it's early on, it's very much open and very flexible so you can integrate things into the workflow right away. You can work on certain data and metrics whether it's telemetry data or just granular like usage data, you can do all that in collaboration with your community. And again, as I mentioned before, it's the faster feedback loop, the shorter feedback loop. Here early on what the issues are, you get a broader scope of the users who have a direct channel to you and each other to ask questions and file bugs and create features. All right, so the next really, why is the branding? And branding by itself is not good enough reason you have to think of the other three whys behind it. But ultimately you get to the branding point indirectly through doing well either of the community leadership or productivity or all at once, which is actually quite difficult to do. You can learn more about this topic on the YouTube channel from Meta open source where I, for example, talked about open source quite a bit. So how do we actually manage open source and work like that in the enterprise level? People would sometimes refer to something that's called OSPO or some people would call it open source office or open source console, many other, you know, wording whatever you wanna call it really the way it's defined it's the organization or formal or informal, it can be usually the way I saw it, it would be several stakeholders across the company working on the open source operations and structure. And what it means is responsibilities are actually quite well outlined in a couple of resources I'll link, but some key ones is the strategy work, actually figuring out what are you doing and why you're doing it. Prioritization, whether it's prioritizing the particular work streams or even what events to sponsor, where the audiences are, all these discussions can come and go to the OSPO. It's tracking performance, right? Cause you don't want to just release the project and never actually look at how it's performing cause in order for that project to go through the life cycle of increasing the development or winding it down, you need to have some metrics behind it and that's what the OSPO would do. And really community engagement, again, organizing events, connecting with people, sending swag, all that, sometimes more or less formally done through OSPO. And there is a great place called to-do-group.org that has an entire guide about open source OSPO as a whole, which is funny because then it's linked to Linux Foundation, which has a great guide as well. So if you go to this site, you're not gonna miss out on anything OSPO related. But how do we do open source? In general, I usually outline five types of work that I've seen. There is planning work, when it pertains to open source, there is branding work, documentation, and code base. There's also the fifth one, think about what the fifth might be and I'll tell you later in this presentation. So talking about the planning, and I already mentioned before, but really you need to ask why of the any open source projects that come your way. I work at a company that we sometimes get, not sometimes, we're often actually part of the job. You get requests from teams wanting to release an open source project. And it's important for me to make sure they understand their why. Because sometimes people think open sourcing is the goal of itself, it is not. Open sourcing for the sake of open source is not good enough. I usually suggest them a couple of goals that they need to go back to the drawing board and make a decision on. And it means one of the goals could be recruiting, try to recruit more people and sharing your work publicly could be one of those goals. Contributions, you actually are looking for different contributions. Not all projects are doing that though. But you need to make it clear externally and internally and in order to do that, you have to set that goal early on. Branding, again, it's kind of related to recruiting indirectly but if it's just about your work in AIML or big data or in that space, you'd like to share with people. And also it's actually good moral booster, I see. Some developer, most developers that I've seen myself, they like to share the work publicly and it's just easier to talk about it when you go to a conference, when something is open sourcing and talk about the work you do cryptically. And really it might be an option. You actually want people to use your software. You have to think long term. And again, it's type of open source work you need to start with if you're doing open source of any kind. But the more important thing is, figure out if your team actually wants to do it on all the layers, right? Not just the individual contributors but also management has a buy in and one of the ways you can help them understand the importance of open source is through defining what Ospo is, defining the overarching narrative for the company and that way they have already reference points, they know how to debate over doing open source or some feature work for internal stuff. You need to make sure the team is committed, especially long term. Because if they just open source something and forget about it, unless you make it clear, I consider it to be a failure. So branding type of work, it's not just marketing, it actually shows commitment. And I'm not talking about committing with money, you can do a lot of things without much investment, budgetary, financially wise. Branding can consider things like name, have you thought of your name before you named the project or published the project? Have you thought of search engine optimization? Is the project already very popular in different space and if people start searching for it, that thing comes up first over your project. So you have to think about that. Logo as well, narrative around your project, maybe it's part of the larger work that you do. And the social media, right, getting proper handles on different social channels, that's important thing to consider. And one example I like to give in terms of, it's not about the money necessary and it's actually a great opportunity for contributions. DocuSource is a big project that we have public from Meta, it's a great static generator site tool. And this is the logo that we currently have, very cute, very nice. This was the original logo, it's also a dinosaur. And it was written made by one of our contributors who wasn't a meta employee, but that person contributed and it was a great contribution that went into history of the project. But again, just highlights, they thought of that, they worked on that. And again, it was one of the ways people were able to become maintainer by doing the logo work, the design work, which is very important. Documentation, I always put documentation over code base because the code base, people sometimes put on the pedestal saying that this is amazing, this is the most important thing. Documentation is actually the key for any successful project. If you look at statistics out there of the top projects, you would see that they all have proper docs. They have ideally a website which is searchable because people go to those things like documentation and sites when they are encountering an issue. And so people who are gonna start working with your project, the contributors, those who try to use it, they would encounter issues because people who work on projects full-time, they often don't know what they don't know or they take a lot of things for granted, they already have everything built on their machine. They never actually went through building the same project on another operating system, but your users might. And so having proper documentation is the key. And again, as I said, it's one of the cornerstone of open source. And as I am a firm believer, it's what makes a break a successful project. So when it comes to documentation, again, it's great for contributions. We are holding a docathon for PyTorch related this month, you can register at PyTorch.org. But basically, again, it's one of the ways we get people who might be first intimidated by the project and contributing to the code base, they might see documentation as the better place for entry or in general, they'd like to improve the educational part of PyTorch. So this sort of work is great for people to start working on the project. Making your documentation searchable. Usually we do it through creating a website. DocuSource is amazing for that. I'm quite biased, but I can say that. You can also use tools like AlexJS, which is a great linter to find, unwelcoming words that you might be using, whether you are doing it intentionally or unintentionally, AlexJS and similar linters will be able to highlight it in your documentation to make sure documentation is welcoming to all. Because that's the key of open source. And the code base work, one of the main things are every single code base, every single project that we release at Meta, it has several files, including code of conduct. It would have readme where we really explain what the project does, why people should use it, and how to get started. Contributors guide, because if you want to build the pipeline for your contributors, where it's usually it's users, contributors, maintainers, if you wanna have the pipeline, people need to know where to go. And also, in these days, we have great companies like GitHub or GitLab. You can have PR templates, issue templates, so your interaction doesn't follow with person filing a bug. And your next question is, how do you reproduce it, right? Or test is failing, they say, but they don't actually specify what they expected. So all of that is what you can avoid by having proper templates, proper process. So I've talked about four types of open source work, and the fifth one is community work. And community work, as I mentioned before, is, it has to be team-driven, team itself, internal or external, has to care about open source and work on that. It's often focused on content, because a lot of weather is not written content, it's video content, audio, whatever it might be, just has to be a way for people to learn about the project and work with it. Because some of the knowledge you keep to yourself, it's an asylum, nobody can actually enter that space. You need to have a community space for people to ask questions, whether it's coding questions or documentation or any sort of concerns, or they need to discuss the proposal. And all of that, they need to create a space for people to work together, and it can be whatever messaging platform you might use. And really, it's all about communication, especially if you're an enterprise. Talking to your developers, to your users is the key. It's the same idea in business, right? You, overcommunication is usually best. Of course, you take it with a grain of salt and you keep in mind legal implications and all that. That being said, if you approach it from the transparency point, or trying to make it as safe and welcoming for all, you would not go wrong. And Kemi Williams, one of my colleagues at the Meta, made this great video about contributing to open source for the first time in PyTorch, so you can get started right there and you can find this video on Meta, YouTube channel, Meta, open source YouTube channel. So with all that said, how do we know if we're successful? Is there a matrix? There's some single matrix that everyone can use. There is no such matrix. Everyone is different, every project is different. So I answered this question again, like every consultant would, it depends. And so some of the metrics we still collect and focus on and try to define, you know, successor health of a project, repository numbers, right? Or package downloads, independent of the project and the space you're in. If you're working in different channels like Reddit, Stack Overflow, Q&A forum or social channels, what's the sentiment analysis of that? Positive, negative, what's the share of voice? Very marketing terminology now, but it's basically how many people talk about your project versus the alternative. So things of that nature you can collect and work on and there are many tools out there, open source and none. Twitter and YouTube, as I mentioned, yes, please. We do, but it's not open source. We use a couple of enterprises once. And we do use quite a few enterprise and social media management companies that do that. They aggregate data and they provide reports and things of that nature. But there is the great thing called CAS, C-H-A-O-S-S, which is a great open source framework for measuring health. If you just search for that, you'll find that one is more guidelines than a tool, but that will help you to pick a tool that will work for you. Great question though, thank you. So yeah, Twitter and YouTube, you can actually have a feedback and comments and figure out what's next. And third-party tools, there are quite a few out there, but really there is just no single place, single health metrics that will work for all. It depends on your market, on your audience. I've worked with projects with, where the total audience in the entire world will be like 300 people. So you would approach it very different from a community of like a couple million, right? So it really depends. Call to action, really strategize and prioritize when you work on open source in the individual level or in a corporate level, figure out why you're doing it, what's your end goal. Know your community, know who your audience is. Same as in business, this is really, doesn't differ that much. You need to be, you wanna be nice, you wanna be, make sure it's safe for all, welcome into all, and you over-communicate the same way you would do it with any other thing. And still collect metrics. Obviously make it, you know, work with the community what type of metrics you collect. It's in open source, it's actually very easy because it's an open space, right? It's public already. But collect the data so you can, ideally find some correlation. Relation doesn't mean causation all the time, so don't try to make that extrapolation. Oh man, I'm almost talking like poetry now. But collect the data so you can figure out whether your efforts are successful or not. And with that, thank you so much for your time. Please reach out to me in these places, ask me questions, you can also find these slides which quite a few of them on my website. And with that, I appreciate your time and ask me questions, thank you. Thank you, yes, yes please. It depends to what extent we're talking about. Like our OSPO is cross functional, so it will be throughout the company from all the major stakeholders that being said a lot of the open source efforts throughout the company would be, I wouldn't say outsourced to us, but would be on us, right? So if let's say Presto and Big Data is working with foundations, it will come to our team, right, or if there's a GraphQL foundation and we work with GraphQL. So all the type of work would come to us. Your question about, like I mean, if let's say we're doing the meetup at one of our offices, we would reach out to security and like they would, or NHR, they would like issue temporary badges. Or if it's swag ordering, would have admins for that too. Oh, okay, yeah, yeah, yeah, we do. We do have a person who is focusing on legal, actually several people who focus on legal, and any open source. We don't call it OSPO, like formerly, we call it open source. Just open source team, open source department. I would have dedicated specialists in, let's say legal area, several, as I mentioned. Different levels as well, because open source dimension is extremely difficult when it comes to legal part of the world. We have special people for open source who deal with budget and invoicing, especially if you work with foundations. It becomes quite tricky. So basically we have all those covered. I don't know if I'm asking a question at all. Thank you. Thank you for the question. I do appreciate it. Any other questions? Yes, please. Generally speaking, we would centralize that budget for open source projects. But if there are extra requests, like let's say for some of the projects which were overwhelmed with number of pull requests and issues, we could talk about like hundreds and hundreds of those. For that particular project that's owned by a particular team, we would go to the team, I wouldn't call it begging, I would say, you have a problem here, you want it to be fixed. If you want it to be fixed in a way where we resolve the issues, you need to give us funds so we can hire an open source specialist, the contractor to work on that particular area. So that's where the budget's coming from the individual team because they have a particular issue. Because the other option we offer them, let's just archive it. If you don't care, let's just archive and you can step away from it. And making it clear with them right away is the way to go, I believe. But when it comes to larger budget for open source as a whole, as a brand, you have a dedicated budget and you figure out whether the brand is highlighted the most. If it's open source for let's say a particular sub-project, then you do get it from independent teams. But normally back for it, they know the importance because let's say membership to foundations, right? That comes with a number of seats depending on the level of sponsorship. And if the team or the project want to interact with them on the level they have been, right? Like let's say have technical guidance being part of the committee and also management like business side of things. They wanna have three seats. It means certain funds. And the team has to have commitment to actually go to those meetings and want that work. And then we'll get those funds. So really, we're not really bagging but it's kind of central. We try to centralize as much as possible because invoicing and all is very, very complicated. But so we centralize it for general purpose and for independent like individual issues we do ask individual teams on demand. Or like if they need the better documentation. Like our team, one of the things we do, we do find or work with teams to find gaps in their strategy. Let's say we find that they are liking proper documentation. We work with doc team that would find those gaps and to fill those gaps, our team not gonna go and write the docs for you but will help you hire a person to do that. It can be an agency. It can be an independent consultant or whoever else and they would work on that. So that's where kind of a budget is very big discussion point but we're never really back for it. Because if teams don't care for it, we wouldn't either. So the discussion never been that difficult in that sense. Of course if we talk about like CI resources and all that, that's a different discussion all together. I like GPUs and things like that but that's an entirely separate discussion. And I'm also very careful with what I say. Any other questions, yes please. I do apologize. I got slightly lost in a bit. So if it's in short, you had, can you repeat that one more time? Okay, make sense. President or not already, but it meant the project in the meanwhile I'm also finding a hard time for us to bring back that engagement. It's hard to argue, like there's a company that's building this. But that company started focusing on us, or their own thing. They were heavily, heavy contributors to the project before. Is that? Okay, and so to be honest, ideally, and I really like that model some of the big companies. Because the VV companies come with like, you can say anything of big budget, but when they're honest about the things they need, and they hire person to do that work. And many organizations hire an open source developer from the open source community that's already been big there, like have expertise to work on the area that they interested in. Rust would be a good example. I know of some companies who needed a particular functionality in Rust. Not talking about meta, talking about other companies. In particular functionalities in Rust. And rather than doing like internal work, I don't even know if it's possible. That probably is. But anyways, they hired that person to contribute and work with the core of Rust to actually have that implementation of that functionality that they needed. So if that is possible, that's the best scenario. But of course it comes with like full-time salary, or that's like full-time employee kind of thing. They focus on open source. You can sponsor a particular person who's really big in that space because ultimately open source is not free because it's time, right? So if your business depends on that, I would say you need to figure out how to connect money to that. Because just, you know, you can obviously do the hackathons, you can do, you go to universities, all that stuff. But still ultimately, there was a reason why that company went out of their way to build the business around it rather than just doing the open source, right? So if you know exactly what you need, you can find a person who already been active in that space and either hire them or sponsor them to do that work. So they have incentive to do that extra, go that extra mile, maybe in addition to the primary work to work on what you needed. But generally if you're trying to grow that project, I mean, that's a whole nother story, right? If it's community, if you just want, if you care about the project to grow, you build community strategy around it, figure out what people do, what the alternative is, meetups, some companies approach like bunch of meetups, some companies approach from articles and videos, it really depends, largely depends on your particular space and project. But hiring someone and giving that responsibility, developers generally are excited to work on open source. If you have an employee who is FTE right now, help them, ask who is interested, let's say, set in their expectations for their role, so they don't just do it like addition to their primary, like 40 hours a week, make sure that maybe they can spend 20% of their time on that open source work. So you don't need to hire maybe an additional person, but you can find a way to do it if it matters that much to the business, right? If it's a feature, if it's a community and adoption, different story, but if it's a functionality and technical part, there is no way around it. Thank you. I know, it happens, it happens sometimes. Thank you for the question. Any other questions? Yes, please. Good question. First of all, you need to spend money to get more money, right? It's like if you get a budget, you just spend it technically, but it's actually, I don't see it that much anymore anyways, but it depends. Depends on your leadership. Some leadership has the predetermined notion what they like or what they don't like. Like some might say, some type of engagement might not be their favorite. That means that you are an expert in open source supposed to be the one to define what actually matters and where to spend the money. In our case, what we do is we have a particular metrics we created, which is basically with every type of engagement we do, whether it's conference speaking, article writing, video creation, because it's also lots of funds there too, because even articles you can do ghost writing, video you can do video editing, like live streaming, all that stuff. And so we usually convert all that engagement in a single type of metrics with every type of engagement having its own coefficient and we report that metrics. And the leadership trusts us that we value each type of engagement according to what actually has the biggest impact for that space. So we don't tell them, we got like 100,000 views on a YouTube video. We say we got certain metrics that we have a particular name for of 100. And, oh, but we know that conferences don't produce that the conferences make, let's say one, right? It's a clear understanding that if we continue spending funds on something that produces one out of 100 with our video, it's clear that we are doing the wrong work, right? So we need to show that we focus on what makes impact. But with events, there's a different approach to things, right? Events like personally, I'll tell you my personal approach, going to many events at this point, I don't believe is the right thing for myself personally. Most of the projects I support are for a general brand, but I would go to bigger conferences, like a flagship conferences, like this open source summit. There's all things open every year. There's some big one Kansas City developer conferences that I personally enjoy. So you would find the ones that actually, the larger ones, larger events. And if I report my impact and money spent to my leadership on the general scale of things, I need to make sure that I don't just focus on spending money on that 1%. I focus on the thing that gives me a hundred. And so they would see that. And ultimately it's being on the same page and them knowing what you're chasing. And if they know that I need like a video editor on stuff rather than spending money on the contracting agency and vice versa. And they will see that I'm spending money there. Ultimately they just don't know what the impact is. So we spent a ton of time and we had great people focusing on that type of work to explain to the broader leadership why the work we do is important. What type of work we do is important. And after we got on the same page, we need to stick to that one page, the same page. So they know that we spend money where money give us biggest impact. So basically TLDR, them knowing what you're doing and just going to conferences by themselves, I'll tell you a story. I remember I was interviewing with companies for developer advocacy position. And when a company has a predetermined notion that it's a developer advocate, your main role is going to 50 conferences a year. This is a no go. This is a right away broken system because this hire would have been their first developer advocate. Instead you have to approach it. We have a plan, we have a strategy, we have a product to advocate for. Help us figure out how to get there. So if I were to just say, I'm all in on conferences, if I were a leader, that would not be enough for me. I would need to understand why conferences. Are you collecting leads because you're enterprise product? Sure. Are you doing sponsorship talks to broaden the, because other big companies doing sponsorship talks? I would understand that. But just making sure your strategy is aligned with your content. And then the budget comes. If there is an impact, the budget comes. I don't know. It's a long story with lots of branching out, I know. But that's how my brain works. That being said, I try to give you some anecdotal evidence as well that that's the approach. But really just telling you, spending hours and hours, spend hours and hours, many organizations I worked at, get on the same page. Because people sometimes, developer advocacy is very new position. Marketing as a whole. So defining that is very important. Because there's also like defining marketing versus developer advocacy. All that is not that easy. And it requires hours. I would spend more time on that than a budget discussion. Thank you for the question. Good question though. What time is it supposed to end? Is it 35? Good, because I'm in a rush. But please do reach out to me on my social channels. I'll answer any questions you might have. And you will see my slides on my websites. dvnik.dev. Thank you so much for your time and I appreciate you being here. Thank you.