 Thanks for coming. We're actually gonna, I think these two minutes will cost us maybe just one slide, but that's all right. So I'll just jump straight in. So we're gonna skip this, but I'll quickly introduce myself. So my name is David Hirsch. I work for Dynatrace as their OSPO program manager. I've been doing it for the last two years about. I'm also working with a few other open source projects like Captain, like Open Feature, some collaboration also in open telemetry, and then I'm also involved with some, let's say foundations groups. So to-do group, inner-source commons with their marketing group, and I think that's pretty much it. Then in my free time, I study artificial intelligence and at the same time, trying to get my MBA, but I don't know how that's gonna work out. All right, so just a quick intro into Dynatrace's OSPO. So here we're about 25, this is actually wrong now. We're about 28, changed quite recently, actually in the last three days. Yeah, we contribute to a lot of different projects. We're set up with a few teams where we contribute directly upstream to projects. So we have an engineering team that just works on open telemetry, upstream, things like this, and then we have other teams that are directly involved in specific open-source projects like, as I mentioned before, kept an open feature. And then we also coordinate all the contributions coming from other engineers within our organization, which are about, I think, 3,500 at this point. And here we just have a bit of an overview of places where we're involved, where we like to contribute. One thing I can recommend, which can be quite interesting if you like observability or you're interested in cloud-native technologies, is having a look at, is it observable? This is one of my colleagues who does completely technology-agnostic videos. So he just goes out there and goes pure open-source and works with things to see if they work and how they work. Yeah, so this is always the fun part. It's what's the mission of our OSPO? So we started out exactly a year ago, we actually started calling it an OSPO. Until then we were called the Innovation Lab. And this was the sentence we like to refer to the most, where we didn't really wanna be an open-source police, even though I think everyone here knows it's inevitable. And it's quite true still to today, but the objective was really to be this red carpet service. And by that I mean providing services to our open-source projects or providing education to our engineers and other parts of the organization. And we're slowly getting there, but it's probably gonna take a few more years. And this is the way we like to describe it. Wanna make sure that we contribute to the right projects. Wanna make sure that people can do this easily. So an engineer doesn't have to worry about, oh, what tools I need to use, or what is a CLA or can I sign the CLA and simple things like that. So we just provide them with all the information we can to make it as easy as possible. And at the same time, we also wanna build projects and communities. And that's why we work quite extensively at this point with the CNCF and the CDF and in general with the Linux Foundation. So let's get kind of to the real topic of today. So how can you help an open-source project? What can you do for it? And we've kind of found three main, let's call them themes or sections. First one is making sure your project exists for the right reasons. And by that, I mean just the question, should this project be open-source? We think this is probably the most important thing to do. We've had sadly a lot of projects in the past that were open-source because they want the community to take care of it, which is a lovely sentiment, but isn't really true. Then we have providing the right infrastructure and tools, infrastructure here, I mean from, sorry, code hosting all the way to tools that provide metrics to social media management tools for the community side, which then falls into the last bucket, which is building a community. And with this, I don't mean only communities around projects. I also mean a community within our own company because the idea for us is really to build in a way our own ecosystem within. You could look at it like in a source or just look at it as if we have our open-source projects and we encourage people to contribute to these. And so we're our own customer zero or our own contributor zero in a way. Yeah, let's try into the first pillar. So why is our project open-source? So here we developed something called an open-source canvas. One of my colleagues also presented this at the Linux member summit, I presented it in a few other places, but I quickly wanna have a look with you. So the first item is what is the strategic goal of this project? And this is the fun question that all our engineers really love when they come to us. Then we go on to why does it need to be open-source? And here, yes, you get that favorite answer, which is the community can take care of it and we don't have enough engineers to which we always answer, no. Why should it be open-source in a sense? Is there an interest from people outside of this group to contribute to this project, to use this project? And we then dive into better answers. And here again, value. So this is kind of complimentary to the second question. So why will these people contribute and what will they get out of it? Will it actually help them in something or will it just be another project out there that just becomes stale after a few months? Then we dive into a bit of a different section. So the first one is more strategic. The second, we go in more to the community side. So who is your target audience? Is this for SREs? Is this for DevOps people, for security people? Is this engineering productivity tool? What type of project is this? And who is your audience? Then contribution. So some of these you'll think are quite similar, but it just helps us provide a wider image of what this means. So contribution, why should people be contributing? Again, this ties in to also value and into why is it open-source? Then we have our engagement model. So engagement model here, think about how you'll interact with people. How will you talk to the contributors? Will everything happen on GitHub? Will it happen on Slack? Will it be a combination? Are you gonna try to have a very in-person community, or is that even possible? So it's thinking about all these items. And then here we have key activities to actually grow the project. Again, this could be organizing a meetup twice a year. This could be having weekly community meetings. They're endless possibilities really. It could be, I don't know, you wanna set up a hackathon on a monthly basis and make it possible so asynchronous people, sorry, so asynchronous participation is possible and easy across the globe. Then, so this part, let's say, is mostly focused, as you can see, strategy and community. Then we head down to the bottom, and this is, well, the business side. In the end, most of us come from or work in a company. So there will always be a business motivation behind your contribution or behind the establishment of an open-source project. So what is the business value of a project and how does the success drive business success? I'll show you some examples later of how we filled this out for some of our projects, so it will become also a bit clearer. Key resources. This one is, again, one of my favorites, I guess, when I talk with engineers or other engineers, it's, what do we need for this? And they said, oh, no, no, we don't need anything. We'll just, this will be our side gig. It will be maybe two hours a week tops. And this is where we remind them of the whole community side and how they actually need to interact with people. They need to answer PRs, issues, and whatnot. And last one, cost structure. So here we have three sections, again, strategy, community, and the business side. So what are the most important costs? This could be, what are the costs for setting up events? What are the costs for people you need to hire? General marketing budget. Do you wanna have swag for your community? And this is one of those things where we learned the hard way to answer that question upfront because we had some events where we realized we hadn't planned for budget and then it just wasn't possible anymore. So, now I'm gonna show you three examples of projects that are currently open source. One of them I would call open source with a lot of quotation marks. But let's go with the first one. So the first type for me is when you're open sourcing a project. By this I mean you've already established a project internally and you're now deciding to make the code public and open it up to contributions from external people other than your organization. And here my favorite example that we have is Captain. This is a project which we now open sourced. It is since two years within the CNCF, I think last year reached incubation stage. Here we noticed it was an interesting, it is an interesting project and but we noticed we made a fatal mistake which caused the community growth to be extremely slow. Why? Well, we contributed too much to it. In the sense so many of the contributions were coming from Dynatrace that we realized the rest of the community didn't feel like they had a say in what was happening. So this year we've slowed down, we've tried to change with the community direction of the project or the next developments. We've made sure that when establishing our governance board there's equal representation or let's say less representation on our side to make sure that all decisions are a bit more balanced and we did the same also for the technical committee. So right now we're basically, we're still in an incubation stage but we're really focusing on rebuilding this community to make sure that people again feel involved and feel like they have a say in what happens in the project. Yeah, so this for me is the first option. And here's an example of how we could fill out our open-source canvas. I'm not gonna go through all the items but feel free to have a quick look and I'll upload these slides as soon as we finish. And then we have option number two. So starting an open-source project. With this I mean probably the complete opposite approach. This means you have an idea, you maybe write a POC, then you decide to reach out to people that you know within the open-source community or that you know within the IT community in general. So it doesn't have to be that specific and you say hey, I have a great idea, I wanna do this, what do you think? And here the idea is to get buy-in as soon as possible from other individual contributors, other companies that work in that space to make sure that from the get-go this project is truly open-source and has a very diverse community behind it. And for this, I choose open feature. This is a feature flagging standard. Again, CNCF project, Sandbox now since I think last April. And here the first thing we did was reach out to all of the feature flag vendors and to understand if they're interested, if this is something they want to participate in. And the really interesting answer we received was yes, we are so interested in this. There was no way for us to do this with one another because we're all competitors and none of us felt comfortable having one of the others getting this started. We're quite impartial. We just want something that works. We don't really wanna work in that space. We just need a feature flagging system that works. It's simple and that doesn't complicate our life more than it should. And this for me was probably the best approach for open source, but that's just a personal opinion. And yeah, so here we have an example of the canvas. Again, I'm not gonna go too far. I don't wanna go through this. As you can see in the cost structure, now we added marketing and conferences, but they're still missing the little item with written swag. And then this isn't, let's say, a typical approach to a project, but it's one that we experienced and that was fun, traumatizing, exhilarating. It was all the emotions put together. I'm not sure how many here are familiar with Inner Source, so more or less, okay. So just a quick overview. Let's consider Inner Source would be taking an open source approach, but behind your company firewall. Essentially, people within your company are able to contribute to a project which has a well-established documentation, which has organization when it comes to maintainers, approvers, and similar. So it's your own little open source ecosystem. So here we had a fun experience, or we still have a fun experience with a project called monitoring as code. And I'm not too interested in what the project is. That's, if you wanna have a look, that's great, but it was really the process behind it. So we started out Inner Source, then no one in the company was interested. Perfect, let's open source it. I'm happy to say this was a few years before I joined, luckily. So can walk away with that intact. So yeah, in Open Source, and then recently we discovered that only our customers are using this. No one else is interested in it. And so now the question is, what to do with this? And that's why before I said we have one Open Source project. In a sense, it is openly developed, but we're not really looking for contributions. Someone wants that can, but it's not really of interest to many people for now. So let's jump into the second general pillar, so infrastructure. As I said before, for me this is code hosting, working with foundations and tooling. Code hosting in our case is GitHub. This has been a massive effort. Why? Because GitHub is great, but there's a lot of freedom out there for people to do, I'm gonna say essentially whatever they want. It's very hard to keep a very close and monitored view on what people within a company are doing, because anyone can open any repository with almost any naming. They can choose whether or not to put licenses, which is the fun part. And if we're not aware of it, it's very difficult to know what's happening. So actually here, I'll just go to the next one, yeah. So that was the first part about organizations in a sense. We found out there were 130 organizations with Dynatrace name. Some of them were experiments. Most of them had licenses. Some of them were empty and stale, and others were just, were ours actually. And we knew about them and had control on them. So I think now we've gotten to owning 20 of these. Some have existed for 10 years, but are empty. And the repositories, we don't know who owns them. So we're slowly working with GitHub to find out who the owner is and see if it makes sense to keep those out there or not. Users. So user management, for example, here this also ties into the tooling. We use something called Peribulus. So it's an open source tool for our user management. We haven't upgraded yet to GitHub Enterprise. We're still looking at whether it makes sense or not. But this provided us with the tool to manage users across multiple organizations and multiple repositories. So this was an enormous effort, was cleaning up the users and making sure that they were actually, people that still worked at Dynatrace and that still needed access. And the last one for me is templates. Everyone's like, yes, you love templates. Well, yeah, actually, we found this was a great way to get projects started a bit faster, providing a basic setup of what a person needs and sometimes even valuable examples of how to write a security policy or how to write or read me what should be in it, the structure of documentation. And the idea for us is now, soon we're gonna open source everything we have of all these items, whether it comes to tooling, documentation, our guides, so what is our process to open sourcing a project? Many other companies have done this and it's helped us also quite a bit. So we figured we could do the same. Yeah, and foundations. I call this standing on the shoulders of the giants. You can get so much information from either one of these websites. I find very useful, the to-do group. There are a lot of useful guides, useful tools, and if you interact there with the other members, you can really get some great information. Oh, yeah, and obviously, it provides a really good platform for projects. For the simple fact, you get visibility. And I would say even you establish some level of trust with consumers of your project. And tooling, yes. Again, here, metrics, health metrics. We try to use it as much open source as possible. So things like Grimoire Lab, sorry, DevStats, Linux Foundation Insights, which we're currently working with them a bit because we've noticed some irregularities in the information, but we're getting there. Usage analytics, we started working now with SCARF. Again, this is another open source project or at least it's free for CNCF projects. And then compliance and security. I'll actually be talking about that more tomorrow if you're here interested, but yeah, we try to, again, keep as open source as possible. So, phasology or using tools provided by the CNCF for a CNCF project. So, SNCC, and yeah, I think that's pretty much five minutes, so I won't go in. Yeah, so if you're interested in the talk tomorrow, this is shameless self-promotion, but don't read into that too much. All right, so let's go into the final piece, which is really community. So, community, a lot of people within our company underestimate the importance of this item. And for me, this is really the most important one. You can have all the tools set up, you can have great infrastructure, you can have an amazing project which can do incredible things, but if you don't have a community behind it, it will be extremely hard to get it used, to get people to contribute, or to get people interested in general. And again, this goes back to what I was saying before with some of the struggles we had, for example, the captain, which we're still having. And now what we're trying to do is we're slowly working with all the metrics and tools we have. So we have a mailing list that works with MailChimp, and that's a pretty interesting tool. We just recently went in to discover why are we having such a low participation in our community meetings. And we realized we have been offering community meetings in the wrong time. We thought most of our users were EMEA and an APAC. And we were actually quite wrong. We noticed recently that the majority of the people consuming the material we produce, whether it be YouTube videos, whether it be blog posts, even social media, whether it be tweets, all right, forgive me, yes, we still use Twitter for now, or whether it be LinkedIn posts, the majority of the people consuming this information were coming from the US. And we had kind of ignored this piece of information because the participants we were seeing in the community were mostly from Europe and Asia. So we weren't offering even a community meeting for the US, and that's something which we're now trying to fix to make sure it's a bit more balanced and we'll probably try to offer still both. That way all community members can still participate. Another important thing about community is how you interact with your people. So we mentioned this before. What are possible tools you could be using? We said yes, Slack, you can use discussions, Discord, you can be using, again, newsletters. Again, there, there's not one solution fits all. We had set up our own Slack workspace for captain, for example. Like not just a channel, we set up a whole workspace, a bit overkill, have thousands of people in there, fantastic. But then we went again, looked at the analytics coming from Slack and noticed that the participation was maybe a 10th of the participants, of the, sorry, of the members. So again, a lot of information and a lot of good details and good guidance can come from looking at metrics, which seems very easy and very straightforward, but sometimes it just gets lost, that information. Another important part we realized for community was you need a community manager. Maybe not a full-time community manager. If it's a small project, then it's just getting started. But you'll need someone that's gonna dedicate, I'm gonna say half their time, at least to this. And as it grows, you will eventually need someone. Right now, I'm also the community manager for Open Feature and for, in part for Captain. And I completely underestimate every day how much impact this has on the project. And I'm not talking about GitHub Stars here, I'm talking about looking at, are your contributors returning? Are they just making one small issue? Are they, sorry, opening one small issue? Are they submitting a PR? Is it getting accepted? So are you checking that the developers within your team actually respond to these pull requests and issues? They should. You want your community to feel like they're involved. Yeah, and the final part is creating, again, this open environment for your community, making sure that everyone feels welcome. Again, lots of good material coming from the to-do group here and also I think there's a specific CNCF group now dedicated to diversity, equality, and inclusion. I don't remember the exact naming, if it was a tag or a sig, I'm not sure right now. But that is another aspect to always consider. And yes, here are some other items which you can think about when it comes to community. Documentation and guides, how clear is it to contribute to your project? Is there a contributor ladder? So do people know what they can do or what to expect as they move forward? And it's not just writing a list of requirements in there, like, hey, you need 50 open PRs and I don't know, 10 issues and 20 lines of code. I have no idea, I'm really inventing at this point. But do they know what their responsibilities are? So if they become a maintainer, do they understand what that means? Do they know that they should really do their best to work with people that are opening a PR for the first time? So not just say, no, this is terrible. It can be true, they can put in a terrible PR. But the idea is you need to help them and guide them into making better contributions rather than shutting them down at the first go. Outreach, I'm sorry. Outreach programs, example, Google Summer Code or Google Summer Doc or the Linux Foundation mentorship. There are so many interesting programs out there. You can even work with Major League Hacking and there are, again, lots of other great organizations out there that you can collaborate with to set up good outreach programs, in this case, for coding. But I mean also outreach programs for me is also on the social media side, blog posts and general content that you're producing. We try to make sure that all of our community meetings are public. So anyone can participate, whether they're a member or not. Whether they've contributed before or they just wanna listen and see what's happening. And then we try to publish these as soon as possible also to YouTube. Creating interesting content, keeping it as vendor agnostic as possible. So even though, for example, with Open Future we work with feature-flagging vendors, the idea is to create content that can help educate the public and help them see the importance of creating standards rather than everybody doing your own and reinventing the wheel every time. And finally, events and meetings. So meetings, as I said before, community meetings are a great way to speak with your audience. Yeah. And events, I think participating in events such as this or KubeCon or other smaller regional meetups can be a great way to build community. Yes, digital tools for virtual communication work and our possibility. But I still think face-to-face can really help establish at least a smaller group of core people that contribute to the project. Yeah, we have people like, again, just an example of Open Future working with people from all over the globe and we met the first time at KubeCon EU last year and we were all in the same room and that was a great moment. We actually were probably more productive in two hours there than in the last and then in the three community meetings before because we needed that time to really get to know one another and to create this kind of bond. That's pretty much it. So does anybody have any questions or do you all so much? Any questions? How is to... Hold on one second. You want to mind? Thank you. So how is to get funding in terms of within the company to start an open source project? Can you give any guidance on that? Okay. So there are a few different options for us. As we have quite a big open source team, what happened for one of, actually for the last two projects was after the proposal, we said, okay, there will be just two people working in this and once you can demonstrate that magical, magical business value, it's a lot easier to then go to your CTO or whoever you need to speak to within your company to justify why it would actually make sense to invest more in a project. Here we said, okay, we could, this could give us better information. You know, an example, what is this? This is open future, yeah. So this could help us save money. We won't need, this will help us save money, save time, it will make our developers happier. This is already, let's say one justification. Another one can be also looking for ways to integrate it with how we work. And if you can demonstrate that there are use cases in the future that could produce revenue for the company or help increase the revenue, that's really a great way to go. And I think we recently had our planning and we submitted now our proposal and the idea is like, this is our justification, this is what we're able to do with our current team. And then we've kind of showed, hey, if we have another two people, we can also work on these features and grow the project even more. If we get a specific community manager, we can help the community grow around this project, that way we are not the main contributors, but we are just another member of the community. Or, yeah, if it's a strategic project like open telemetry, there it's really, again, similarly showing what type of contributions we could do at the moment and again what we could do with more people. Or why should we be participating in events like this or in events like KubeCon? And it's in a way demonstrating the return on investment, which is hard to do, but we're somehow getting there, like last KubeCon we saw, we reached out to, I don't know, 50 people that spoke with us about captain and seeing the number of responses we got, it's a way to show, all right, we're actually improving the possibilities of our community growing and then how many people after these contacts decided to join once a community meeting, decided to join twice, how many of them contributed once twice, did they contribute once in the go? So it's a lot of work the first time, but once you establish an idea, you can use this again. I hope that answered. Yeah, one more thing. Because we are going through the same thing in the company, trying to get funding to start working on open source project. And it's very difficult to convince business people like saying, and they want something in return. And it's very difficult to tell them, okay, let's say it's gonna help us hiding good talent in the future and it's gonna make our, we are using a lot of open source, we can give back to community. But some people don't understand that, they're just talking money, right? So when we say, okay, it might, there's a possibility of revenue generation in future. When can we, how can we pitch that, like, how to say that? Because it takes a lot of time to build something and build a community around it. And it's very difficult to say, oh, it's gonna generate a revenue, so. It's a lot of research, honestly. And when it comes to other items, like, it can improve retention. Luckily, that's something you don't have to do on your own. But there are, there is a lot of research out there from the Linux Foundation from, I think also the open source initiative has some similar research and you can use that. That's, there's numbers, there's good data in there and you can actually, I think you can even access the data yourself. So if you need to provide specific business reasons, it's all out there, honestly. It takes a bit to do the research. That's definitely true. Took us now, I think, three weeks of two people working on just preparing the business justification. It's extensive, but the idea is if we wanna hire people to work on that, we need to show them why. And that's usually the only question. Yeah? It might be a bit duplicated question, but for the business value and also cost structure, so you will sway your leadership to, okay, so let's open source this in line with the strategy, but do you have a measure after you open source and, you know, how do you, sorry, do you measure, did it, has it make a, profit, business values? Do you measure, I'm sorry, do you measure? Yes, it was right to open source this and then we can get this back. Do you measure that? Does your company measure? And then if so, how do you do it? Yeah, so for us, a big learning was with Captain. We based part of our product off of, I'm gonna call it the red hot model, so you have your open source side which has some functionalities and then you have the proprietary version which maybe has additional support or services on top and over one year, we measured really how many customers we had and we realized that people just preferred the open source version and then we decided to move away. It was painful, but it was necessary, so there's a way to measure and see like, yes, it makes sense, no, it doesn't and you just look at how many people have invested time and what your return was and if it's already on pair, then that's already not good enough most of the time. Thank you. I hope that, yeah. All right, but I think I'm- We do have one online question and this is gonna be the last question, I'm sorry. Do we need to open source a startup and what are the benefits doing so? Open source is a startup. I don't know if I'm well-equipped to answer that question. It depends, I guess. Again, I would do this or something like this and this is not perfect, by the way. This is on GitHub. If you wanna propose changes, feel free. Yes, you can open source a startup but I would say there's always that balance between how much time you're gonna invest and do you have a business plan in general? But I don't think that's covered by this. That's like a very much larger experience. Yeah, I have, yeah. Sorry, I don't know if I can- No, that's okay, that's okay, thank you and that's all we have time for, so thank you so much. All right, thank you everyone.