 So, a bit of a backstory. So, Spotify has been using Open Source since its very beginning. They was founded based on establishing an engineering team first and then figuring out how to do this old music thing afterwards. So, naturally, Open Source was just part of what we adopted and used from the beginning. And also just as natural engineers started publishing code as Open Source as part of that process. So, there was no company decision to focus on Open Source or any central governance. It was just something that organically happened. It was part of this autonomous engineering culture that Spotify has. If you looked into working models for engineering cultures over the last five years, you've probably seen this Spotify model of autonomy and tribes and squads and so on. And that's very much how we practice things in Spotify. So, engineers are empowered to do what they feel is right and what they're passionate about. But still, after 10 years, we are seeing, you could say, challenges with this kind of thing at scale, especially around Open Source projects. Because we see a struggle with actually prioritizing our own projects. We see that we can't keep engaged with our own code long-term. And we also sometimes have even a challenge rationalizing why did we even do this? Like, why did we even open source this? We don't care about this Open Source project and no one else actually does either. But we still decided to do it because no one really asked questions about what is the value of doing so. So, in the sense, inside of the way we work in Spotify is we have a strong set of principles and ways of working for normal work, like projects, but we never applied those to Open Source. So it's kind of a gap. We see Open Source as this like passion-driven kind of perk for employees, whereas our internal projects is very much, we are guided by very specific principles of what makes sense to our customers and also at the same time learn and measure and adapt, but we never applied those principles to Open Source. So, after 10 years of doing that, we have kind of come to the conclusion that passion-driven sources is great. But in the end, Open Source work is essentially just work. You still need those mechanisms to decide if as a piece of work for an employee or an engineer does it actually make sense to do for the business? Otherwise, you end up with these hobby projects where you forget the whole thing about value and goals and dedicating resources and so on, and more is just a hobby. And so, we don't think it's just a challenge for Spotify. We think it's a structural problem in the ecosystem and also we think this kind of thinking about Open Source as a hobby or a passion-driven thing is also something that has a negative impact on sustainability and diversity in the ecosystem as well. Jim also talked about this in the keynote this morning, which is great. I think it's great that they actually start talking about how do we do this? Also, I think he's wrong when he says that money doesn't make a difference because for a lot of projects out there, money is equal to time. We'll get into that a little bit more. So, what I'll do here in this presentation, I'll try to share the findings and our principles and the concrete changes we're doing right now to try to fix some of these problems for ourselves. And also give you a bit of more background why we feel this is also a way to address sustainability and diversity in the ecosystem at large. Before I worked at Spotify, I worked with a different company in Europe called Serando on their open source and security topics. And before that, I spent 10 years in an open source software company with a 200, 400,000 developer community behind it. So, I've tried to be on both sides, both as an open source consumer and also as an open source vendor. So, the agenda, we would just look at three metrics we kind of looked at to kind of figure out what we were and kind of understood the problem. Then the three different kind of beliefs of principles that's guiding us going forward and then three specific things you're doing now. We don't see that as the end game, but we see it as three concrete things we could start doing now. So, the metrics. So, this is the key metric for us because when we looked at our commit data and looked at the employees inside of the company, so for our employees, we don't measure community members' commits like externals because we don't know where they are in the world, so it's very hard to actually tell what their working hours are. But for our employees, we know they're working hours, we can see that over half of it is outside working hours. You could say for a company, that's of course great because people work for you for free. So, from a commercial perspective, that's probably fine, but it does end up being a problem in regards to sustainability and burnout. People essentially have two jobs. They have their actual job as part of that, and then they have that open source project they maintain on our behalf. It's also a metric that's on par with the industry. About half of all commits on open source project at large is done outside working hours or on weekends. That's from a 2014 study that hasn't been in New York since maybe this change, but I highly doubt it. Also, if we look at our dependencies, we have very little influence on our dependencies. We don't have any kind of upstream strategy, what do we decide to engage in and why? When we actually pull in bigger infrastructure components, we have historically not actually had any sort of collaboration with that upstream dependency, and so that also gives us limited involvement and limited influence over the dependencies we so highly depend on. When we talk about supporting these dependencies, we had not had a program for doing that, neither financially nor non-financial support of these dependencies. So we didn't really know if we had an important thing in our stack and how this was supported and how we ensured that it stayed alive so we could safely depend on it. So looking at our own projects, we have about 125 projects in our GitHub repository organization that we deem somewhat active. 116 of these do not live up to a basic quality baseline that we set for our projects. So that means that they have open security abilities, they have pull requests that haven't been addressed for more than three months, they have issues that has not been addressed for six months, and some of them haven't had commits within 12 months, so they are practically not active. If we zoom in a little bit, this is a chart that outlines number of active repositories of public and not archive repositories in GitHub compared to activity over time. So you can see the number of repositories just keep growing and the activity line just stays somewhat flat. We don't have the same kind of growth compared to the amount of code we actually maintain. You can see there's a bit of a change around January 2020, which is actually more to do with the different security tooling that started to become a thing, like the Pentagon. So it's more like these automated updates on our repositories, and I can see this trend going up a little bit. So, somewhere just in where we are is that we have generally a quality and longevity challenge with our own projects. We also see that when we actually open source a project, it gets harder for ourselves to actually use it, and that's a tooling problem. We can't use the same testing and build system and so on, so once we open source things, it actually becomes less popular and satisfied if I use. But anyway, these products, it has a negative impact on the experience for contributors. It's generally a security problem for everyone who depends on our project, that we don't maintain them properly, or we abandon them. But I think the most important thing for us actually is that we cannot tell the difference between success or failure. Like we can pour in engineering hours into a project, and at some point, because we didn't give the engineer dedicated hours or support in the community support, marketing support, financial support, this engineer will walk away and do something else with his time because he's had to do it in after hours or weekends. So a promising project might end up being abandoned. At the same time, we might have a very dedicated engineer putting hundreds of hours into something that makes no difference to the world. No one cares. It only cares for him, really. And that's just a smart, much of a problem. So we as an organization need to be better at telling a difference between what is actually a valuable project to us and a not valuable project to us. And the metrics show that we are clearly failing at that. So with that, three different beliefs that is guiding us going forward and some metrics to just kind of explain how we got through that. So, a tight lift in Black Dock has done some surveys about maintainers. And this is like the long tail of maintainers, not the Kubernetes or Linux maintainers. As we heard in the keynote today, they're pretty good with time and money. But generally speaking, half of all maintainers don't feel compensated money-wise for their work. 45% of them feel stressed because they have to maintain this project outside of work. And also, the general positive changes in regards to security and compliance is gonna lead to more demands on maintainers going forward. We see all these different things about test bombs, securing the supply chain and so on. These are gonna impact maintainers. Also further down the stack. We might start with the Alpha Omega projects now, but further down the stack, we have the Colorado JAS projects and the little tiny utility projects that is not part of this and won't get a resource to do it. But they will still end up being impacted by this. And for us, what we care about this is that if we depend on an abandoned project, that is an enormous risk for us. If we have something that we've referenced 2,000 times inside of our landscape and the maintainer decides to say, I am not gonna do this anymore or just silently walks away, then we are depending on that code. And we don't wanna do it. That's why we have a dependency that didn't build it internally. So for us, funding a project is actually the cheapest risk reduction method we can think of. If we can give a maintainer 5,000 euros to work on something without any strings attached, we are not paying to our features. We are paying just to keep maintaining ad security updates and so on. That is the cheapest way for us because it would be so much more expensive for us to update all applications to a different alternative or find out how to forget and so on than just paying this person to do it. So this is the first principle and this also applies for our artists on the platform. Well, we believe creators should be paid for their work and that also includes open source creators. We can't pay every creator in the world. We don't have the money for that. But we do believe we should be creators we depend on. So the next one, next principle, if we look at, you could say the diversity of commits in the ecosystem around 9, 10% of all commits on open source projects are from female contributors. There are different studies but there varies between like 5 to 12% of the thing as a max. At the same time, we also have this metric of half of all open source work happens outside working hours or on weekends. And then the last one, if you look at a job ad for any kind of tech company in the world, they would most likely have a desired skill around contributing and maintaining open source. So that means that we have built up an ecosystem that is for a very specific kind of person. You do this outside working hours, you do this in your weekends. There's a very low diversity in the ecosystem and sometimes it's like a highly valuable skill. So our guidance is we don't think that it should be just for people with evenings and weekends to do open source. Also we don't think it should only be people who are paid by tech companies. We need to find a better way of doing this. Also because what you learn in open source are great skills for career progression. This can bring you forward from being a junior engineer to a mid-level senior engineer. The things you learn in open source projects are valuable for your career. And if we gate keep that and say you can only do it after hours on weekends or we don't pay people to do it, then that's a very specific kind of people. And so for us as a tech employer, we have an obligation to improve that diversity. We need to ensure that our employees have dedicated working hours when they work on our behalf. So it's not just for the 20-something dude who likes to do JavaScript on the weekend, but it's also for people who are above 40 and have a family or for people who have sick relatives or for people who have a larger degree of home like housework to do. So we can enable anyone to do this because this is an important skill for your career to develop. So that is the second belief. We believe that all employees should be given support and work time to do meaningful open source now. So the last one, when we look at the ecosystem at large, when we talk about successes, a lot of the time we talk about an open source company became a success because a bigger tech company bought it. So we can see Red Hat being bought by ABM, nothing against Red Hat, or IBM, it's fine. Or we see that open source libraries getting repackaged into cloud offerings, or the open source projects who have received a lot of funding are pressured to make enough money so they're re-licensed under a non-open source license where they kind of foster customers to pay. So we believe that we should try to decentralize the commercial success in the ecosystem. There should be more small vendors. You shouldn't be required that you are like an open source unicorn. There should be more room for open source small businesses. There should just be room for maintainers who are fully paid to do it. And also for us, why we care about this is because if we can actually see a dependency that has a commercial strategy, so they can pay their bills, they can pay their engineers, that is actually for us a positive sign on longevity so that we can keep depending on them. It largely reduces the risk of depending on something if they actually have a commercial strategy. And we'll gladly pay them a license fee if they have a commercial offering because that also means that we get a more stable product to depend on. It reduces the risk for us. So this is a very long belief, but we do believe that the ecosystem is better off as a whole with more independent commercialization. We should move from this very lovely picture of everything is free, but to actually start having a more normal way of charging money for what you do. The old fashioned model of I provide you value, you pay me, still works. And it is actually a fairly decent way of actually making sure that people are paid. But it's a hard thing to do in the open source communities right now because you also have these like larger tech companies like Google, Facebook, and so on who actually offer everything for free because they have other income channels as well. So it's hard to be a small open source vendor out there because you don't have a search engine to pay for your bills. But we do believe that we do need to remove the stigma of making money for open source containers. So also the principle is the right thing to do. We don't really believe in that because it has a tendency of these like the right thing to do kind of thing have a tendency of going away on once you kind of hit like more economic on certain times, you can see this in these times now. And also as Jim mentioned in the keynote that companies have a harder time justifying and investing into the comments. So three things we're doing now about this. So regarding by the beliefs and these beliefs has led to like two concrete things we're doing. First of all, this is very much like an internal facing thing is that we want to move open source you can say up or down to be an equal term to any other kind of work inside the organization. If we look at again as I talked about in the beginning we have operating principles that helps us define work in any other kind of in the organization. These are the five principles we also have like a larger framework but around like focus optimization differentiation synchronization but also the last one is like learning and adapting. So these principles drive our normal work and this should also drive our open source work because it's not really any different. So far as it's about elevating open source work and looking at impact and purpose when we do these projects. So where we want to be is we want to ensure that open source work is prioritized and equal terms as core business work. This is where you zoom in to when a team make prioritization decisions. They likely have a feature or service that powers one of our applications or music streaming or whatever but they also have an open source project they own. At some point this team needs to make prioritization for their backlog and say we need to add this thing here for that's a way of how I'm just gonna look. We need to prioritize updating our open source project or we need to add feature X to the mobile app whatever. They need to have a framework where they can actually compare those two things on equal importance saying we are actually doing this open source project because it helps us hire for the team or it's a good career development for the junior developer who's owning it or it's actually important for the company to own this specific niche in the landscape or it could be any other thing but they need to know why they're doing it. So a team needs to be dedicated to actually, here we go. So the team needs to be committed to doing this and also they actually need to set goals in their key results. Like when we are going forward as a team what is it that we actually wanna achieve with this open source project? And we've seen in Spotify teams at least there's a tendency to just like yeah like open source is just an ad hoc thing we'll do it every once in a while when we have time for it and it's not really driven by a roadmap or concrete goals. Any other kind of work in Spotify is driven by roadmap or concrete goals. So why is an open source? We believe that it should be the same. So this is it. It boils down to that a team before they actually release or start like a larger opportunity and contribution is that they actually have an idea of the purpose and the value of why they're doing this and it's not just driven by an individual but it's actually driven by a team decision. Oh, this makes sense for us as a team. It's not just driven by a random person over here who just thinks this is fun. It's actually a team decision because in the end you have a budget of hours per team you can use per week for things. And an open source project if it's important for the team you can set aside hours, work hours to do this. Another thing we've done is we've added metrics for all our projects. So these four, it's hard to see with the screen but that's like four boxes at the top. This is the four important things for our teams to actually understand when the owner projects these are the metrics that we care about. So of course you have the spectrum of contributors, you have security, you have responsiveness of PRs and issues and then you have how much of this work happens within working hours. So we now have a metric inside the company that we measure all the time saying you have a project here but you actually only spend 10% of your working hours on this. So this is clearly something that's like weekends or evenings, maybe it should just be a private project. Maybe it shouldn't be a Spotify one or maybe you can actually ensure that you dedicate resources for it so you can do it in the right way. So for that, prioritization and team ownership is the only way for us to live a long term in quality for that. With open leadership there's also a responsibility to actually measure and adapt. It hasn't happened yet but we have a sense that once we get the teams to go into this mindset of actually measuring the impact and learning from it, they've also at some point come to the conclusion that, oh, we should actually probably just archive this or we should add another engineer because we can see there's actually traction here. And again, like in the matter of priority, it is business first teams and then individual needs whereas before it had kind of been the other way around it's an individual with a passion who has done something. We do want to have the perspective but then it's the business who are investing to this so you should also understand how it actually benefits the business. Okay, so funding. So I think like largely when we talk about the left side like the more important, more critical projects, they are generally paid by their employer to do open source work. But then you have the long-term, long tail and that's where money equals time because they don't have a salary for an employer. Employers like to do that kind of work. It is something they do outside of work or they do it as part of being a freelancer or small business and they do need to find the money to actually justify the time investment. So far as we still see that money does matter for open source projects, especially when we look at our dependencies, we see there's clearly to fund them. We also completely filter out stuff that comes from Google and Facebook and other like large companies because we know they have paid staff to actually do that. So last spring we started an initiative of experimenting with funding projects because we honestly don't know if it works. Like I don't think anyone has actually seen like a metric that says, oh, this actually improved the thing. So we started out by dedicating 100,000 euros and we also decided to be public with the number because we need to start somewhere and we see this as an experiment. So again, we try things out, we learn from it and then we adapt. Our focus was very much to have eight to 10 recipients of this so we actually give them a fairly large sum of money, again a small project but giving them a large sum of money. Nominations came from our employees and also from our dependency graph. So it's like a bit of a quality metric and a quantity metric. And again, we had to focus on independent projects, actively maintain and also align with our company values, do it, they have a code of conduct and so on. And we wanted to do it as a yearly thing. We didn't wanna like spread it out over the year. Also the reason why we wanted it as a yearly thing is that we wanted to have like a, you can say a point in time when we say, okay, we gave these projects money at this month in time. Let's six months for them, let's look back and see if it actually has an intangible impact on the metric we care about. So we funded projects, doesn't really matter what it is, but maybe you recognize some of the logos. I think what is problematic for us is that we know that these are good targets to fund. We know they are represented across our landscape. We know if any of these things went away, we would be in problems. However, what we don't know is, we don't know if this is actually the best ones because it's very hard to actually decide if a music streaming encoding library, how important is that compared to a JavaScript testing library? And we have both a music encoding code here in a testing library. So how do you determine that? Like engineers can't compare those things across an organization. You can't decide what is the best ones. We know these are good. So, but I think we need to, we need forward, we need to find a way of figuring that out. One way we're doing it is that we are repurposing this idea of the first fund to actually drive it into the team budgets. So we are enabling teams to actually just take from their own team budget and pay an open source dependency. They don't need to pay for a specific feature. They don't need to have like a support contract. They're just paying them for their already done work in that project. And that, getting to that point is hard. Like convincing procurement, legal and all those things to pay for nothing is hard. It is not a normal thing that companies pay for nothing. So, but it helps us actually move that criticality understanding into the teams. So the teams actually make a decision. The team that actually depend on that audio encoding codec, they understand how critical it is. And they can actually make a better decision than we can like broadly for the entire company. So, or you said this, we're running out of time. We're just going to skip this. So the last point we are doing now is we are focusing on commercialization of our own things. We're not going to commercialize everything, but we are trying it out because we feel it's important for us to also do what we preach. So Spotify started the protocol backstage. It has been donated to the CNTF, but we still do the majority of the work on it. For those who don't know backstage, backstage is a framework for developing internal and other platforms. You can keep all your applications and services and whatever else is interesting for the developer in there. So we've used it heavily in Spotify for the last five years. And it has been a success from a room's perspective. We have over 400 adopters companies who have adopted backstage now, 1500 contributors, a lot of folks, a lot of contributions from the community as well. If we look at it from the insights, we have around 40 people working full-time on backstage. There's now a backstage organization and they put 40 full-time positions into this project. That means both building on the open source version, making sure we move more and more features from the inside into the outside. But we also need to have a path towards sustainability. Again, we have these more uncertain economic times now and we cannot continue having 40 people working on this without any tangible benefit from it. Of course, we get some branding and hiring benefits from it, but that does not justify 40 full-time positions for Spotify. So we need to find another way. We want to make this a sustainable project and we actually want to commercialize on top of it so we can stay engaged with the open source projects. So we can stay as engaged with the open source bits now, but we actually have a commercial strategy for paying some of these people inside of our teams. So we can do this long-term. So basically for us, the bet here is, or the model for this is that it'll be a free remodel. There's a commercial bundle up top of the open source core. The core was the open source. The core will stay with the CNCF, we'll continue maintaining it and investing in it. But at the same time, we'll actually get revenue streamed in from these commercial activities that we're putting on top of it. At the same time, we also want to enable revenue from other people in this ecosystem. We can see there's a plug-in model for backstage and we do want to enable other people to actually charge for their plugins. We don't feel that having everything for free by default is the right path forward for a pro-source. We feel that there should also be ways for maintainers to make money on top of this ecosystem. In the end, this is to make our own investment in backstage self-sustainable over time. So we want to keep investing to make backstage as good as it can be for the open source one and for commercial features, it's like role-based authentication. It's like these like more, you can say, enterprise-driven features we want to put on top of it so we can sustain our investment. And also we need to build up an organization to do this like long-term, both for support, sales and so on and so on. That requires a lot of funds. So to summarize, the three things we're doing or the three pillars we have is it's essentially making sure all employees have dedicated work hours to do their open source work. Is to make funds available for dependencies like third parties who actually need support. We want to make sure that they have funds. And then the last one is commercialization. We want to support open source commercialization both by actually paying commercial projects that we pay now but also enable our projects to commercialize into our backstage. And of course the last one is we also want to commercialize backstage to make sustainable. So it's not just a vanity project, not just something we're doing until people think it's not fun to spend 40 people a month on something that doesn't have a tentative benefit. And if you think about it like ensuring that you have funds ensuring that you have time and also ensuring that you have somewhat of a financial or a commercial model for your work that's all very normal considerations for any kind of work but open source. But first we feel that it's time to try to change that and ensure that you can participate in open source without spending your nights and weekends that you don't need a second job to pay the bills and that you also, that we can actually create like independent self-sustainable business instead of depending on venture capital and building unicorns and all that. So I think we can still be very passionate about open source but in the end like open source is just work and that can be work that you are paid for as an independent maintainer or that you get time to do. Maybe it's work that turns into careers or businesses. And I think for Spotify as a tech company highly engaged and also benefiting from open source we have an obligation to make sure that happens. So thank you very much for listening. There's a number of ways you can reach me if you have any questions and I think we also have time for questions now. Thank you very much for the talk. It's very interesting to know what Spotify is doing with open source, contributes and supports. So my question would be about the project which Spotify is trying to support by, I don't know, budgeting or funding. And I know that in this case there is a risk that the developers or owners of those projects would feel obliged or become dependent on the company funding. So how can you tell if you're worth about this? Yeah, we thought about it. It was a risk and a consideration also when we decided to go with a larger sum of money. And we tried to make it clear in the communication to the project owners that this is a sum of money. You get no strings attached. It is a one-time fund. We might fund you again next year but just to understand this is a one-time fund. No strings attached. This is actually payment for work already done. We see you have maintained this for years and that's actually what we're paying you for. Not to add features, not to do support, not to do presentations. Of course we love that we have a contact with you as a project but we are paying for work already done. So it sounds like a donation. That's how it sounds like, more like a donation. Yeah, and I think that's the only way we can kind of get into this neutral thing but for us it's, we know that there's a power balance in balance. We are a big company and they're like maybe one or two people projects. And yeah, it is a donation. But for us it's also for us to see them as a vendor. We would rather treat them as a vendor relationship and sometimes a vendor do need to get paid to deliver quality products. So we don't like this idea of donations because it seems like it then puts projects in the mindset that they have to kind of depend on the goodwill of the richer people in the ecosystem which I think is the wrong way of doing it. Like they're providing something of value and we are paying them for it. Thank you very much. Thank you for your talk. I really agree with your slide about the open source work is prioritized on equal term to core business work. So my question is, as a perspective of Osco, I agree with this, but as the other person like a city levels or business levels, they kind of want me to calculate some numbers, right? So how did you persuade to get budgets or something like explanation? Yeah. So it's a very individual thing for each company, how they actually get value out of open source. I think for us, it has been a good driver for hiring. So that has value and we can justify that. For instance, our research team releases quite a lot like both papers and open source code because it does show these are the interesting things that we are working on and can attract new hires. You can say hiring is not as big of a protein as it was before, but it is still an important thing. That shows value. Then of course, your challenge is not supposed to kind of show that doing open source actually helps on your hiring. So when hiring and branding is quite up there. Then for the team that is releasing a project, if they actually can benefit from having outside contributions or getting their project adopted by another company that helps them make it more resilient, that's also something we're seeing. We have some different product for data pipelines and so on that other companies have adopted. And then we do get contributions back that makes our own code more resilient. But it's very much individual down on what does your company do and what to achieve with this? What does the team do and how can deep benefit from it? And then the last one, how can the individual benefit from it as well? Because I think you can also make a case that says, we have a junior engineer here. He's built like a library, a feature library and wants to open source it. So he can actually try to both interact with the open source community, get that experience and also build up like skills for progressing in his career. And from like a retention perspective or like you want to keep your employees and make them grow, that can also be valuable. But of course you need to find the destination. Thank you. Thank you. Hi, thank you.