 My name is Alois a bit of my background. So usually it like to start my talks Why you should actually even listen to me so even though what I'm talking about so some background Regarding open source and myself I was running a lot of our community and standardization activities at Dynatris early on initially We started to do a lot in W3C more than the standards development and Influencing some development on the browser side then we started to engage more and more into open source Which then led to like creating the first dedicated open source team Which we then kept growing and as we kept growing it We established an entire business unit that at Dynatris is responsible for open source Bit more details on what we're doing there before but it's really was taking it from zero To a reasonable number of people who are fully dedicated to open source Today's talk is about beyond Ospo's The idea is really that by the definition and what I learned talking to a lot of people who ran Ospo's a lot of this Was triggered by the Linux Foundation member summit conversations I had last year in Lake Tahoe That we kind of like follow a bit of a different approach and we kind of took it to a next level and wanted to do more Than many Ospo's do today give you some background Why we're doing it how we structure it and how we actually made it work also doing this a bit under the Idea of like we have some additional economic pressure right now like how to justify the value of the work we're doing in open source How to a position it inside a company and also how do I do it in a company? Where whose main business is to sell commercial software that's not necessarily tied to open source So a bit about open source at Dynatrace or some background Dynatrace is an observability and security company so we built security and Observability products we have been doing this for a very long time our software that we sell to customers is SAS based and Most of that software is actually proprietary. So most of the software by itself is not open source And for a number of reasons one of them being that some of those components are only valuable to us inside Inside the company some of it continued technologies that would only be relevant to us or our competitors At the same time we're using a lot of open source and collaborating in the open source space for example around open telemetry and the whole ecosystem on Data ingestion automation integrating into the cloud native ecosystem and so forth So the interesting thing to to understand here really about how we're doing open source and and how I look at all of this we have a think for our company of our size a reasonably large investment in open source and None of these open source components are integrated into any components in Dynatrace that directly generate ever any revenue So it's not that we have this open core model on this software. We kind of try to do it once It's not really what we're necessarily good at but we believe and invest in open source where it makes sense and contribute to the business so Just bringing this up that you have some understanding of how to do this in a company that doesn't even want to make money out of The open source components that you're building at least not directly We have three major open source projects that we contribute to in in total as it's like roughly 200 But we talk about the ones we strategically contributing to two of them We have actually founded or co-founded and one of your contributing to one is the open feature project One is the captain project and the third one is open telemetry all of those projects We joined very early on captain viewer founding member open feature We initiated and founded it and open telemetry. We collaborated on a lot of the work. It was done there also the Related work that's happening within the W3C around trace context, which was also founded by us But it will see about all of these projects that they very much Have a certain standardization touch to them open feature standardizing How to write feature flagging code in your application how to define feature flags how to manage them The captain project how to get the observability and Automation in a standardized way into kubernetes and open telemetry how to capture standardized telemetry data So a lot what we do is create standards across the industry On core areas where we see them fit and honestly where we want to have standardization So it's easier for us to interact in these markets Overall the team at dinatrace on the open source side is roughly 50 people it keeps steadily growing as we grow on on projects and Starting from 0 to 50. I think is a good Trajectory that we have been on we keep Usually growing at a reasonable size every year depending on project contributions and the areas that we contribute to when we talk about Contributions, this is not just about code contributions So we also take care of community management. We take care of documentation for some of those projects Support them also on the governance side and in the technical community side So this is not just code only we help where the project needs help And support those projects there So when we looked into us both and like the whole idea of creating an open source program office We saw some challenges. I think there's goods and bats and this is obviously my very personal view And then why why did you decided to go for for a different approach? So I suppose very often our advisors only and the only here is obviously under exclamation mark It's very important. What else was they're doing and how they help in the company, but they're not actively Contributing and creating the open source components and they're not contributing to Creating artifacts that are directly related to the business in the sense. Yes Drive open source compliance in the administration. That's great. That's important We got a lot of questions about this We have to take care of this one when we started the whole activities and my colleague David here can tell you a lot About how to get a couple of hundred projects compliant to most open source policies We help this help people to do it and support them We review and advise internal projects so not all projects need to come directly from our team There's always people who want to start a project We actually help them to do this and then also act In a way that we can like fit this into a business model help develop them and then either decide whether they want to move forward or not move forward Scouting for interesting projects is what I heard some are supposed to like rather developing something internally looking at other Projects that are out there. Sometimes we also get asked by colleagues like which project We should pick which others we should not invest how to look at a project Whether it tells you or not or where to look for alternatives and how we can ensure the sustainability of a project so if you have a core project that we don't want to like run and Like really be like in the driving seat We still want to ensure its sustainability in case we build it deeper into the product obviously So that was the plus sides the minus sides with this traditional Oscar models You're not really driving the actual open source works You're not doing the coding the community work. All of this is usually left to other teams that are outside of the Oscar You're not directly aligned to business goals and the notice might be better for discussion when I talk about business goals Yes, you aligned maybe to a business vision and maybe to some of your business priorities But do you share goals with the commercial product teams or not in our case? It was very important to share the same goals that we are measuring We can't be measured by the means of the business and can show active business contributions and also agree with the respective business owners on this and Last but not least not really being responsible for business outcomes. I know this might sound a bit scary you in the open source world You have to influence the community work with them on consensus and still you should be responsible for business outcomes for me coming from a From a background where I was leading my own business unit This was like obvious if I take responsibility Some about something I have to be responsible for the outcomes like how can I not be responsible for the outcomes if I'm doing this Like why are you even? I would even go to my boss and I say why even paying me if you don't even care what the outcome of my work is I mean, it's it's a nice idea, but at some point it wouldn't be that obvious So if it's if you're more the consulting side you're missing out on these actual topics and we didn't like this That's why we decided to go for a different structure that I walk you through Just to take it away our core engineering teams are part of our open source business unit open source is a product at dynatris It happens like every other business unit So how do we do this starting very from the top conceptually Obviously every every now and then we want to start a contribute to an open source project actually both are relevant Step one is strategically modeling the project not having developers. Hey, we built this tool It's actually great It helps solve a lot of problems or sometimes we also in the situation where we are acquiring companies like every bigger company does They have some open source projects going on We have to take the strategic decision Do we want to continue those projects? How do they fit into our overall business plan and so forth and also if you say Well, we want to invest more development resources Development talent and support the project also understanding how the project work So for us, it's really key to understand how a project works the same way a business works The way we do it is using the open source canvas. This is more or less a business model canvas Adaptation specifically for open source project. So it's not only focused on business. It's focused on the core project The audience community and also business value. Why did we create this? It just helps us whenever we engage with the project to ensure that all the important questions are answered There's a link down there where you can download is obviously the open source business the open source can versus open source So if we to download and modify it So one of the most important questions, why do you think actually open source? This is something we keep asking people again because we want to have community engagement Now why is it open source? How does it help us to run something open source versus running it proprietary internally at the company because from our experience running Something open source is somewhere in the range of 30 to 50 percent more expensive than building it entirely in-house And you're also significantly slower if you have to develop something in a purely consensus space Instead of one product manager telling a team what to develop Yes, once it gains momentum once you reach your goals You're going to be faster, but especially in the beginning where you're looking for traction where you're looking for fast progress Honestly building a lot internally might be a much quicker way to do it Especially the way we'd like to do it We don't want to where we have been more successful is not creating a project first and open sourcing it and then getting By and our fastest growing projects are actually those where we got Consensus across other parties. We wanted to collaborate with before we wrote the first line of code Part of this was also was the understanding. Okay, why would the community care and What type of interactions are we getting with the community and who is actually our community like who are the people obviously? Who use the project, but who will be future maintainers who do we envision to be a maintainer of this project? And and why would they be maintaining it and why would their companies? Found them to maintain it. I think everybody in here knows like there's this idea that somebody just doing this for Altruistic purposes, that's not really true That's not how open source is built and the really big projects are built by companies who have a commercial interest in these projects being successful So then going all down to the community side. What do we have to do there? On the top left a very important question that as we have recently seen some companies haven't answered properly And change the licensing models How does the success of my open source project and people using my free open source project help my business be successful So how is the success and the wide usage of my open source process? Having a positive effect on my business and not becoming a threat of people rather go for the open source version and not my commercial Commercial offering or the commercial offering of somebody else Which as we all know in some cases then leads to license changes that restrict you from certain usage Making your users and a lot of people unhappy and we answer this question right from the beginning Very often we get the pushback. Yeah, we figured it out once we were successful. Is this kind of like too late? Yeah, it's like getting a pre-nep when you always want to divorce somebody that's way too late to have this discussion Yeah, it's the discussion should be happening much earlier now that giving any like relationship advice here But I think you get the idea like figure it out before you're successful how it's happening there because otherwise You're not going to be happy there and for us. This is a key question and then we also define the investments up front Very often when you have discusses. Yes, I do this on the side You don't do anything on the side that you want to be successful We need to have a dedicated set of people you need to get your resources like simple things And talk to developers. Yes, let's hand swag to all of our maintainers that you have zero marketing budget If you want to have marketing budget, we have to get you this marketing budget So that's how we structure and work with these projects and give it to them also as a checklist What the outcome of this is that sometimes even the developers is no, this is not really want to want to do this sounds to businessy or can't answer all of those questions and Sometimes it then provides also the input that we use them and obviously presenting it to Our CEO CTO to take that investment and to fit it into a broader business context It usually helps us to be way more prepared and it's a fair way of judgment And also for people learning along the way Step two then really is about corporate alignment Okay, now we have we understand we actually have a strategy beyond writing cool code or want to like build something That makes the world a better place Having an idea now we really need to align it and what we do we really drive this alignment sessions top down So very short primer how we do it like most companies do it. We have like very high level goals That directly come like from the CEO top down. Is there a mission critical goals? They're moved into what we call like needle movers The first below I was mission critical goals Long story short. We build nothing open source. That's not aligned to any goal in the company Because we simply can't Sometimes we do it a bit more forward-looking, but that's a different discussion Then we define how towards this mission critical goals. What are the most important activities that we need to take? That's what we call needle movers. I know every company has different words for it And then we will see how open source can help there then we define how but how this Open source initiatives actually have business impact against hard goals. This is not community growth This is not contributions. Nobody actually cares in the in your board How many contributions how many stars you get how many maintainers you have how many conferences you've spoken at? That's the hard tools to care how you contribute to the bottom line of your business and that's fair And then obviously we define the funding and funding obviously goes in line with business impact So we plan the same way we plan everything else on the product side We were actually part of the same planning cycle as every other part of the product We have to provide the same materials We have the same business reviews as everybody else in the company So we tweet open source exactly the same way this for us was quite a journey to get there But when I took it over that was my primary goal to come from okay, we give you some money to do some open source So now I want to be Liable to the business. I want to be aligned to the business. I want to everybody look at what we're doing here Constantly all the way up to our CEO So this is a bit abstract Let's give you two examples how this works in the real world and I'll come into like how do we execute the strategy? And this is actually not great secret This are actually dynamic ways examples that you see in here But if you would spend a little bit of thinking you would come to the same Giving you two examples one is open to let me free What's our business called increase market share and observability da and observability company that wants to get market Share and observability quite obvious. So Now, you know one of the strategic goals of dynamic ways you might have known before So how do we do this? We get more observability data from our customers So we increase our market share by getting more customers and getting more data from our customers right pretty obvious What is hot? What is kind of keeping us back from this the quality of Open to limit free data. So very often a lot of these libraries were written Data was not properly tagged Which means we couldn't use it in our product customers did not see the data the data wasn't the wrong format Some of our Analytics and the i keep capabilities were not working properly on the data. So it had no value for these customers So that's why they weren't sending us more data because why should if it's not working properly, right? One approach would obviously be tell the customer that the data is wrong But that doesn't help you a lot either generally custom. Hey, you sent me something. I don't know what to do with it Even if it's somebody else's fault, it doesn't help you business, right? So how did we resolve this? We decided that one of our strategic needle mover goals was we want to ensure the quality of observability data Across all the major technology stacks. We see out there that what we get has the quality that we want How did we do this we decided while we're getting part of the open telemetry Initiative around semantic conventions actively contributing to semantic conventions taking some work BF internally a dinotrace Contributing it working with the teams there thrown it off. This is aligned And just I was the specifications by themselves do not really help a lot We also support the implementation So we ensure that they make it into the sdk is the libraries can't rip repositories and so forth as quickly as possible Even going further helping for a third party projects that we see widely used by our customers Building additional components. That's for example, how the captain project came along what it basically does It adds on top of kubernetes the ability to do Observability and tracing for your kubernetes deployments across individual deployments for like entire applications And then attach actions to it And it just doesn't matter have a presentation, which is actually right That the switch that you see here the lower part is the business goals the upper part are the open source goals So how do we measure success now? We track our interest volume Do we get more open source data? That was our goal in the beginning Do we get more data that we can work with assuming that we roll it out to a wide Amount of frameworks that are important to our customers Improving those frameworks our interest volume should go up And I will see the percentage of proper open telemetry data Now we will notice now like why is this here on the right and not divided by open source and commercial because it's actually the same goal A goal over here to get more observability data is tracked by the percentage of proper data and the overall interest volume The success of four open initial source initiatives can be measured by the success The amount of proper open telemetry data we get as contributing to those libraries Plus the overall interest volume as customers are sending us more of the data So the goal of open source is exactly the same as of the business And as mentioned before what I can see here. There's no contributions. There is no stars. There is No anything else at that level That we care about But everybody understands why we're doing it and everybody can assign a Number value to those interest values, which we are measuring and we can design the priorities how much we want to invest there giving you another example on open feature except the same modeling framework and Yeah, obviously feel free to copy it for your your own way So what do we what's one of our goals? We want to support more developer use case So we want to use support developers use observability also office for an observability company So we need to best but understand progressive delivery. There's actually a typo in here Which we progressively need to change later on So we want to understand when people roll out new functionalities when they turn on feature flags and so forth That's a key goal. We we no longer have like one single releasing production Those all of us know we have multiple versions in a blue canary deployment We even have like this complexity of different features being turned on by different users And we need to understand this data properly and easily What was holding us back too many implementations? So there's like roughly maybe 40 feature flagging providers out there with libraries across amongst 10 Languages that sums up to like roughly 400 libraries that you need to support that all of kind of do the same thing But slightly different So it's a total mess And then you realize that all of these libraries kind of like do the same thing but not exactly the same way So again, what was the goal on the open source side? Let's try for a common standard of those libraries most of those libraries back then already were open source But were developed by individual companies Not collaborating so That's why we started out and initiated the open feature project The goal of the open feature project was to create a standard for feature flagging across languages with standard SDKs And a provider architecture where you can plug it pretty much any back end that you want Right now we are moving even like having a flag definition and rule evaluations built across vendors So what we then did again, we didn't start the project We didn't even start writing the code we talked to everybody in the industry who built something like this And heard all the hard conversations in the beginning Like imagine going to a market leader like launch dark liens And well, we want people no longer to use your SDKs, but an SDK that's built consensus by 15 or 20 vendors out there So we more or less built a business validation act that we gave to people who we wanted to participate that they could take to their cto So that they could make an argument why to do it that was most of my work in setting up this project It was not cheering up people. It was not about setting up Guitar projects. It was not setting up about calendars. It was not finding an amazing logo It was really about helping those people justified internally When once we got beyond critical miles, we started to actually work on it And ended up in this case with the project was moving really fast So we had our 1.0 release of the SDKs six months after We initially started the project We had alignment that was good enough in the project Also, it was seen submitted to the cncf to be under foundation coverage And for some reason like the cncf processes were a bit slow We were not even under foundation management where the whole team across companies was already writing code And that's how we could keep up with that speed right now We have covered already all major languages And today have also con so end user companies like Spotify in our case an ad user company contributing dedicated SDKs Google contributing all the major vendors starting to contribute and the community like really actively driving this But the main work was really getting the community on board. So this is not a code goal The code goal they go on the very beginning was getting 15 people on board to agree working on a common implementation Yeah, and obviously we actively support the implementation. So some of the SDKs have been written by us Usually where we see where we have to support more I honestly it's much easier to find people contributing code than those running your community than taking all the Job board and carry water work, which we often contribute But supporting this and driving a lot of the implementation work forward And again, how do we measure this same story here? Track usage amongst our customers. So that's what we want on the commercial side Plus what we want on the open source side so the more people we see using open feature and obviously tracking Usage of your open source project in the wide world of all the software companies out there is a very hard problem to solve Tracking it amongst the customers or dictate the people who you care about a or customers and and your prospect is much easier Especially if you know observability company like we know which libraries are loaded and how much of them do we see The second one was obviously track supporting companies. So when it's also obvious when we interact with a customer who is Over the using a feature flagging solution Can they use the SDKs and are they using the SDKs and are they provided by these feature flagging companies? Again, what you see here the goals for the open source side and the goals for the commercial side are exactly the same So we report on the same number that the commercial arm is interested in and we're even aligned and driving them Time origins might be a bit different like when we start working obviously on adoption It takes a couple more quarters or a year or so until we see it in customer Always customers showing up. I think that's quite that's quite natural there, but the overall goals are the same Like using this modeling approach like really helped us justify why we're doing it and I mean to be honest It looks very simple if you put it on the slide and like totally obvious Usually when you start off it takes some time thinking But that's also why I wanted to provide this framework It's like really how you break down goals which barriers to your hit how does open source help you to overcome this and find Like a joint measurement and again what you see here no contributions. No stars nothing These are things we track internally obviously But at the CFO level nobody cares If you still believe that the CFO cares about your Github stars No So how do we run this department? I don't think there's also some are different I mentioned it in the beginning in order to do this We need to drive implementations independent of product. There's a bit of an eye chart, but this is more or less The chart of the department we have as I mentioned, this is an entire business unit We structured it like any other business unit. This is actually important for two reasons Reason number one is you have everything in there that you need to run the business, which is super helpful Reason number two, which I think is even more important Is that other business units understand how to interact with you? They need who to talk to people have the same names We have somebody who is a go-to-market product manager We have somebody who is responsible for growth like all the other solutions So if somebody else needs something from us on a growth perspective, they know who to talk to you So this most likely is not going to be exactly what you would need Depending on how your business work the key takeaway should be model yourself in a way that the rest of the organization understands how to interact with you We do actually the same like we have we're using g-ring only for products We have a structure on how we break down All of our depth work in a variation of Scaled edge how we do the same you might say but open source projects don't work that way. No, they don't But our success is that for them we mimic The behavior of the rest of the product organizations and fit ourselves in there Like we take open source roadmap items we fit them in you would find Things like on the open telemetry roadmap that are actually part of what we call like a value increment In our commercial product roadmap So that people can like work with it and align with it This by the way also like allows us to very directly track the impact on product deliverables So if it's to take a certain feature or we call it like a value pack something we ship to the customer I could directly See how much of this was actually related to open source If your question is now, how do you handle something like contributing to community meetings being on a tc being on a governance board remodel it as maintenance Just as you would do with software for software you have new for product development You have maintaining what you have out there and keeping the project running. That's where we would put it in there Yes, we have the highest maintenance rates compared to other product units, but that's just realistically how it works And it's obviously well, if we don't do this we kind of lose that this will use the influence and like these Part of the product will be impacted So obviously there is like open source as a department with the department head And then we have open source product managers. Yes, we have for all of those products Independent product managers on our side There is a counterpart also on the product side. They have a slightly different scope So there won't be an open telemetry product manager on the product side There will be one for as we call the application observability that we interact with but they are more interacting with each other And we do this for every project the difference between the two one is fully focused on product delivery One is focused on upstream and upstream integrations I'm a big fan of having people when they wake up in the morning think of one thing they need to care about today Single threaded leadership You will never get this if you do product and open source at the same time Your planning horizons will also be different. We do the same for engineering. Yes, the engineering teams as for every business You need to report directly to open source All upstream contributions and upstream integrations are built by the dedicated engineering teams That are part of open source, so they're not part of product And I will come to why we do this. This is usually a reason for discussion why and they're part of the product teams It's an anecdote to share We still have open source enablement that's helping other people to start open source project Actually, that has become less and less of where we put the effort some of the work integrated into overall processes at Dynatrace and other departments and As we have set up the basics that is working better And then we have a go-to-market organization that consists of community growth architecture and development So architecture development actually does two things it helps us to integrate with other open source projects So we have people take care like how do we integrate Our open source projects with our open source project in the community at an architecture level How do we integrate it with the entire product stack? How do we integrate them into like an overall customer solution? How can we help like our internal support systems work with this? So we not just do the upstream contributions, but we also help the organizations to actually consume and work with those projects And obviously then we have the death rel team in our case death rel People are not called death rels well They are called to the outside world But internally they act as go-to-market Product managers and they also follow the guidance of go-to-market product managers because that's kind of technically what they do You could argue they do more than this and it would differently Yes, but again the rest of the organization needs to understand how you work And if somebody says hey, how can we talk about this open telemetry feature or how about this open feature thing? That we want to talk to you know exactly who to go to Again, this is how we do it You might might look different for your organization But the the key message should be engineering is a core part of it You have dedicated product management and you may make the structure of the rest of the organization So nobody has to learn how to interact with you That's the question we often get Like why is it not part of the product teams? Like why is open telemetry not part of your open of your observability product team? Why is open vision not part of like some of our automation capabilities? Why isn't this part of like the regular product teams? And there's actually a number of good reasons why this isn't the case First of all this focus Again, single-threaded leadership The first thing that happens if you take engineers that work on open source and product Put them under the same product management that the open source engineers Will stop working on open source and help out on the product very super critical That that that's like clockwork that's going to happen What we actually had we actually had this like very very in the beginning And it's actually a really interesting story We had we had took some of the people working on open source back to the core product teams And the other thing happened they started to work on core product more than an open source Then those people wanted to work on open source again So what did they do they then applied for role again in the open source business You need to work on open source So the key learning there was if you want to like twisted that way The system self reorganizes in a way it actually works Better why did they want to do it because also they're like daily routines were on this Different the way they're interacting with others and even more A lot of the commercial people who then had to do something on the open source that they didn't want to do this Like why do I have to argue with somebody I'd rather take a ticket from my backlog work on it Rather than arguing with 15 people on the internet about this and know what I'm doing I can do it and I don't care about the opinion of 15 other people Which is totally fair Which leads like to different skills working in open source and working in a commercial one is totally different The processes are totally different actually as a developer in open source That's also why we brought in the pms If you work with enhancement proposals if you work with interactions If you have to take a lot of calls to convince people you might argue that also happens on the product side But at some point you realize as a product manager Your power to influence the product depends a lot on your contributions And a lot on like how you can get other people on board and convince them Not when it's easy not when you're just adding something but when people have different opinions You need different problem resolution skills in an organization Like what do you do worst case if we two are at the same level and we totally disagree We go to our manager and let them resolve the issue If we were to work for different companies Totally different situation so the skills it is different the people who want to do it is different And also for us as we run most of our engineering out of Europe So we make a mix of like Europe and then East Coast US because we can cover both Work with European colleagues and West Coast US easily You have to convince them to stay later You have to have people who want to come to work later but then stay later Because unfortunately people on the West Coast get up much later than they do in Central Europe Believe it or not Different horizons so what we also do like sometimes we have to invest in something That might not get relevant for the problem in the current fiscal year Or that's not part of the current business results We still have to do it because of strategic importance A product manager on the product side would never prioritize this Because it's not his job and it's not what he should do A product manager in the open source leadership we need to take bets into the future And we have the freedom to do so So right now it's almost like a mix of something 50% direct product contributions That help immediately and 50% strategic bets that we're taking Because we think that's where we're moving That's also why 50% of the work is actually funded by the product teams directly And the rest comes from open source where we have this freedom And obviously this varies over time Like if there's a big new development in one of the open source projects And we have to work way more upstream to get this table There's less of the big bets that you're working on There's always worries, but usually the horizon is different As a product manager you have to deliver always with the next release On the open source side you might in many cases get something ready for the next fiscal year To then be part of your product portfolio And that's your only horizon you're focusing on And again, think let's write a leadership what you think about in the morning You can't think about two things at the same time Yeah, and I mentioned like the mindset on how you do, how do you want to work Get a task to the best way possible being done Or discussing with other people, not doing it the best way But the way everybody agrees on, deferring something you consider important Doing it six months later when people also understand why you wanted to go there Maybe bringing somebody else on board, having the tough discussions Like rather getting it done, that's what we saw Can you get us this into open source, please? I proposed it to like 15 people shouting at me right now And like this red is so long, I don't want to do it I'm happy to implement it like once everything moves forward Even this is sometimes what the open source team does We have experts from the product coming helping with the implementation But we help them to get this into the whole open source flow To wrapping up here, adjustment that we needed to make along the way Actually we renamed the team in the beginning it was called open source What led to that everything that's on GitHub was suddenly our responsibility Even if we never created it and were never responsible for it Because we're the open source team, hey it's a GitHub, it's our job It's actually not That's why we renamed it to upstream contributions and integrations We're responsible for upstream work and integrating it into the product That's also how we relate to the product For example, if there's new capabilities in open telemetry That need product integration we'll support this part It's not that everything we do is open source, but it's always open source related In this case, sometimes the skill set in the open source team is higher To build some of those integrations that stand from the core product teams Or as I mentioned, follow your standard product development process Don't try to be the unicorn in development that never works for big organizations If you have, I think more than 500 and as many organizations here A couple of thousand of developers, don't try to be special That's not helping you here The more you can align with what works in the organization the better it does For us it did like really mimicking the behavior People know how to work with you, processes flow smoothly And you know how to integrate Drive towards full business accountability Try to be responsible I know it sounds scary, like not everything is under your control Sometimes things are late, sometimes things do not get built Yes, that's how business happens anyways You never know exactly what's happening in the market But at least have an opinion on how you want to contribute to the business And communicate it openly And have an agreement that what you're doing is important to the right people Yes, it might be scary Going that far, but I think it's really what's changing a lot of things Last thing, independence versus product-driven Briefly mentioned this as well, we try to do some things independently From product schedules because we consider them important We think these are key new initiatives And at the same time have to do something that the core product teams Need to do on the open source and we kind of need to balance in between And that's actually the management responsibility here Like they have this constant balancing act Like how far do you lean, where do you help, where is it priorities When do you actually say no to product because you think there's something On the horizon that the team is working on It's going to be so important in six months from now That it has bigger impact on what the product team might need from you right now Again, a lot of conversations and that's also what you're doing So that's basically it That's just giving you an idea of how we do open source A slightly different from traditional osprey approaches Sharing some examples of how we do it Obviously open for questions, discussions Disagreements, disagreements, disagreements are sometimes interesting Opening up the stage to you Of course it's faster than open source That left me thinking And I was like, well, if you don't document your code If you take shortcuts, it's just easier to do it We hang closed doors than they open Are you thinking of some other examples? It is faster in the beginning But actually if you're building the same thing And it's very important if you build the same thing And you build it in consensus with ten other companies You are significantly slower getting consensus, agreement And everything done on this piece of code Than doing it first, it's not just about shortcuts and not documenting But if you have one product in your manager And one architect deciding what to do You're faster than doing it with a lot of others That's my point, consensus takes longer In the long run if this is your goal it's totally fine But sometimes we, and I can give you an example Sometimes we prototype things internally Which we later on use in the open source project And get it to production quality It is significantly faster Because we're not asking other people for opinions We don't go for agreements We do not have to take considerations What it means for other people's product integrations We built what's best for us And not what's best for ten people And sometimes people have interested their companies And have to cater to That you wouldn't even be concerned But if it was just an implementation for you To give very one concrete example We worked with one big cloud providers And we wanted to change one character In a specification for a trace context Like why are we discussing about one character For five hours now It was a long day in Seattle We were discussing it for five hours Said yes because we have implemented this Across all of our cloud service And changing this one character For a high two digit million dollar in R&D cost So this is one example of other product integration Which has different opinions on topics At some point you don't need to care Like if you want to be really fast and graph the result Yes, long term sustainability And industry adoption is a different one And certain things you don't need to do Like managing community meetings Getting everything on board Seeing that everybody has time Maybe running a second meeting Because somebody couldn't join You have to do another one Then running it with one internal development team Code reviews You want at least three organizations To approve your PR Versus just two of your colleagues To approve the PR What's faster? And I'm not saying that open source is a bad idea You just need to know what you're getting yourself into Because I've seen people being frustrated Building by consensus takes time and effort It is important for sustainability But to your point Yes, that's how we came there Open source projects And they do so many beautiful things And their business model is supposed to be based on that And you seem to have answered this question You seem to be saying that's not necessarily a good idea To base your business model on an open source project Excuse me, I'd like to add that It seems based on what you were saying You guys tried that but it didn't work It didn't work for us in that specific way And we also are a type of company What I believe in, you can't build a business model Based on some open source work That is a component of it But what you shouldn't do You just shouldn't provide a SaaS service Because every cloud provider Eventually can do it better than you And you just shouldn't do it By providing some support capabilities Or some enterprise capabilities Because others will enter your market What I think does work You build your open source project To solve one problem That gets your end users into a situation Where they then need your commercial product Which always should have at least a different use case And ideally also a different target audience Looking at open feature What open feature actually solves Is defining and evaluating feature flags Building an open feature cloud service Would be for anybody who would like to be In that every ridiculous effort Because you're never going to make money out of it Red Hat's going to do it AWS is going to do it Google is going to do it Pick and choose whoever you want GitLab, pick whoever you want to do that there But if your goal is you want the standardization Of feature flagging Because you wanted to build the best Maybe AI based as we build everything AI based right now Progressive delivery solution Then you have a different business model You have a different use case And your differentiation is not The one that you are part of The open source projects So that way you can build something On top of it But assuming that everybody is using Your open source project Which situation are there in Where your commercial product Is adding additional value to it Complementary Kind of complimentary like extending Beyond that initial use case Or it's different I mean it's radically different You could say or not It's just the next step It's just the next step that users Might run into Or you might Then for example this allocated feature flag Is available but you have the best analytics Like a lot of problems in feature flagging Are fine stale flags Fine flags that are properly used Which ones and which combinations Relate to certain problems Doing things like this But it's not the exact use case It's usually an on top use case That you need to build on I think that's a much better idea Than just being there because I mean we've seen it with companies Who try to just provide the service On top of how well this actually goes And what happens when you Change your business model How well does this go Not really but if a use case Is different that's why We have this question Everybody is using So as a project for free For this project They don't want to buy anything commercial How is this helping your business And that's the question If I was a VC I would ask somebody Getting funding And if they can't answer it I would send them back to do their homework Because there is always a business case Examples Examples as I mentioned Like the open feature one Obviously people like Building the progressive delivery For open telemetry It's more the analytics capabilities on top Like storing the massive amounts of data Doing the analytics So you always have to think it through For the individual project Just stay away from making it Just enterprise features as well Like as part of the CNCF tech Remember one project coming to us They built the open source solution Where it can cross cloud provision Your infrastructure You use a template You can start like a whole AWS environment A bit of a matter of what size But how do you do a different open source And commercial Authentication is actually part of the commercial offering Because we know that people will use it And they ask them Do you think anybody in the market will use An automation solution That could in one minute Spend one million dollars without authentication But cost optimization in this use case Like which resources you should switch to Understanding patterns When things are working not working Building like schedule deployments Like taking things offline Online depending on workloads Would offer an entirely different approach On how to work with these environments Just to take one I think it's always a very use case specific But it's an important question to ask And have an answer for Thanks, thank you Yeah, so if you don't want to ask questions In the background Feel free to also come over here Or find me through the conference Or otherwise it would also be easy to find Thank you