 So, today we're going to have a look at taking open source more in consideration as a product. Some strategies here and there of how you can really frame it in the right way and kind of I'm going to share also some of the strategies we used internally at Dynatrace. Yeah, but let's kick it off. So my name is David Hirsch. I work with the open source program office at Dynatrace. I've been there for about two and a half years. I contribute to a few different projects like Captain, like Open Feature, a CNCF ambassador this year, and yeah, I'm happy to be here today with you. So I always like to kick this off with a lovely consideration about open source. And the fact is, open source is pretty wonderful. It's essential. No software company can really survive without it. But the truth is that for companies it is extremely difficult sometimes to live in this space. So finding the right regulations, finding the right internal policies and all these types of things can be extremely complicated. And for those that are quite new to an OSPO and what you do or to open source, I want to quickly show some of the benefits and some of the, let's say, challenges that you may face. So some of the challenges are really mostly around the software development lifecycle. It's not the same if you're aiming to have a certain velocity. You're not going to be able to do this if you're contributing upstream to a project. You're going to have to wait for the other maintainers to agree on what you're putting in. And at the same time, you're going to have to learn to collaborate with other people that aren't in your organization. Then there's the fun legal aspect. Everyone here probably knows the pain of going to your legal department or similar and trying to really get them to understand the value of open source. And sadly most of the time this doesn't happen or it just takes a very, very long time to get things moving. And finally, as I mentioned before, you're going to be collaborating not only with other companies in general, but you'll even be collaborating with your competitors. I know we do. We work in open telemetry. We contribute. And we have to work with our main competitors out there. So that can be quite tough sometimes. And instead when we look more at the benefits, I mean, you really have at your fingertips access to developers from all over the world, from some of the best software companies out there. You're not going to be developing things on your own, but you're going to be getting things that have already been built. And this will really help you in having faster development, saving cost, saving time most of the time. But this is, you know, something you should look out to, look forward to, sorry. And finally, again, the collaboration here comes up on both sides. Your developers may really look forward to looking, sorry, to working with people from other companies. It can be refreshing. It's a great way to broaden your skills and to learn new things. So what are we going to talk about today? Well, I really want to start from somewhat of a higher level to show how we approach open source within Dynatrace. And we do this on a few different aspects. The first one as you see here is creating. So when we talk about creating open source, we really mean creation of new projects. This doesn't mean creating a fork of an existing project. This doesn't mean we're just going to put something on GitHub and let the community take care of it. But we're really talking about taking a more business approach to what it means to open source project. And to do this, we've started really to interact with our developers. And we asked them a series of questions to make sure they understand what effort goes into open sourcing a project. And this is something created by a person here in the audience, so Alois. So this is what we call our open source candidates. And if you have a look here, you'll see most of the questions revolve around really business aspects or around community. Really, things that a developer usually doesn't have to think about in regular development work. Because we want to know, how will people interact with the project? And what will they actually get out of it? These aren't questions that developers are familiar with. And it can be a little bit frightening. But we do our best to kind of guide them through this process. Yeah, when I share the slides, there will be a link at the bottom. And this is on GitHub, so you can have a look and interact with it. And I would say this covers solely the creation part. So anytime someone in Dynatrace wants to create an open source repository, we try to ask all these questions. Whether it be a real open source project or, let's call it technically open source. So something that we just want to share with the community. Another aspect that we work with a lot is obviously contributing. And this right now is probably the strongest area for us. Because we really want to avoid further fragmentation within the ecosystem. We want to make sure that we're helping out projects that already exist. That's why, for example, we work with open telemetry. I mean, we could create something similar, but that wouldn't really make much sense. And the effort would be incredible. This is also why we can contribute to other CNCF projects. I mean, as I mentioned before, open feature, captain. These are all projects where contributing brings us a lot more than doing it on our own. And I want to kind of go through the process of what we do when it comes to contributing to a project. And we had a few experiences over the last three years where we really had to tighten our belts and learn how to do things better. So one of the aspects we focus on initially is alignment. And this starts at a very high level. This starts all the way with the mission-critical goals from our company. And this means we do not create our own goals that will be completely independent, but they will be focused on the same goals that everyone else is working on. This way, we're not heading in a weird, strange direction that no one understands, but it's easy to recognize what our work is contributing to. But this alignment doesn't stop just internally. I mean, we're working with open source. So we'll be talking to people that aren't in our company and won't really have an interest in our goals or will probably want to maybe get in the way of our goals. Let's be pessimistic. So we have to go into the other aspect of aligning roadmaps. And this happens on a few different levels. So one of them is the community roadmap. And by this, I mean it could be an outreach program. It could be our community strategy for a project, whether we are, let's say, maintainers, or we're just helping out the project. What is the goal? How can we grow this audience? How can we make people more aware of what we do? And this is kind of one of the first aspects. The second is really on the product side. So we can't just say, oh, we want to contribute to these specific areas of a project. We think this is really interesting. I mean, let's be honest. We all work for companies. And we all kind of need to bring back value to our company. So we need to align with existing product roadmaps coming from other departments and make sure we're in sync. Again, this is about making our work valuable. And this is about making our work useful. The final one is aligning with the open source roadmaps. So let's say, in a way, we have three roadmaps that we need to consider. One is from the project itself. So Kubernetes has its roadmap. OpenTelemetry has its roadmap. OpenFeature has its roadmap. We need to take that into consideration. And we also need to take into consideration what we need internally. And when we put those together, that will kind of give us this point of touch between open source product and OSPO. And that gives us the ability to really plan ahead and decide what we want to work on. And this kind of brings us into the next step. So what we call our value of creation flow. And this starts at a very high level. So it goes from use cases down to features all the way down to the individual dev stories. We make sure that even when it comes to open source, we follow this type of process. Again, we're not owners of these projects. But we need to treat it as if it were part of our software. Because we want to ensure the same level of quality. We want to make sure we track what's happening. And we also need to have a process to develop. I mean, you can't just go along and do whatever happens. You need to coordinate. And this is one of our tools. And that's why we tend to mirror everything. Don't look at it too much. I don't want you to fall asleep. So by mirroring, what I mean is, when there is an issue in a project, we try to recreate this internally on our ticketing system. Yes, you may say this is a bit of additional effort for our development teams. But this is the best way we've found to really not only follow our best practices, also make the lives easier for our development teams. They're structured in the same way of any other product area. We have a product manager. We have a product owner, a team captain, developers of different degrees. We have program managers. We have community managers, developer advocates. And we need to plan what we do to make sure that we have a real execution when it comes to open source. And this kind of falls into the next part, which is really tracking. And I don't mean we're going to follow our employees around and see what they're doing. I mean, it doesn't sound like fun. What I mean is, this is the real moment in which we get to show how we're contributing and how much we contribute to our business. So by having tickets in our system associated with open source development, we can really see the time that is dedicated. What type of activities are these bug fixes? Are they new features, improvements, maintenance? What kind of activity is this? And this also helps keep our development teams kind of separate from the more business aspects. Because if we're focusing on things like adoption, I mean, developers can be interested in this. But they usually are developers because they love creating new software. Yeah, and we also make sure we track things like governance. How many people in our teams are members of governance committees, of technical committees? Are they approvers, maintainers? All of these roles take a lot of time and a lot of dedication. Some of them take even more time than just creating code. So we decided we wanted to track these as well. Because when it comes to justifying why you need 10, 20, 30, 50 people to work on certain projects, this is a good number to have. Because this is something that has strategic value long term. You are really helping the project grow. And you're doing it on different levels than just contributing software or with your more chopwood and carry water tasks. And we also decided to track the community efforts. This is a bit more difficult because this is something that kind of never ends and never really stops. So this is probably somewhere we need to get a little bit better at. Have we been able to create specific numbers for this? Maybe not entirely. But we're slowly getting to the point where we can track all the areas of contribution to open source. And when it comes to the end of the year, this is a very easy way to say, hey, all right, we may need more people here. We're holding governance roles. We're managing entire communities. Maybe we can help out these projects even more as we depend on them. And this kind of brings us into the community section. So I tend to use a lot of more business-related aspects when I talk about open source. That's kind of just a force of habit. But that comes from mostly speaking internally. But most of the time, I'm not talking with colleagues, at least not ones that work at the same company. I'm talking with people that work in other companies and just contribute to the same projects. And it's easy to forget that the community is what brings actual value to that project. If you're not able to build a healthy community, you're not going to have a healthy project. You will end up being the sole maintainer of it. Your company will essentially have developed a piece of code that could have been proprietary, but is open source for probably the wrong reasons. And yeah, sorry, I got a little distracted with this image today, so I had to add it. And when you talk about community, there are a lot of aspects. I listed many things here because many of them are extremely important and kind of the basis of how and why you can create a group of people that care and at the same time have people that interact with you and are happy to do so. I mean, a lot of documentation can help you. A little bit of very good documentation can be great. And that's why it's, I think most of the time we focus really on this, on creating guides for people. How can you get started with the project? What are the main features? And all of this goes into our planning. We try to create roadmaps on this as well. Yes, we do focus first on the community roadmap, so something that is open to everyone. But if we have personal interests in a project, we'll try and make sure we are the ones taking care of certain issues. This isn't because we want to limit other people's influence on our project. We just wanna help, we wanna make sure it gets done because having an open source project adopted by many companies helps us drive it, helps our business indirectly, and in the long term helps the project itself. We also try to engage with our community members. Events like this are a great place to do so. We try to make the time to go to KubeCon. We try to create initiatives where people can interact with us. Can be first time contributor meetings. It can be our weekly meetings. It can be really anything. Can be a simple slack bot that says hello when you join the channel. Anything really can help. I mean here I listed also outreach programs and these pretty much fall into the same category as engagement but you need to create content. People will want to see what your project can do and most of the time they don't wanna figure it out on their own. So creating a three minute video on how to get started can go a lot further than having 20 pages of installation guides. And yeah that line is all the way at the bottom because everyone hates that. I mean at least the licensing part is not that much fun but if you do it right that is a great way to get adoption. So that is pretty much one of the first requirements we put in our projects is make sure you have all the licenses in place. Otherwise you shouldn't make it public. Governance is quite a struggle. I won't lie. I think right now a few projects we participated in, we managed to have our first bootstrap governance and are slowly moving into our first election. But this is a great way to guarantee vendor independence and ensuring that people actually wanna use your project. So you can avoid cases in which license changes or complete direction changes of projects happen. And that's a really great way to do it is to have a good governance board in place. And you might be asking at this point does any of this actually work? I mean yes and no. So all of these slides and concepts and ideas that I showed up until now, it wasn't something that we just came up with from the get go. I mean it took about three years to get to this point. We tried out a few projects. First one is, for example, Captain. So this was probably the first real open source project that Dynatrace had. Something that we contributed to the CNCF. We wanted people to contribute. We wanted to be part of a foundation. Excellent. But we took a different route than other people might have. So we started development internally. And we ended up at the point where most of the maintainers were from our own company. Did we have adopters? Yeah, we did. That was great. It was lots of fun. But they weren't really members of the community. Because, I mean, we all know, companies really like free software that works. I mean, you can get it for free, that's great. So this was really a learning journey for us. We saw that if we wanted to do open source, we need to start things in a different way. Another project that we, I already mentioned a few times, contributed quite actively to is open telemetry. I think we're like the top fifth contributor of all time to open telemetry. This wasn't something that we just went and did with, let's just give code away. This is a great idea. No, we really, as I said before, here we started looking at it from a really strategic standpoint and considering it as a product. Because it is important to us. This is a way for us to make our customers happier, make their life easier, and in general, strengthen the ecosystem. So we don't wanna just have people that contribute code. We don't just pop in occasionally, open a pull request with hidden origin. No one knows what company you work for. We're members of the community. We have people on the governance committee, technical committee. I think we have like six or seven approvers. And this is a group of six people. Over the last three years have dedicated 100% of their time to just working upstream. That's all they do. So this was kind of the first part where we noticed we had to do things a little bit differently. And that led us into open future. So open future, we went a completely different route than captain. We knew we needed something. We had this problem internally. We wanted a standardized way for future flags to do future flagging internally. And we didn't know how to do this. We didn't know how to build it. So who could we go to? There are plenty of vendors out there that work in this space. So we reached out to them. And what do you know? The vendors were pretty happy to have an independent party that doesn't work in this space. We became the facilitators. And we got them on board before we had written a single line of code. And at this point, yeah, it's a CNCF sandbox project. Hopefully actually tomorrow, we'll know if we're gonna start our final, let's say, boat into incubation. And it's only two years old. But by involving other members of the community and getting enterprise adoption first, it was a lot easier to push this along and have people really involved in the project. And don't take my word for it. These are just some of the organizations that are contributing. We pretty much cover, I think, 60, 70, maybe 80% of the future flag market out there. I mean, when it comes to contributors. And this isn't a competing project or a competing product or something that replaces future flag vendors. This is similar to open telemetry. It just makes vendor lock-in a lot more difficult and gives users and customers and anyone that's interested in future flagging a lot more flexibility. And the good news is it works. I mean, we did manage to get a few adopters, a few big companies started using this, started talking to us. And this was really exciting because we created something from nothing. But the only reason this worked is to go through and look at it as if it were a real product. We took the time, got all the stakeholders involved, planned a roadmap, in a way, even dedicated resources. And I don't mean just ours. I mean, from other companies, agreeing on who will be maintaining which part of the project is essentially like building a team in any other development setting. So what can you do to make a difference? And this is just some of the questions I want to leave you with today. One thing we saw helps a lot is open sourcing for the right reasons. I mentioned before, yes, you can go and say, yeah, the community will take care of this, it's on GitHub, I put a license, this is fantastic. But that's not enough most of the time. You need to know what the goal is and it's never bad to aim large, aim high, aim for a fantastic goal. Like we want to change the future flagging industry. Why not? And the last one, a goal without a plan is just a wish. No, I didn't spill my coffee this morning. I would not be able to write that straight without my coffee. But make sure you plan and really treat it as a product. Yeah, so thank you. And if anyone has any questions, we still have 10 minutes. Yeah, go ahead. So a lot of it is really interpersonal relationships. It's about going to the people, reaching out and just testing if they're interested. Yeah, we did Slack, we did LinkedIn, we did basically, it's like being a cold caller. It's like, I mean, most of the time you know the people which makes it a little bit better. But sometimes we're reaching out kind of blind to companies and just, hey, we're thinking about starting this initiative who would be the right person to talk to within your organization. And that really helped. I mean, as I said, most of them were really excited to have someone outside the industry facilitating this. You guys have done a really good job of building the tallers for a circle team and trolling. I mean, I would have to say we're kind of lucky. There's a good understanding of what open source is within the company that definitely helped us. But we were also never promising exact dates. We tell them like, it will happen. We will push this in this timeframe. It will take between 10 seconds and 15 months to get approved. Is that an exciting thing to hear? No, but they also accept that if we, the easiest example is open telemetry. We can't not participate in it. So, I mean, they don't really have a choice from a business standpoint. We have to be involved in these projects. It's either you participate and you are a part of the community and you help develop it or you get left behind. And that's just the truth. They accept it. Life cycle of an open source project. I guess it's totally context-dependent, isn't it? I mean, on what kind of project now? But how do you, for example, in your project, you said, was that since three years, is that one of them? What do you think would be a life cycle? When it will come, when will it happen that you know people will start going out of the company and then, you know, it just becomes an open source project? I mean, the hope would be that that doesn't happen. I hope I have, like, changed job or retired by the time that happens. I mean, I hope. It does happen, like, for example, in our, like, we come to a community called open network automation platform, won't that happen? It started with a huge time fair five years ago. Now, there are a couple of companies. I mean, there is no predictable way to look at that. I mean, it's gonna happen sooner or later. The project's gonna die down. Technology's gonna change. We did have a project like that where it started as something internal. It was, let's say, an inner-source focused project. We had people from all parts of the organization collaborating and participating. And then we decided to open-source it. It stayed open-source for a while. Didn't get much participation. Like, hmm, okay. Nothing's happening. No one's interacting. The only people working on this, well, are us. And we're like, okay, from the next release, we'll just close it again. And, I mean, these choices are things you're gonna have to make kind of on a case-by-case basis. I mean, if you're part of the CNCF, you do have somewhat of a framework for this. And the good news is that it won't only depend on you or your own objectives and metrics because, I mean, you start out with Sandbox. If you have a certain level of adoption and contribution, you can go up and up all the way to graduation. But every year, there is a review. And I haven't seen it specifically happen yet for projects that get, let's say, shut down. But there are criteria that you should be trying to fulfill to prove that you're active. Like, if one year, the whole governance committee decides to leave and no one else wants to do this, they're probably gonna ask you to either try again to get a governance committee in place or they're gonna recommend maybe donating parts of the project and shutting down that one. So that's also why being in a foundation can help kind of remove the personal affection towards projects. Any other questions? So engagement towards the community is really tough. It can go, I mean, we've never actually offered any financial rewards when it comes to participants. A lot of it comes down to the fact that people want to have this as a contribution on their GitHub CV, let's call it like that. They want to participate in projects. So these are usually people coming, sorry, people that are individual contributors. When it's people coming from enterprises, most of the time it's because their company has an interest in the project. So in a way they are getting their own financial or monetary reward for this. It's something we've thought about in the past. But we haven't really, we've never really gone into this yet. We've done small things like a recognition video, like, hey we want to congratulate this contributor and we kind of interview them. Like why do you contribute? What do you think about the community? Or it can be small gifts like a t-shirt. But that proved to be more complicated than we wanted to, I mean, shipping is fun. Yeah. Yeah. Yeah, so I mean, we do work with OKRs. Most of the time they are not criteria for evaluation, let's put it like that. It's more, for example, in a growing project the goal is to usually double everything. Double engagement, double adopters, double, double, double. Double everywhere. Yeah. And that's, I mean, that's a metric we use to motivate ourselves and to get us moving forward and like measure what effects do the activities that we do have. I mean, we do use metrics coming from, I had a panel yesterday with Don Foster from the Chaos community and Daniel from Viterja and we did talk about these metrics. So there are plenty of things you can use out there but internally what we really use is the contribution to the different parts of our product. That's like internal metrics. Then our, let's call them vanity metrics are for us to measure our impact. But it's nothing that the more business side would have interest in like how many people are in the community, it can be interesting but that's not gonna determine whether they want to continue investing, invest more, invest less. They're gonna be interested in how we're contributing on a product, from a product standpoint or if it comes to, I don't know, something that's not product but is used for testing or used for anything for development then that's how they'll measure it, like reduce time or things like that. Yeah, any other questions? All right, I think we, was it at 20 at the end? I hope so. Or did I imagine it? Good, yes, got past technical difficulties. Thank you, thank everyone. Have a lovely summit and yeah, see you around. Thank you.