 Hello, everyone. Welcome. So this is a panel, one of the many panels you have been through with the past three days. I apologize for the delay. I said one of many, but it will be the best. So we're here to talk about corporate strategies for investing in open source sustainably and what that means. It's a really interesting question because obviously investing in open source is very, very easy to do if you have a really nice like process when you're coming but actually making sure that the investments you do make sense for the community and make sense in the long term is really difficult. And so we have a few panels here to talk about what it means for their companies. Just so you have some context, I'm Richard Littauer. I work for open source collective. Open source collective is a fiscal host that manages the money for 3,500 different open source projects. We're kind of the equivalent of GitHub sponsors, except GitHub sponsors is mainly for individuals. Open source collective is for collectors. I also run the Sustained podcast. There's a sustained community dedicated to understanding these questions. Alyssa is also a co-host on that podcast. So that's my perspective. And then we have Alyssa Wright. Alyssa, do you want to talk about what you do at Bloomberg and how you got there? 30 seconds to one minute. Sure. Thank you. Hi, everyone. Really pleasure to see everyone. I am Alyssa Wright. I currently help lead the Ospo team at Bloomberg Finance. My journey there, where to start, right? But the journey started with a deep interest in kind of like how we as humans like sort of relate to our digital and media environments that led to kind of a growing interest in open source. Specifically, I was very much involved in open source geospatial technologies and have worked closely in the OpenStreetMap software projects and startups that have grown from there. About a year and a half ago, I joined the Bloomberg's Ospo team with Kevin Fleming, if you've ever crossed paths with him, a good deal of Bloomberg's technology work is built on top of hundreds of open source projects. And so it is a priority of the space to have clear, repeatable, scalable processes, policies, support systems to both sustain open source within the company and to sustain like the open source projects that we're reaching and improving and relying upon and beyond. Thank you so much, Alyssa. So Bloomberg's a Fortune 500 company. Stripe is a bit of a newer player in the field. So are you, Mike? So we can talk about how you got there and what you do. Yeah, absolutely. Hi, everyone. I'm Mike Fix. I am a software engineer at Stripe, the thing that company most known for our internet payments products. So yeah, my foray into open source was first as a maintainer near the end of college. I found this wacky world. I got super excited about it and really jumped in as a maintainer creating an open source application called Carbon. It's a little app to create and share screenshots of your code on Twitter and your blog posts and your presentations, etc. And that grew enough where I got to really collaborate with the community and really found the joys of open source there and gave me like some deep, I think, empathy for the space. So then after a few years doing that, I joined Stripe as an engineer and within a couple months of joining the company, ended up in the open source working group and then taking it over a month after that. So I'm leading that working group for the last couple of years. And for the last nine-ish months, I've been doing open source full time as the head of their Osmo, head of open source, prioritizing open source strategy, trying to figure out the highest value ways we can use and contribute to open source to help the community and help our company. Thanks for having me. Thank you, Mike. And now we have Suzanne from VMware, which is the more traditional tech company at this space. Yes, thank you. Welcome everyone. Thanks for coming after lunch and still being awake after lunch. So we're going to do our best to keep you awake. Suzanne Ambele from VMware. I've been at VMware for 12 buster minus years now. So I'm kind of a long-term long hauler at VMware. I got involved in VMware's Osmo about six years ago when our Osmo was first conceived. VMware has done open source for many, many years. But six years ago, they decided to form a more strategic body called our Osmo to help us do more open source more consistently, more sustainably, scale. And the company has grown so fast that having an Osmo really helps people move more quickly in open source because they know where the edges are. I think we were talking about lunch and one of my fellow panelists there says, oh, that's like the bumpers in bowling, right? You've got the bumpers on the side so you know when how to stay on the straight now. So I work alongside our Osmo and I also sit in VMware's brand and advertising team. So I split my roles. It's a very interesting world for me. A lot of context switching. Thank you. Thank you. So, Mike, you're really one of the first people who was interested in having this panel, largely because we were having a conversation about how you fund your open source ecosystem. So we're talking about sustainable methods of investing and you don't just fund your dependencies, you don't just fund people who use Stripe, but you have a different strategy. Can you talk a bit about that? Yeah, absolutely. So coming from being a maintainer myself, I was always interested in how you get paid doing the job, doing the thing you love, and eventually establishing open source maintainer as a viable career path. And I'm really passionate about that in general. And so when I joined Stripe, I was really interested in figuring out how we could contribute to that. In general, so I wanted to start an open source sponsorship program to pay whichever open source maintainers we could. But that led on the path of figuring out how we could do it the most sustainably. And what that meant was focusing on ROI, so return on investment for the company, figuring out how we could measure and determine that we're actually getting measurable returns for our company in response to our sponsor program. So what ended up happening was we took a user's first approach, and we ended up sponsoring projects that our users use to integrate with Stripe. So by taking that approach, we can measure, we can measure the money that we get back from those companies using our software, because we're a SaaS business. And because we can measure that, we can really sustainably invest in that open source ecosystem. So instead of just contributing on a quarterly basis or a one time grant, that sort of thing, so long as those projects are continuing to make us money, we're continuing to sponsor those maintainers. And just like you've seen in other business models, if you have recurring revenue, you can make different decisions as a maintainer. So these open source maintainers can basically rely on $3,000 coming in every month. And that's not a full time job by any means. But we've seen so far that it does make a difference. And that that dollar amount was intentionally chosen. So it did meet that threshold where they could rely on it, make different decisions in their life. And so far, we've become like the number one client for folks that are like freelancers of their business. Or it's been like a number one income training for people to have small businesses while maintaining these open source projects. Thanks. So you mentioned a FOSS fund. So Alyssa, you previously worked on another FOSS fund with JHU. You also helped with managing the digital infrastructure group, which is interested as a group of researchers trying to figure out what digital infrastructure means and how we sustainably understand how we fund the world using open source. What I'm curious about is, have you had the same experiences as Mike of having a FOSS fund and realizing it's not enough? And how does that influence your policy at Bloomberg in sustainably giving back? Well, first, I think we need to do a audience call out to the original author of the FOSS fund sitting in the back. Many thanks to Indeed and Duane O'Brien and all the work that came together to put together this kind of like kind of an industry framework for a FOSS contributor fund. And I think, you know, generally in my sort of kind of reading of what that means is that, you know, how does a company organize a sort of inclusive, repeatable voting mechanism to raise certain open source projects, you know, raise as in like vote for certain open source projects. And those, quote, winning projects would be awarded a certain amount of money that was that the company is like, you know, set aside to allocate to such rewards. And it requires a lot of, to implement, it requires a lot of administrative pieces to come together as well as like cultural and distribution and language, you know, requirements. But I think one of the most positive things is that there's a collective conversation that happens like within any organization at many different levels, everything from like, what is a technologist to what a tooling that we use to collect those votes to how do we make it repeatable to how does procurement like, you know, feel about all this, you have to like kind of shift the conversation in order to be able to support open source projects that maybe are not at the kind of at the, the same sort of sponsorship tier intake process that we might be useful, used to with larger, with larger open source projects, because there are as many, so many different scales of open source projects. There's a long explanation, but I really encourage everybody to learn more about the FOSC Contributor Fund in part because I think within the industry it's kind of changing some of the ways, some of the tools that we have that on hand in order to make a difference and to make a difference to many different types of open source projects. So all that said, what was the question? How is working with FOSC Contributor Funds influence your perspective on how you hold those conversations well within the company? Well, I think for me, so we have the go ahead at Bloomberg to move forward with the FOSC Contributor Fund. We, it's been a year, go ahead to move forward with the FOSC Contributor Fund, and we've spent a lot of that year kind of bridging language between how we traditionally like evaluate a software vendor and the state related statement of work. And so this has really been a, like a interesting exercise in translation. And in order to like have like the signatures in place so that we can, you know, make something just make something come to be, because we know that it's possible like within the context of Bloomberg, because it is impossible within the context of any organization that's using open source, open source software, and they want to support open source software like again in a sustainable, repeatable way. I think I also want to emphasize that what we haven't touched upon yet is the really interesting aspects for creating community like internal the technology, momentum and engagement and dialogue. They're, you know, we kind of all get silent in our own work, but being able to talk across teams about what are the projects that are most useful for your work, I think opens up like really interesting, exciting and, you know, related to retention conversations when you need to talk about open source across as many bridges. But it is not the only one. And I don't think anybody here who's doing like a foster contributor fund would say that that's the end of the story. But I think it is a sometimes a culmination of like, you know, one story. And I think can help us continue to redefine the needs around cultural and language, like ways of being so that we can collaborate better. But I think that there are many other things, including better documentation and support and more nuanced like mentorship that are corporate strategies that I think that we are all pursuing that need to kind of move, need to move maybe a little bit more quietly, but need to move like in parallel to something as kind of revolutionary as a foster contributor fund. Thank you. Suzanne. So you don't even sit in the Ospo at your organization, which is really interesting because you also have to have these conversations, but I don't even know how you wear that hat at all. So I'm sure it's cool. What do they look like? What color are they? And how do you wear them? You know, I just have to make sure I've got the right hat on in the right room with the right people because it can be very confusing. So at VMware, we are a large, large company. How many of you are familiar with VMware? Right? We're 40,000 people strong now. It's so it is, it is sprawl and we know and we recognize that open source can come from anywhere and that 40,000 employee ranks, right? It doesn't just come from the Ospo. We're the guides and it was in an earlier panel where we talked about guides, we're the guides for the rest of the company. And so when we look at open source and investing and making this sustainable and scalable for a company of our size and complexity, you know, money is probably the worst possible choice we could make when it comes to the word investing. We have to think about investing quite differently. We invest time and talent, not what I call our treasure, because to hand money directly to a maintainer would be not impossible for a company like VMware because we have so many controls and constraints because of who we are and what we do, right? We build software that we sell for a profit. Let's be very clear about that and we're proud of that, but we also coexist in an open source community as well. So our investments are leaning in on our talent and investing in projects via our people and contributions, our leadership via our work with the to-do group on clusters here and chaos, Linux Foundation, all manner of things in that way where we're leaning in with our expertise and our know-how and our people's time, not our dollars per se. And we also look at investment from our customer's perspective. VMware sells to the Fortune 1000. Now the Fortune 1000 company is not all of them have to wear with all, participate in open source community. They know it's critical to them. They know it's important, but they make sneakers. They're not good at this. So they look to VMware to be their proxy to represent their interests in the communities that they're interested in. So we oftentimes become their proxy and help them bring them along in the community. And so I think you have to look at investing a little bit different. Don't get too pigeonholed and the only way to invest in a project is to give it money. There are many ways to invest in projects that aren't just cash. Richard, what's your perspective on open source collective? From open source collective, invest all the time, invest all the money you can. Well, no. So I'm in a weird position where I'm not corporate in the same way. I'm a 501c6 foundation and I'm here to help out those projects. Money is like the least important part of making a project sustainable. Docs are important. Governance is super important. Trying to figure out how to actually deal with the money once you have it. Trying to figure out who's in charge of this project, who are the maintainers there, how do they figure out where the money is going to be allocated, how do they figure out things like code of conduct, when a maintainer burns out, or when new contributors don't come back, or when everyone just gets tired or when other people have shipping priorities. These are the questions I think about, which is a very different approach from a corporate perspective. I have no idea how to deal effectively, which is why I brought you three up and I'm moderating. So I'm just going to pass the buck back. Absolutely. So the conversations we had this week have been really interesting because it's been all sorts of things around giving money or giving money to hands or providing leadership in a way. But what we've been finding common ground on is the fact that open source programs and the strategies they provide have to be intentional around corporate strategy. So like finding the initiatives, the programs you can run, the ways you can invest that align well with your company's mission, ends up creating much more sustainable paths. For us, that meant contributing to our users' integration guides because that meant that we didn't have to argue our value every month, but it became really obvious and that made our program a lot more sustainable. I would really haven't had to defend it, but yeah, defend it to our CEO or CTO on a sense of consumption. For being where I've been talking with Suzanne this last week, that means different things for you all. Well, intention is really important when you step into open source, that you know why you are in that project or in that community. And if you work for a company, I do, most people here do, understanding how that work lines up to the corporate strategy. Make sure your intentions line up. They're not going to be one for one, right? But they have to be aligned. And if you're working in open source and you're working for a small company or a large company in finance or in tech, if you check yourself every now and again and find too much daylight between what you're doing and why you're doing it and the corporate strategy, you need to stop for a minute and ask yourself, how did the drift happen? Is this amount of drift okay or will this cause problems, right? You always have to be able to ladder up. When you can't ladder up anymore, that's when you should stop and have a check. We all know that corporate strategies change in drift. They just do because they are, you know, dynamic bodies of work. And we all know that open source drifts, it doesn't stand still. It can't, otherwise it wouldn't survive. So all this is moving at different places for different reasons. So it's always important when you're investing the way we do in open source is to check in. Are our strategies still aligned? Yes, no. If no, is it close enough? Or is it so far apart that we need to realign? So it's really important. And even when you're doing money, I think it's important too to check in. Strategy is still good. Great. Keep going. Boss? Well, first on that very last point, I'd love to see, especially since we are working with shared resources, what those questions are that kind of check yourselves, I think it would be nice to have consistency across our work to be like, are we drifting? Are we aligned? But all that to also say, I feel like this reminds me of the importance of partnerships and people that can help bridge the language, the requirements, the ways of talking in order to have open source as a movement of body movement and corporate strategies as a body of movement to have your partners help you find spaces of bridging and alignment. So I think that's a lot of the work that we do, I imagine as all of us in the space is finding those partners to help us continue to translate. And to some extent, No, I don't know. Well, I already have my mic up now. I'm good. So every open source community that you're working with is your partner. And so trying to figure out what their needs are and what their goals are is really, really important. And this is really freaking hard. As you all know, especially to go down the dependency stack, the further you go, the harder it is. And there are some tools right now to figure out what your dependency stack is and how to think about it. Ecosystems, ecosystem.ms is one of the main ones. That's me, but the same person who made libraries.io, which is really, really cool, which no, title it uses to figure out there the fancy tracking. That's useful for saying, what are we using? Also the guy I work with. Yeah, my boss, Ben. Yeah, he's great. But that's a really good tool for figuring out what am I working with and how is going to work, but then figuring out which of the main nodes in that tree and what are their strategies and what are their needs and what are their goals and are they being funded adequately. It's part of your job as being an Ospo. And that's tough to do and takes a lot of work. So if you figure out how to make it faster, please let me know. Which actually reminds me that we could talk all day. Could I repeat the what? Yeah, ecosystem.ms. Yeah, ecosystems. Yeah. And there's a few other interesting ones that are coming out now. But that's the main one that's going to be happening is currently being worked on really hard by Andrew. Going to come out in the next month or two, I believe, with more stuff that you can use in your Ospo. Oh, we took like tidbits down in like two seconds and then open it up to... If you have a tidbit. Yeah, I have a tidbit. Go ahead. One thing that I've been chewing on, so Bloomberg Finance, is it's in a really interesting and unique position in the industry in that all of our profits go towards Bloomberg Philanthropies. And so we've made incredible investments and I think difference in everything from climate change to urban development. And so it is of interest to me sitting in the Ospo team to draw the stronger relationships with philanthropic efforts. And so what can I do there? How can I leverage what's unique about where I sit, at Bloomberg with another company, with something that's really quite powerful and making a difference in the world and the sustainability of a larger world. So that's one of my tidbits. And if anybody ever wants to talk about that, please come to me. It's really like these are seedlings. My tidbits may be very different, but something that I keep partnering on is around the money and investment and how it doesn't, it's not the only thing behind the news. But what I found from sitting in my role at Ospo is that it really makes the conversation simpler in two different ways. So internally, when you're pitching upwards or pitching laterally, it just flattens the conversation. Your boss says, how much money do you need? How much money is it returning you? All right, the conversation's pretty much over if you can pitch that well. And we're in a very fortunate position that we can, given just the nature of our business being a SaaS model. So it wouldn't work that easily for everyone. And so what that gives us is that we tell the ROI to our boss, but then as teammates, as people that run the Ospo together, we get to celebrate all the wins of our community, all the little things that they release, to feature improvements as a community and celebrate those together. So for example, we pay some money to this maintainer who created the Ustripe. He maintains that he creates features for them, but at the same time, that little urge of 3K a month or whatever sort of inspired him to take the next step, and he started Open Source Philippines. And now he's developed this whole ecosystem of Open Source. And so we actually ended up just launching Open Source Philippines instead of him as maintainers, and now that's like a collective that he's now running. So that's not the other side of the equation, where the money wasn't the only thing for him, but it acted as a catalyst for other change. And now he's bringing out community partners, bringing out Microsoft, Open Source, and the Philippines, and having all these other changes inspire a lot of that. Okay, two bits. This one's for you, Richard. The fault lies not in our stars, but in ourselves. Is the shade here? Yes, that's for a city bill, you're welcome. And the meaning behind that is about intentionality and knowing what you're doing and why you're doing it, and having those conversations all the time. Don't get disconnected from your community, but don't get disconnected from your corporate overload, if you will, right? Who's paying you? And making sure you're having those conversations. The Ospo at VMware helps those internal conversations happen to make sure there's good alignment. Again, I refer back to how large VMware is and how someone over here could be doing something in Open Source, and over here, same, and over here in a proprietary fashion. And our Ospo helps to get that alignment, that intentionality squared up, and making sure people understand where they're headed, right? So they don't get themselves backed into a corner and unintentionally. So we act as advisors and guides and help people understand what investment looks like in Open Source. It can look like many things, and it's not just money, but it's a lot of different things. This whole week, for instance, is an investment in Open Source for VMware. We're about 18 people here. We have a booth. This is an important place for us to be. So this is an investment as well. It's not a direct investment. It's not a $3,000 check every month. It's a different type of investment, but it aligns to VMware's strategies. So I think that's important. So here you have it, Richard. Thank you so much. At this point, open it up for questions. We have one in the back already, and I'm going to repeat it for the people on the broadcast. So go ahead. How does risk management play? Let's go sleep, roll, go. Big Stux. XKCD Cartoon, right? So the question was, how does risk management play into this thing? When your dependencies fail, how do you know where they are? How do you make sure it doesn't happen? How does that influence your corporate strategy for investing sustainably in Open Source? We give it to Mike because he looked the most perplexed. I'm excited, yeah. I was thinking a lot about this the other day because as a small Ospo, we have to focus our attention on a very limited number of things. You could take any number of directions, like go in the marketing side or the software side, community side, or dev advocacy side. And that is going to make me think that in an ideal world in a software company, there is no Ospo. You just have a bunch of divisions that are all open source informed and understanding how they should leverage or contribute to the community to best advance their goals. And so for Stripe, managing risk is a job of all software engineers, but there's already, like there's tons of risk management organizations that understand our dependency chain and have better insight into that space than I would even. And they analyze it across all of our software stacks, so the open source dependencies, as well as internal stuff, as well as internal forks, all of these sorts of spaces. So in that sense, the Ospo doesn't do too much, but we would encourage other teams to become more software informed and bring in those risk management principles to their expertise area. VMware's product portfolio is enormously complex and diverse across all kinds of technologies. So risk management, it's a little difficult to pin that down. Our Ospo provides guidelines, best practices. We provide guidelines on types of licenses, on how to create what we call an OSL. Release management, we rely on our security team, we rely on our legal team for IP and trademark. Patents, it takes a village for risk management because risk management is a large field that could include any number of things. So it does take a village when looking at open source and your dependencies and what are you using and why are you using it and all of that. So it takes a lot of people with a lot of different expertise. It doesn't lie in one organization for VMware. And I see Dawn nodding her head up and down. She's quite aware of risk management. So questions for Dawn afterwards. Dawn, raise your hand. She could go on forever. So break a big coffee because it won't be a short conversation. I want to agree with everything that's been said before. And as a, I guess two things. One, I think it's important that the open source program office is present at the conversations around risk assessment and management and the tools because what we are asked to be aware of, responsible for leaders of is part of risk management. So just being in the room, I think is important for successful addressing. And I'll just give one example of how some things have changed for us. So with the log for Shell, we're on a phone available at the end of 2021. Yeah. It became a priority for us really generated from the people that were addressing the issue internally to become a member of the Eclipse Foundation and to support the Adoptium Network, Adoptium Foundation, which is physically hosted by Eclipse. And so that's something that Ospo, like we heard, we were able to hear that there was a risk in our entire ecosystem and that there were like efforts to address that prior to such events. And we looked to put our support both in terms of technical leadership as well as like financial investment into like the foundation and the projects that are already working towards such things. The thing I would say around Ospo is that it's not just the Ospo's job to fix the risk. It's the Ospo's job to communicate the risk internally to everyone there. And just like, you know, when the Queen died, they didn't have to write a new article for New York Times. They already had that written. They were just sitting on it. So I would start sitting on all the different things that might come up and just be ready to explain that to the CEO. No, it's okay. This has happened for this reason. Yes, we're working on it in this way. And whatever you do, don't email the open source maintainer and demand a lot of stuff. But please, please don't do that. Yes. And it's also, especially now in the current climate, a lot more federal talks are happening and not just in the US, but in the EU. So listen to OFE, listen to the land council. I think, but listen also internally to where you all think there are risks. I'm sitting in Dwayne with your hand up, unfortunately. I know, I'm scared of Dwayne's. It's an act of love. What's up? Yeah. It's a large organization, but the smaller you are, the harder it might be to prioritize the head count for a dedicated person for that. So for the smaller companies who want to get involved in sustaining open source, either financially or at the time, what advice would you have? So the question again was, the 2021 survey showed that a third of Ospo's that are going to be started are companies of 1000 people or less. What are the strategies for smaller companies to deal with open source when they don't have the resources to dedicate an entire team or even an entire person to dealing with open source policy at their company? That is a very good question, which none of you are able to answer except Suzanne. Why Suzanne? Because her hand was up. Kindergarten, you raise your hand, you get to talk next. It's how it works, I don't know. So yeah, I work for a huge company, but I think when you step down and look at smaller companies like Stripe, it goes back to, I think a shared sort of experience. Where it takes a village once again. It doesn't take a full person, but a little bit of your time and a little bit of your time and your expertise and your expertise and have a council have a some sort of club. I don't know, call it what you will of people who know certain parts about open source and can meet regularly and help to guide the company around those decisions. How do you justify some of that? Well, one of the justifications, I think it was that piece of research Dwayne, or maybe a different one that shows that up to 80% of a code base of an application is reused and within that is going to be open source code. And if you're not accounting for that, right? You're you have a blind eye to 80% of the code you're shipping. Does that feel comfortable? It should scare you. You should pause and think, oh, is all of my budget of time and talent and people going to just the 20% I see? What about the rest? You would never invest that way. So I think you have to kind of reevaluate where you're at with the software that you're using and producing and really understand if you are correctly applying your personnel investments and do you have back to your mentioned back there of risk management, do you have a risk issue because you're ignoring a huge chunk of the code that you are either using or relying on or shipping the packaging? I'll just add to that a little bit because I was both formed out of a council just like you mentioned and I thought that was a great point so it doesn't have to start with formalized headcount and in fact you probably need partnerships to start one anyway so you need dev advocacy, legal, engineering, design, brand, like all these folks are involved in the making of open source so that's how I started and for in terms of turning it into a team with headcount the advice I got when I was transitioning doing open source full time was if you just start doing the work and you end up doing open source full time and that is valuable to your company and you don't need to defend that value then you just get the headcount by default and so that's that's what worked for us and I guess I had good leadership that understood that my boss is boss who approved the Ospo for us she always says like if you need to like argue your worth like it's probably not you're probably not doing the things that are valuable so yeah just like keep trying to find the alignment for your team what I would say as well is something like 9% of the current applications use open source and so you could also lean on inner source as being a way of justifying an Ospo and outer source thing so talk to Claire and figure out how that works Claire I'm not going to go with you but I'm going to go with this guy question yeah so I definitely resonate with that perspective where if you're having a conversation with any of the stakeholders in terms of giving money it is very easy to have that conversation in an open even with an open source project where you can show positive revenue or show positive return on investment so my question is have you ever been in the situation where you are dealing with a harder to demonstrate that return on investment or the situation where the return on investment is clear but there is a wide it could be this it could be that so it's just a wide band in terms of what that horizon is going to be and then for those types of projects I guess my question is how did you measure it and how did those conversations go so the question was how do you deal with circumstances where ROI is either dubious or lossy and you're not really sure what's going on how do you talk about that to your company so I think Mike that was to you it was pretty much Mike yeah cool cool yeah so uh yeah that's a really interesting question particularly because some of the investments we make are for projects that are just getting started they don't have users yet they definitely don't have money yet and so we end up we end up basically treating the ROI of the programs the whole not necessarily treating them as individual individual ROIs but is this collective investment returning to the company in the same way like a VC firm would right like they need the one unicorn to return the rest of them can all die we don't we don't go we don't like we so then we end up investing in those those projects nonetheless because they nonetheless we invest in them nonetheless to keep them running yeah and so some of the projects we've invested more recently haven't been the ones that make us money but are our dependencies and the argument for in those investments have been different whether it's getting like an enterprise support contract by paying a monthly fee through get up sponsors or investing in one of a a new dependency that we want to take on and we want to make sure oh is it this we're going to rely on this indefinitely so for this particular case those maintainers are asking for it and a sort of like joint licensing model I'm sure you're going through it that approach and so that's just like an instant power while where we couldn't adopt that new dependency about it I think we have time for one more question moving Claire is that okay yeah it was in relation to a specific game when you're investing talents of time and the service more towards money or whatever they release the survey results we're talking about is the fact that there are more and more people doing that in corporations but that the like carving out that time and time pressure seems to be one of the barriers to sustaining that effort and so great that you know you be ever would would like have that have them as most popular but I'm kind of curious as to tactics that enable individuals to continue to carve that time actually and do you have any for that so the question was what do you do when giving time talent treasure and then time actually is good but it's not sustainable in the long run because that hurt your company's ROI in general or hurt your company's paycheck how do you deal with that so it goes back to you know intentionality and having those constant conversations with your management and your manager and your team because again as we said earlier projects drift so do corporate strategies so do product roadmaps and having that that conversation in tech time is always not enough you're always scrambling you're always behind and so it's just a constant battle whether you are an open source or not and just having that conversation we hear it all the time if you're more I don't have enough time I don't have enough time I don't know and so it's it's I don't think it's any different than any other conversation you're going to have with your manager and you know when you're working on a product and I say that word specifically something that we sell and there's open source dependencies that's where you have that conversation that says well the success of the product depends on our continued investment in the projects that comprise the product and are you're laughing at me but again you have to be very explicit the language changes in open source and if you're working with product managers who are unaware of that you really have to be intentional with your language too and have those constant conversations and it's always going to be a problem so sorry my friends and comates in exile we do have to wrap it up but unfortunately the best part of the conference is the copy track so do meet us over there if you want to talk further and thank you so much for coming thank you