 I think we can wait a couple of minutes to see if anyone's coming. I recommend those in the back that you come closer. It's going to be warmer for all of us, and also to see the slides, because they are a little bit dark, I think, so the contrast with the text could be a potential issue. If you are that long, that far from the slides, OK? So are any of you aware of the concept of open source open source program office, what does it usually mean? Or is this something new for you? OK, at least one person knows. You know a little bit about that. OK, you are the one opening. My name is Brian. I'm from Uber. I manage the Uber's open source program kind of office. We are still building it. So when I first joined Uber, the open source program, the open source program of the concept was very vague. We had a program running, because like all other companies, we use a lot of open source software. We create a lot of open source software, but we never had someone that really helped facilitate the whole process and policy. So I was hired to do that. So the first thing that came to my mind, or the first thing that came to my realization is I tried to figure out what's the full scope of open source program, or you want to call open source program office. I just call it off-call for now. So this is a full scope of a common open source program office, need to cover. There's two parts. When we talk about open source software in a company, there are three kind of activities, most of the time. You either consume open source software, you contribute to the upstream open source of wear project, or you create new open source of wear. And you can kind of divide it by two big parts. One is inbound, you take things inside your company, and the other part is outbound. You put things outside of your company. So those are big two categories, but if you, when you look into it, it's kind of complicated, because when you put things out or you take things in, it's not just engineering process, there's some IP implication there. So what's the company's policy when we push something out, share our intellectual property to external, and when there's external facing, then you talk about like, you talk about, are we okay with sending this kind of message? Because whenever you do something external, there's always the implication to the business, and depends on who you ask for. So if you look at a full scope, it's kind of complicated. And for someone to manage the full scope, it requires a lot of different skills. Like you need to be, you need to know the license, like this, a bunch of different open source license. If you one of them has different implications, which one is better for us? And you also need to be able to speak the language to talk to the attorney inside the company. So they speak very different language, you need to be able to understand that. And then you also have a big chunk of stakeholder engineers, because they are the people that are doing the daily work. They use open source of work, or they wanna create open source of work. They also speak a very different language than attorneys. So you need to be able to understand both language and try to bridge them and get them into a consensus. And so you need to know how to communicate across different area of different expertise. And you also need to have some kind of strategy. Like what, for example, a big question is, why are we doing open source? Like why are we creating open source? So you need to have an idea of what the strategy, how does it align with our business goals? Those are from skill sets perspective. They are very different skill sets. Like you need to have engineering, processing to be technical. You also need to have the full skill. You also need to know the legal languages. It's very complex, like the whole scope is very complex. You need a lot of different areas of expertise to help you. So one person, maybe someone is really, really good, but for me, I am not a good, so I need a lot of different expertise experts to help me to navigate the whole scope. Also, in most of the companies set up, those experts are not in the same team. They are usually from different organizations. Usually the attorneys are on the legal department and you have engineers either on the R and D or some company has a research org. Those are the people from different teams. How do you put them together? There's also another thing that you have to take care during building the open source program office. So if you look at this, the nature of an open source program office in a corporation is all about collaboration. A lot of skills, you can find the skills that each group, each people, they are all there to experience your company, but how do we put them together to work together? That's a collaboration problem, right? How do you do that? On top of that, it's very important to understand, like, so what is that we are talking about The program is a very vague idea. What are we talking about here? So are we talking about a program that basically only works with internal stakeholders? Like everything we do is internal, for example, that we only care about our own open source of words. Open source of words that we use, we don't talk to anyone outside of the company at all. Or do we still need to work with our communities? For example, if we create open source targets, does this open source program office, is this open source program office responsible for building a community around our project, promoting our project? When we push ourselves to uptrend, who is maintaining the relationship with uptrend, maintaining all the projects, or even the foundation? Those are the questions that someone has to decide. Depends on who is your exact stakeholder. Someone has to decide that, right? That's the goal of the program. And then the next thing is the challenge requirement. You might have everyone, all the experts that I mentioned in your team, then you're lucky that you can control and work with everyone within the same reporting structure. Things would be a little easier. But I think most of it could be wrong, but my observation is most of the open source program office leaders have to work with across different teams. Especially the legal teams usually in outside of the reporting structure of the open source program office. So you have a metric system that you have to navigate. You need to know who is the stakeholder, who makes the decision, how much capacity do they have to get to you to help you. How do you put them together? They all have different priorities, even timelines. Different agenda or different perspective of what open source program office is. So this is something you have to work on. And when you come talk about a program and there's also a budget that you talk about and then you probably need to work with your program management office in the company. So it depends on what kind of program management office structure you have in the company. You decide how you can work with other people. So some company has a centralized program management office. They have all the policy templates that part of everything that you have to follow. And then you have to try to see how your open source policy and process fit into your corporation program management office scope. And some company have the more coordinated, like each department has their own program management office. They get to decide their own policy, the process and budget. And it's probably a little bit easier for you to do that when you have the kind of structure because then you can set up your own policy. But again, you still need to pull the net apart or the program management office. So these are things that you have to look at and then try to decide what would be the best fit for the company or what do you have to try? We need those frameworks. And then we talk about, once you have that and you need to talk about the process, why do we need a process? Because we are not just talking about developing work, right? In the beginning I talked about policies about license. Those license implications are really high. So you have to set up a process like how do you get things approved? As simple as how do I get things approved to go outside of the company? So you always need a process. Most people don't like process but you need to have a little bit of process otherwise you won't be able to get things done. And then you have to decide, okay, how much process do I want to put in place so people don't hate me? But if you follow the process. I remember when I first communicated to the whole organization saying, hey, everything that you use, you want to take into the company, you actually need approval, like formal approval. Like here is the policy, here are the license that we approve and here are the things that you actually need. Like real approval, like you cannot develop it, I'm going to use it. I sent out an email and within the 10 minutes I got 200, 300 emails telling me that this is ridiculous, you are reducing our productivity, like have you really thought about it? We have a tool for what we can talk about it. But it is very important and like the process actually might, that's right. The process and the people and the culture are actually really tied up into, tied up together. When a company has a very rigid process, it also put around sometimes trying to help people's creativity. But it's actually going to add, sometimes you have a culture first and then your process go around it. Sometimes the process kind of define the culture without knowing it. So whenever you put up a process, it's very important to understand the implication of the process might change the culture potentially. On top of that, the stakeholders are very, very complicated. So as is, there are four different categories of stakeholders that opens up for more of this has to handle. One is the two most common one is legal and engineering. So the engineers are those people that actually are doing all the work, they have the required and needs to work around all the software. The legal teams are covering the IPs, our compliance and make sure that everyone is protected. But if you are doing, creating an open source project or even if you are very vocal about how you use open source project, you might need to talk to your product team and then do the business. Make sure that everything, every single message we send out to the community, to the public, are aligned with what the product team and the business team want. Especially when creating an open source project, the product team has to be comfortable with sharing this social truth outside. And we also, the business organization also needs to be very comfortable that we don't accidentally leak something that would enable our competitors. Basically, those are the four big ones. So financial is very interconnected metric and you have to handle not just internal and external in a very cross-functional governance way and the project inclusion is kind of tricky because you are taking a lot of different people and you try to move forward in the same direction. But if you look at the four categories, they, by nature, they have different way of working in the same, even just to get one thing. So there's something the open source program also has to try to map it within the company. There's no one way to do it because every company is very different and the person that you work with is also very, very different. So the conclusion I have is actually very complicated and they are a lot of challenges. On top of that, you also want it to be very inclusive. After all, you're building an open source culture in the company. It's ultimately, there's something that's involved by most people. How do you include everyone? You want everyone to be able to come, like probably, I correct that. So it's definitely why you want to contribute because you don't want to do this by yourself. It should be very transparent or the decision should be very transparent. Otherwise, it would be just, otherwise it would be very hard for you to be able to take the whole company moving to the same direction because it's not something that you can do by yourself. You also need to form a community within the company. A lot of contributors in that company is willing to help you to shift the open source program of this organization. And also ideally if there's a meritocracy decision process that we can seek for consensus, it would be ideal. Motor time is very challenging. And then to be able to do that, you want to have a very safe environment to collaborate, including, like you need to be very transparent, you want to communicate very well, you want to listen to everyone's needs and make sure that you're stressed or everyone's concerned. And of course, you want to be inclusive. And if you are doing everything and you never get everything that I just said that you're somewhat successful, you might get to the level like this. That's what we have today. We have 350 projects on GitHub. That doesn't sound like really scary, but if I put some timeline perspective, since 2012, it was our first time open source anything like that. We, on average, open source one project per week. So last week along, we opened those two huge projects on GitHub. Both are on the cloud page. And we have three community projects. So it sounds like successful, then this happens. So then, as I mentioned, there are a lot of people who try to do something. So people come to you like, hey, it's so fun. So I know that you sent out an update using some good, you know, success here. So what's the strategy here? So why are we open source so many, many projects? So how are those projects doing? How can you justify why we are doing those open source projects? What kind of value does it really bring to the company? So we have three community projects. So how big is the community actually? You know, those fun questions start coming to you when you are a little more successful. And then they actually don't ask questions like this. No way they ask questions exactly. Hey Brian, I don't think we should continue doing this because I don't think so. Or like, hey, I think hosting me that is a waste of time because you know, what do we get from that? Or some people just say, hey, I think it costs the company too much to maintain our open source project here. See, our maintainer needs to spend time talking to the community, people as a person and then give you the call. Or you know, they'll say like, hey, why do you even approve that open source project? I don't think that open source project really, you know, stand for over quality or whatever the person wanted to say. That's a very true reality that most of the open source program, office leaders, or if you're running open source program, inside of the corporation will say. In the beginning, I was very like, overwhelmed. I think, oh my God, why are people so mean to me? And like, excuse me, all those questions, like how do I handle that? And they all sound legit. Like those questions are all sound legit. Then I met this guy. Then one thing that, you know, through our collaboration, I realized one thing very important is that opinion is not bad. A lot of people leave their opinions in the company, especially when we talk about open source. A lot of people think they have, and they probably actually do have a lot of experience, but open source space is so big that you have experience of different domains. They don't actually apply across different processes. Even if you are working with infrastructure work, and comparing to the web technologies, the community probably prefers different big processes. So even if you are very, even if that person is very experienced in one job, many doesn't really apply universality when we talk about how the corporate, how the company should do things going forward. So, the fact is, how do we get the fact instead of getting barriers into all those opinions is we need a lot of data. So we do everything, we need the data, we need to analyze the data. And that's when the third job comes into the picture. Okay, I have my mic. Can you hear me? Okay, so my name is Manrique. I think I did introduce myself at the beginning. Now you know me, complicated name, sorry. I'm working on Viteria, and this is more or less part of our motto. This idea of, okay, without data, you are just another person without an opinion. We are not saying that opinions are bad, but when you have opinions based on data, probably the opinions get stronger, and you can justify them a little bit better. So basically, this is when everybody, as Brian said, you realize, okay, I need data. Our technical mindset said, oh, that's easy. Let's go fishing for data. Basically, we're using GitHub, so let's go for the GitHub API, get all the data available there. Oh, we are using other stuff, so let's start having fun getting data. This is gonna be a little bit an explanation of the typical journey that open source program offices managers, even when they hire us, run through this process. Okay, let's get data. What I should be looking at when I'm looking for data, or fishing for data, as Brian said in the beginning, mostly of the activities around contributing to existing projects or releasing my own open source projects, so let's go for then and identify the data sources I need to track. And this is where things start to become a little bit complicated, because not everything is happening in GitHub, not everything is in Git, not everything, not every contribution is coming through a Git commit. You can have people feeling issues. You can have people feeling ideas or submitting ideas through a mailing list. You can be discussing in the Slack, IRC, or whatever communication channel you are using, and those are also valuable contributions to your projects and to your process. So you need to, okay, but you still have fun getting data, so go for them. There are even tools, if you look for committee health analytics projects from the Linus Foundation, you have this open source tool like Grimoire Lab that supports around 30 different data sources, Discord, GitHub, GitHub, Vaxila, so okay, I have the tools, I have the knowledge, I have the power, so let's have fun getting data. And then you start to feel, I love this slide, start to feel okay, I'm controlling the metrics around my company. I know everything about that. You can even end with dashboards like this one, and this is a Vitergia dashboard, so you can blame us for this. This is the first step of the dashboard we built for Uber at the beginning. They hire us, they produce the dashboard, and they say, okay, we are gonna have fun with this data. And you have data around things like the community. I can see how many people are contributing in the different areas, so okay, if you look from outside, okay, it's charm, let's play with it. We have the dashboard and panel written with activity, so I can see how many projects, what's the level of activity on each project, by data source, by company, so okay, let's play with that. And also performance, I can see how people are dealing with issues, pull requests, when they are coming from my company, from outside my company, I can also see how fast are we solving issues or attending pull requests or match requests, or how many iterations are needed when closing a pull request, how many conversations do you need to have around that, okay, plenty of nice screenshots, I would say about that. But the reality is when you talk with the managers after a while, like three months or something like that, is you produce a bunch of data and they start thinking, what do I need all this data for? I have all these different panels, like 20 different panels that I can navigate through, I get lost. Because probably the strategy you are trying to achieve with that is not the right path to follow. So this is more or less the feeling that some, even some customers have at the beginning like, okay, don't talk with Vitergia in terms of okay, I can play with the data, I have data knowledge, and they start like digging into the data and get lost about the value of the data itself in terms of that. So, I usually take this quote from Sun Tzu about the strategy and tactics. You need both to be in place. Probably tactics are like, okay, let's go for the data, it's a good one, but you need to start with the strategy. What I want to achieve with all my open source pro-anophys, what I want to achieve as a company when I am releasing open source, what I am trying to achieve when I am contributing to projects that I depend on. And those questions are the first step. So, we take something similar to the Deming Circle approach that basically says, how is the OSPO when you are running analytics path? So first of all, you need to start with a strategy, as I said. Like, there could be different goals that you are trying to achieve when you are running an open source pro-anophys. Probably it's about transparency. I want to show to the communities outside, to the developers, hey, I am doing this. I am doing this open source thing. So, come to me, we are charming, we are welcoming people. Also, it's about self-awareness. It's like, okay, I need to know where I am, because I need to lead a change at some point I need to know where I'm starting. And I have some experience like people discussing, okay, let's put Gary to do core review, because we are gonna be faster doing core review. And I ask, how fast are you now? We are slow. We are gonna be faster with Gary. Okay, but how much slower are you now? We are slow. Okay, give me a number, because if you don't have that number, how do you know that you are improving? Okay, you have a new tool. Nice, cool. You are cooler in the player, but you know. Also, when you are policies, when you have policies to deal with, say, okay, to do this, you need to go to Baxila, Filanesio, then start a discussion, you can test if those policies are the ones being put in place in reality. Because probably you can, Brian said you put a lot of processes, but the truth is the community and the projects are behaving differently. So you need to adapt your processes and your governance to that. And also, it could be also motivational. And we know a lot of people looking for data just to say, and the number one on whatever, area of the project, because I want to say that to my marketing people, because I'm going to be in this whatever conference to say, hey, we are the top contributors to whatever area of the project. And I'm sure, statistics are able to say to you that in whatever area of the project, because we are used to play with that data a lot. And it's like, you can always find like, in the last week, in the last month, in whatever area, in core review, in answering questions, you can always say that. Many people are using, or half of my strategy around, okay, I need to attract talent. And we know some companies that move to the open source ecosystem just to say, we are cool, so please send us a CV so we can see how many people are contributing, people from outside the company, oh, they are contributing with this quality of code, probably they are interesting for us, and things like that. So that's an approach of having a strategy. I will have tried to do some kind of exercise of putting at least two goals, two typical goals like, okay, I would like to, in my company, to have worldwide talent attraction. I need people to see, okay, this company is cool to send my CV or my resume to work for them because they are doing this open source thing. And also, it's a charming company, it's perceived as this company is cool, they're having this fun around open source, they have been in these conferences. So those are goals I would like to achieve. That is also like dividing into the typical worldwide domination or the worldwide leadership for a company. I would like to achieve. Okay, the next point is, okay, you have these goals clear, right? So now, even in your own company, I'm sure you have a goal or a motto saying we are gonna be in five years this thing. So the next thing is, put that goals into questions that could be solved or at least answered with numbers. So basically, you can go answering, having questions about the community or about activity or that performance. Typical things about that. So in the same exercise, for example, some questions related with the goals could be something like where contributors are coming from. Where are the people? If I want worldwide contributors, I will be able to look at goal-wide contributions. How much engagement do my projects get when I release them? Because if it's only my people contributing to them, what's the difference between having them as open source project or not? Typical question, what do we are releasing this as an open source project? How many new contributors do I have? So I need to identify how many people from outside my company are contributing to these projects. Because again, if it's only my company, what's the goal of being open source on that? Things like how many core, regular, casual contributors are in the project, even how people are changing between these buckets. And when I'm talking about core, I don't know how many of you know about the bus factor, this idea of how many people you need to put in a bus and throw through whatever they have to give the project or to hire or to buy to control the project. So the core developers could be like, people doing 80% of the contributions, for example. In whatever area of the project, I mean, could be it, it could be mailing list, it could be answering questions stuck over flow. It could be also the regular people, the people that is doing 15% of the contributions, for example. And the casual ones, those are doing, for example, 5% of the contributions on a specific period of time. And you can see also the evolution of the time. It could be interesting to answer those questions. And of course, how I am dealing with external contributions. When someone from outside is sending me a pull request, I am being fair with them? Well, just no, no. My boss said, look at our pull request first. And then you could have time to look at other one's pull request. And you know that usually that's how it ends. You don't have time for anyone from outside. But again, if you want to be a charming company or a welcoming company, you can look at that kind of questions to be thought of. So next part is, I would say, development or customization. It depends a lot of the companies. And we know several examples like, as I said before, usually big companies think, OK, I have the manpower capabilities or whatever to build these front scratch. So I am going to build a solution for doing this. Or I can go outside and see which other tools are out of there or even hire someone to provide this data to me. But at the end, you need to customize that at some point to provide those answers. Because usually, you go outside and there are tools everywhere. As I mentioned before, there are others that probably are developed by a community. But they are developed probably for the needs of the community. So for example, they are supporting only the tools that the community is using and things like that. So my recommendation is, usually, don't start from scratch. There are communities outside, or projects outside, the community health analytics for open source software from the Linux Foundation. I will mention that later. That is hosting several projects to do that. There are also tools available. So try to reduce existing tools. And if you find issues and pull requests, I ensure that, I mean, you could see improvements. You can send pull requests to them. And usually, you get this, don't go alone. If you want to be fast, go alone. If you want to be farther, go with someone. That would help a lot in this area. For example, OK, let's look at the tools. And I'm biased here, because we are one of the main contributors to Green War Lab. But as I said, OK, it supports almost 30% of the data sources. It has some panels, as I've shown before, predefined to answer some questions. Also, there is a tool to manage the multi-identity of the people across the different data sources, even inside the same data source. You know, you can contribute using, for example, two mail addresses. And what does it mean? Due to people contributing, one people, it depends on the project itself. Also, it has a REST API to consume the data. So if it needs to be integrated with the company on tools, business intelligence tools, people say, OK, that's going to be fun, because we have the power to do that. And of course, it's 100 free open source hours, free Libre open source hours. So OK, let's go for it. And then, when it comes to reporting. OK, I have everything on place. I have the questions. I have the goals. And now I have these people, as Brian said, asking me questions. So I need a reporting system that should be consistent. And I said, if you are contributing, for example, to CNCF projects, you will be looking at DevStats. And if you are contributing to OpenStack, probably you are looking at stack-alities. And then you start, OK, I have two different ways to look at the data, but my manager only needs a PDF reading its month, for example. How to do that? So the idea of customizing this to produce a uniform system that allows me even answer, like, I need to go deeper. And I will show some examples later. It's a good way. And the other thing is transparency matters. If you release something like this internally, it's going to be OK. From the perspective, OK, I can see not only how that we are doing open source. We are also able to see how we are performing doing open source. If you release this externally, you're also saying to the people in the communities, this is not only our open source project. This is also how we are developing open source projects, how we are dealing with you when you are contributing back, and things like that. OK, so these are some, for example, answers to these questions. And I would try to call them metrics or insights, for example. And this is also for newer use cases. Where are contributors are coming from? And when we release this panel with the map, there are data sources that you have information from geographical information. And you have, for example, any meetup. They have this information, so you can see what contributors are happening. And we were talking about this yesterday, what do you think about when you see this panel? What changed in the company? I think that. So taking away from this here, what we decided to do internally and then, if you can see, most contributors are from the Mississippi area. So for me, when I look at it, I kind of failed doing my job. Because we have 12, 13 overs across the world. Why all the contribution is from Mississippi? So I talked into the data, and it turns out, 99% of the open source projects were created in the Bay Area. And I look into it deeper, actually, just more to them, because there are some, some offices, they just don't have in the engineering to mentor them to do those activities. Or they would not assign the projects that, probably, they think it's interesting to create a layer of wouldn't use technology. Some offices, they don't even know that I'm writing here. They don't even know why. So it actually helped me, it guided me to, again, I had to start looking at what's going on within the company. It cannot be a take-quarter kind of centric program. Otherwise, it's not going to scale, and, you know, people, it's not, they were still against my goals. I wanted to be, you know, globally available to anyone. I can, if you want to know, I was a staff, and I was there, and I wanted to talk to you about what I have to share with you. This is one example, but some data sources, I mean, some areas of the contribution, you don't have that geographical information, but, for example, you can also have time zone information. So, again, it's another way to see where contributors are coming from. Probably, it's this size of the wall, but at least you can guess what's going on there also about that. Another interesting question is how much engagement do my projects get? And this is an example of how many active repositories is Uber nowadays maintaining, and the evolution over time. So, okay, it's like three, five, three 50 projects around there, but if you look at the numbers, only half of them are active. And you can also see how many activities from outside Uber, because also, as I said before, this is only a project with Uber activity, what's the difference between having this open source or not? I mean, from a manager perspective, it's okay if we are dealing with this in an open source way, it's nice in terms of transparency, but this is the same revenue if I have it inside my office, for example. Okay, so, a potential next question would be how many new contributors do I have? And this is evolution over time in these contributions, I think, so you can also see how many people from outside is coming. And I would like to show you this slide, because this is not my laptop, so blame me if I broke something for you, Brian. Okay, so this uf.bitter.io, as I said before, you can play with it, you can play with the data, and we have here the data sources, probably the menu is gonna change in next week. This is for community, you can see the demographics of the community for the last, okay? So if you go this, you can see how many people is joining all the projects I have, and how many people is leaving. I mean, not active anymore. So you can have the demographic of your community in that area. Of course, the last two bars probably are the last three or one month, I think, so probably they are still active, but it gives you idea of the trend around your projects. And as I said before, you can have some fans here, like, for example, let's add a filter, like the out, or this is where the magic happens. I mean, it's easier if I go to organization. Outer name is not your boom. You have there all the contributions from outside Uber coming to the projects, and the trends are quite similar. So again, but you can also keep having fun with the data, and this is where our technical mindset starts to get lost, oh, I wanna apply with this. So let's see what happened, I don't know. Here, for example, August 2014, I can click there, and I can see the pattern of the people not getting active anymore. And it looks like, okay, people do a contribution during the next one month, and then they leave. But there is some people doing things like a couple of months ago, right? So if we click there, we have Michael's free list that has done some contributions lately. And Michael is working in Salesforce as far as I know. So basically you can say to your manager, okay, this is the value of going up and sourcing tests. This is like signing up a partnership with an external company contributing to my projects without dealing with all the bureaucracy of doing that partnership. It's just going up and sour the data, we have these people, and it's still active in my community, having this engagement. This is, again, is one example of the things you can do here. I think if I go back to percent, this is gonna be presented. Okay. The contributions, how many people are doing 50% of the contributions? And you see, big bars are the people doing the 5% contribution, more or less. So most of the contributors are our contributors. Yeah, I think so. I need to check the, yeah, that's it. And usually that, usually it's aligned with this Pareto idea of, I don't know if the Pareto balance between 20% of the people do 80% of the work. So you can compare with that, for example. And you can see how it's evolving that. And the last question, for example, is how fast are we dealing with external contributions? As I said before, you can filter, but I'm going to show you again, a life example, because you're not gonna see that easily there. So this is more or less the efficiency panel about Github issues, I think. Yeah, that's it. So basically there you have information about the, in those charts, it's more about the evolution over time in things like how many, the relationship between issues open and issues close, sorry, issues close versus issues open by mom. So you can see a trend there about how we are dealing with that work effort. And also the lead timing, that's how far, how the house develops time to close issues from time to open to time to close. That's more or less what it says. And I'm going to look at this number here. That says the median time to close issues for all the projects. So basically it's around six days, but we can go and say, let's look at, okay, I think I can do this. You will apply, okay. You are over the median, but let's look for the pull request, but you can do the same thing for pull request. You can go here, you go to efficiency, for the last year, for example. And there, they are quite fast solving issues. Sorry, we're closing pull request. Let's look for you, okay. It's around five, six hours to close a pull request. You can see, okay, last year, what this was, what the year before, what was the value of year before. Okay, it's almost the same. So we are stable on that point. But let's do the other way around. Well, how fast are we solving issues not from Uber? One and a half day for the last year. Is that a good or bad number? I will ask you from the manager perspective, it depends, I think. But at least you can see, okay, if we want to improve this, we know now the numbers. We know that we are this when we are dealing with our own issues. And this is our number when we are dealing with pull request from outside. And we can see how was one year ago. Okay, it's going stable, but not that good because it was faster last period of time. But again, this is the way you can discuss with your manager about what should be doing next based on our strategy. And now you have numbers to say this. And again, you can go each of the projects on the rise so you can filter by each individual projects and stuff like that. I'm going back to the presentation. I don't know how we are on time. I can see it. So basically, you're seeing all the path. The other big issue from my point of view on our experience is you need to be reviewing this periodically. Because once you put metrics on place in front of the people, people are gonna try to cheat the metrics and you know that. It's like, okay, if we are gonna be aware or awarded or whatever or rewarded, we are gonna be to see how to cheat that metrics at some point that our contributions are gonna be faster or things like that. But on the other way around, if, sorry, on the other side, this can be used to change patterns. As you see, it's when you're trying to get fitness and things like that, it's like they don't say to you, okay, go to the marathon from the day one. You start by looking, making small steps. So you can use the metrics to start changing patterns in your company. Like, okay, I want people to attend more to the issues from outside the company. So let's put that metric on front in the dashboard. So when my people go to the dashboard or to the airports, I mean the last word, but it could be the reports used into the managers, they say, okay, I need to improve this. So the next time I have a full request, probably I'm gonna look first for the people from outside instead for the people from inside because, okay, this is something I can manage at some point. And then once you see that the pattern is changing, remove that metric and put other one in place to make people go to the next step. Like, okay, we are seeing that you are closing mercenaries faster, but the number of iterations with the people, we are not getting out, we are getting bad responses for the community outside because they are doing minus one in the pool reviews or things like that. So again, you can become a pattern changing in your company times to this. And as I said before, this is not something that we invented. I mean, there's a community around these topics discussing about this, this is Chaos Community. Chaos stands for Community Health Analytics for Open Source Software. I know the name is quite aligned with the work being done in there, it's a lot of chaos, I would say. It was set by the Linus Foundation, I think one year and a half ago in the Open Source Summit in Los Angeles actually, so it was, this is the second time in Los Angeles to talk about this. And Grimoire Law, for example, the tool I've been showing you how to make this dashboard is one of the foundation projects of this initiative. And just to talk a little bit about the initiative, the initiative is divided in two committees. There is one committee focused on defining metrics in terms of what are the metrics that Open Source projects, I wouldn't say should be looking at, but at least at some point, the metrics that people are looking at when they are talking about health. Things like engagement, things like diversity, and then there are several, inside each committee, there are several working groups. There's a diversity working group, there is a growth, maturity, and decline working group focused on metrics related with the topic, there is a risk committee working group, sorry. And that's the, I would say the more academic group. Out of academics, they are discussing about metrics, how to formalize the process to release them. And then there is a committee focused on technology in terms of software that could be the one implemented the metrics defined in the metrics committee. In terms of, okay, there are tools outside, they can be contributed to the project, they need to be at some point integrated. And Grimoire Law is one of them. There are also CRE-HIT, I don't know if you know about it, it's used for Linux kernel analysis, it's not used remotely, but it could be used to analyze any JIT at the token level. I mean, there's not just line by line, but in terms of, okay, this function with the author of the function, how many things this function has had, and stuff like that. There is also a work from the University of Illinois, I think. I don't remember exactly the university, which one. Danny, I don't know if you know better than me, but I know if it's Mississippi or Illinois or whatever. It's one of the universities contributing to the project. I would say PetProject is evolving quite interestingly about how to get data from JIT Hub mostly and produce some metrics as reference. And the other one is Prospector, that was submitted by Red Hat when the group was founded. I think there is no activity around the project, but this is also a very interesting one about how to create reports about what's going on the project based on some kind of model of maturity or something like that. So those most, there's some mailing lists happening there and stuff like that. This is more of your part. So the motion is like open source project, which are best to contain the up to date and give you the best quality as you can. This also, the open source account you can find in the interview, so you do have open source project from machine learning, AI, the structure of mobile, basically the whole technology stuff. Look at it, if you find anything that fits your needs, you can use it. If you encounter any trouble working with any project, you can contact me and we'll talk about that. So you can also contact us if you find any way that we can collaborate. If you're open to Q&A, any questions for us? Yeah, actually we wanted to have some kind of open discussion at the end or some minutes too. If you're already running some kind of open source pro-annoufice or you're running this kind of infrastructure in your own company, well, what are your questions or your feelings about this? Okay, you have a question? Tell me your goals with the idea of open source or don't think there's people or companies who are hostile to open source. What, from all this information, do they find persuasive that yes, our company having these programs is valuable to the company? So we need to repeat the questions for the recording. Basically, if I have understood it, which are the metrics or reports that are most valuable for people that usually, I would say they are not that in favor of doing open source or to see what's the value of doing this stuff, right? I don't know if you want to ask from your own perspective, from your own personal opinion, and then I can give mine. My experience is, don't say that you need to come with someone that don't want to be doing this. So I'm using the other question is, do we have a company-wide goal or why we are doing this? Now we need to present the focus in the data. My experience is, at minimum, they go from showing data and then I forgot that actually we don't have a concept of how we are doing this. And also, the data also needs to be distributed to how to find it, how to find it, how to find it, and down. So why are we doing out-down, like contributing to the open source project-wide? Do we want to get just branding, hiring, or do we generally believe that it's a good thing to do or is it a good for our business? Like someone that's like, is that your father has a question before we show data? But I do believe that for most of the skeptical people in a company, they will come to you with a very strong opinion and you can usually tackle with the free-style data. For example, if someone comes in, I believe that also open source projects hurting our brand name. Okay, let's look at how our brand is great awareness of the media and hiring, you know, racial, those are the same TV too, the crazy things that are there. But if the people or the person that has the question of the executive sponsor, then it would be a bit trickier for you to handle. Did I answer your question? From our perspective, I didn't know if you want to add something. No. No, okay. No problem. Okay, from our experience, one of the things that has worked instead of being valuable is, first of all, metrics related with contributions from outside the projects from my own company. Because this one, you can say to the managers or to the people that is skeptical about this is, okay, you see we are getting contributions from outside without doing a bunch of hiring or whatever, but usually that is related with the objective or the target of the company itself. For example, there is, there was a, I think the video of the talk is online, there was an example in Samsung, they are contributing to several user interface projects, like with graphics and kernel and things like that. They are using similar tools to measure this kind of stuff. And the managers say this is the slide I used to convince my manager for getting more money. And the only thing that he worries about is, why these Arianex more money or more people or more resources to contribute to, is because if we contribute upstream, upstream projects are gonna be earliest integrated in my technology, I'm gonna support my technology faster that if I go only inside my computer, forking the project and doing it by myself. So that was one good example. And I don't remember now many of those, but those are the typical examples I have. The slide side avoidable on the scale X, scale 70 X side, so you can go for them. Thank you very much for coming this morning. Thank you. Thank you. Okay. A lot of noise. We are live, it's awfully close. Is that okay, or am I now overwhelming the back of the room? We're still good? Okay, good. Come back in your pocket before you forget it. Glasses back in your pocket. Okay, I am gonna get going just to be respectful for everybody's time. So, my name's Steve Wally. I have been around the open source industry for almost 30 years now. I've been working for 40 basically. And so I've built up opinions because a lot of what I learned about building product out of these interesting buckets of technology on the internet, I learned before we ever called it open source. I kind of grew up in the Unix and Usenix community where we were collaborating on software all the time and that's to a certain extent just the way you did things. I have, presently I am a principal program manager. I work in the Azure office of the CTO. So yes, I work at Microsoft. I was at Microsoft 99 to 2004. It was an interesting period because I was part of an asset acquisition where we brought a product called InterX which was the Unix face on Windows NT. We got acquired into Microsoft. And I built that product out of a lot of open source including GPL software that continued to be shipped by Microsoft. And it was a tightly kernel integrated product. That's why we ended up at Microsoft in the acquisition as a failing startup. But that means I was the first guy shipping GPL software to Microsoft back in 1999. And so I've been around these things for a long time and I have some very kind of product engineering centric views on a lot of this stuff. I left Microsoft in 2004. I did lots of interesting things for 12 years and I came back two years ago. And working in Azure is, so I run around basically saying that open source software is about engineering economics. That to me is kind of fundamentally what this is all about. That's why it works. And because of that I fundamentally believe that there is no open source business model. It's not about the business. Now we're gonna talk about business here. I'm gonna also talk about economics. And so my goal today is to convince you of a number of things. That it's all about the economics and engineering. It has nothing to do with business per se. In fact there's certain business things you need to know about if you're gonna go step into an open source world thinking that you're gonna use open source in your business. And then the last thing that I'm regularly known for is freeloaders means you're doing it right. We're seeing a lot of the sustainability debates. Our folks that are very concerned about all these freeloaders in the community. And you'll see it from two different directions. You'll see it from, often it's not a community around an open source project. It might be a developer or two. And they really are drowning under the load. And they don't know how to think about that or act on it or talk about it. And the other side is if you end up with a business and presumably one with a lot of investors and they're doing things with open source, they think, but we're giving the customer all this stuff for free. They gotta give us something back. And so that's where really it is one of these situations where it's all about freeloaders means you're doing it right. So these are the things I hope to convince you of over the next. So open source software is about engineering economics. And what that really means is that collaboratively developed, liberally licensed software is all about engineering economics. And people try and point back at the open source definition. A quick question actually, is the bit of feedback you kind of scratchy off this, is it really bothersome? Do you want me to switch, Mike? The thing to understand is we have been collaborated on and we do that because writing good software is hard work. And so I can bore you with stories that go literally back to the Institute of Advanced Studies in Von Neumann working on the original programmable computer in America. But if you even back off of that original kind of research, IBM ran a conference for software developers in the 50s and it was called SHARE. It was deacon in the 60s with the rise of deck equipment. USENIX came into its kind of existence in the 70s. We've been collaborating on software. By the time I started working in 1980, that was the year that the US Congress applied copyright law to computer software. So this creates a number of problems for lots of us. But there was a period where still going to DECA conferences in the 80s, you could show up with $70, which was a lot of money back in the 70s, or a mag tape full of software that people in your community in the DECA world had built. Like we've been collaborating on software just forever because writing good software, writing useful software and honing it into the kinds of artifacts that we use every day and care about and trust is hard work. But 1980 and that application of copyright, it created problems. All of a sudden, you would have to ask my permission to use my software. The whole problem's derivative starts to flow into this. And so for 20 years, we start experimenting with licensing regimes that allow us to continue to collaborate the way we've always collaborated. So you see, I mean, this is the period of history when Stolman articulates software freedom for the first time in 85 and the Free Software Foundation comes into existence. MIT and Project Athena, Athena, that's X11, Kerberoff. These are things that, it was DEC, IBM and HP, and a host of other companies came together in MIT to create X11. And again, they needed a sharing license. So you see the rise of the MIT license. The folks at University of California, Berkeley, they're sitting there with BSD, they basically do the same thing. You've got universities writing licenses to allow collaboration to continue to happen. The first license that sort of looks corporatey is Netscape decides to do their open source thing and publish Mozilla. And so you see a license that suddenly no longer looks like the simple licenses or the political manifesto of the GPL, you see something that suddenly looks like a corporate license. But the culmination of all of this is you end up with the rollup after 18 years of experimentation with the open source definition. So at this point, we're still just trucking along, right? We've been developing software for almost 50 years at this point, we now have a definition that seems to be this working definition and it's worked well for us for 20 years now. I am a big fan of the open source definition in its current form. I think that's an important thing to understand. It is 10 tenants of a license. The attributes of a license. And these are the things that we learned in that 18 years of experimentation that creates the broadest surface area for engineers to collaborate in. Yes, yes, yes, I know they're being written by lawyers, but when you think about what it means to us as developers in the room collaborating on software, it's these are the attributes of the license that give us the broadest surface for collaboration. Now, I worked for the company that invented the term shared source. I was in the room when they did that and it was a horrible, horrible idea. And it proved to be. And the company walked away from that. And right now what you're seeing is a lot of folks coming back into this idea that we need, we want sharing and collaboration, but I wanna make money. Okay, well, don't put an open source license on us. And we'll talk some more about that when we get to the business side of it. When you put a license on your software, we are developers, we are not lawyers. So what you're really saying is this is the social contract under which we are willing to collaborate. And that's why when you, even the, you know, GPLv2 is still not an overly complex thing. It says these are the expectations of working together as engineers in this collaborative environment. It's the social contract support. That's where I keep coming back to this idea, collaboratively developed and liberally licensed. Of course, engineers try to be marketing people and we called it open source. But that's what it is. And it's all about engineering economics. And what I wanna give you is kind of the first time I really walked through the education of this in my own product space. Inric, this idea of a Unix space on NT, we were fully kernel integrated. We were using 4.4 BSD light as our code base to bring the shell and utilities on top of that environment subsystem so that we had a clean code base. And we knew we could use 4.4 BSD light because AT&T's lawyers said we could. That was after the lawsuit, which crushed the FBI. So we step into that space, but what we realized is we need control of our own compilers because this is the late 90s. Windows NT runs on Intel, Jack Alpha. And so it's not enough, like for us, we are living on the Microsoft compiler and our own headers at that time, but we actually needed to do other things. And in stepping into that space and meeting other things, well, I can't just, the Intel compiler was probably the best C compiler out there. But I'm a startup. I do not have this kind of licensing money and that's only gonna solve one chip set. There's this interesting, relatively new community still. It's a growing community for GCC. So we step into the GCC space. GCC is, at that point in history, with about 750,000 lines of code. And before anybody wants to challenge me on lines of code, I was an engineer. I understand it's a terrible, terrible thing to use lines of code. It's an interesting, relative measure for this discussion. So, bear with me. So 750,000 lines of code. If you did a COCA mole calculation on it is about $10 million, depending on the multiplier you want to throw in there. You could claim 20 million, but let's claim 10 because we're playing with numbers and we want to keep it easy. I hire a compiler veteran. 20 years of experience of compilers on operating systems. And, again, late 1990s. I can hire him for under $100,000. And by the time you add in testing and shimming and fit and finish on the product, for about $100,000 over that next year, I've captured $10 million worth of value. And I now have control of my view of my compiler chain. As an engineering manager, I will tell you I'm very excited because that's two orders of magnitude of value capture. But now, the unfortunate part is we're living on an expensive fork. And nobody wants to live on a fork because forks are brittle. Software is amazingly dynamic. Copyright is a stupid idea. It is not a book. And so we end up in the space of how do we get our changes back? Well, we all know how the open source community works. We just contribute upstream, right? Well, working on compilers is a reasonably complex problem. And even though I had a very experienced compiler veteran with lots of chipset experience, it turns out there's actually five communities hiding inside the GCC community. And some of those communities loved our changes. I've clearly hired a good engineer. Some of them took the attitude of you're working on that Microsoft shit, get away from us. Not exactly the best technical feedback, but this is the kind of thing, we have a coherent set of changes across five projects that need to happen. And this is the kind of bumpy ride we're going through. So I went to Cygnus Solutions, Cygnus Systems, sorry, because Cygnus was the preeminent compiler, GCC compiler engineers of the day. And they said, yeah, we will happily get all your stuff upstream. It'll cost $120,000 and we can start in 14 months. Again, I'm a startup. I really didn't wanna spend that kind of money at this point on the other $100,000, but there is a company called A to Core Technology. And they are also committers in GCC. And they'll do the job for $40,000 and they can start next month. So I hired good engineers in the upstream commit space to get all of our changes coherently. And this is not I paid for the changes. Don't be misunderstanding that somehow, some company paid somebody to put their changes in. No, no, these were upstream committers with their responsibility being first and foremost to the project. So whatever editing they took on to get the stuff incoherently in a GCC project enabled kind of manner was done for the money. But now I've spent $140,000. Thing is, GCC has not been standing still. In the year from when we started and then the other half year before them to get everything upstream, GCC is now a million two lines of code. So that value capture is growing in our favor. And not only that, now that we've actually got all of our stuff at head rev, we figure the back of the envelope for the next major releases means that we've got about a month of fit and finish work to do to pull our stuff. So, you know, we're down to, if I had the laser pointer, we're down to just a little $10,000 kind of thing on $10 million. So I'm now at three orders of magnitude of value capture kind of playing the game going forward. So this is why I'm excited about participating in open source as an engineer building product because this gives me time to market. This gives me solid engineering and I have to commit upstream. And this is not out of altruism. Software gets incredibly brittle incredibly quickly. Software is amazingly dynamic. I need my changes upstream. Otherwise I'm living on this very brittle and expensive form. And so that's the engineering economics of open source. And it's something that, you know, when you actually step back instead of doing it by the numbers, I just like, every engineering manager, I don't care whether you live in a product world or if you live in IT, every one of us understands the build versus buy discussion. When you add open source into the mix, you get four-owned share. It gives you more optionality in how you're going to make your engineering decisions forward. And when you're capturing certain engineering here, it just makes sense. Why would you, you could go buy a web server or you could write a web server or you could pull this very battle hardened web server and maybe make some small changes, maybe use it as is, maybe pay somebody for some of the small engineering around the edges. But it just makes so much more sense to live in that space. So that to me is open source software is about engineering economics. So that's the basis of that argument that's always been in my head. And I've gone into this debate with lots of folks from lots of other companies and they always try to say, yeah, but really there's still some experimental business models and, you know, there's some creative stuff out there. And it's nice that it's about the economics, but really there is a business model. So let's talk about software business. And I want you to firmly take your open source hat software and we're just talking about software. And that is actually a pet peeve of mine with so many of these discussions is people want to wrap something up as an open source discussion and it's not an open source software discussion that's a software discussion. So let's talk about software business first and foremost. Anybody know who these guys are? So the gentleman on the right is Jeffrey Muir. He is the man that back in 1991 wrote Crossing the Chasm. So the big aha observation was in the technology adoption life cycle, you get to this point between the early adopters and the early majority, that there is a gap in the continuity of people adopting your software product. And so, you know, joyfully called it the chasm. Technically, I lost Inderix in the chasm. So I know exactly what the chasm looks like and what it feels like. What it looks like is you're sitting in front of the CIO of Bear Stearns and you've just had a great meeting with the CIO and their chief architects and they have used your product and they love it. I know that Inderix solves the fundamental problem of how do you get all of your UNIX application code onto Windows NT in a few days and have it behave with fidelity? I look static. And is it all of the architects leave the room and the CIO looks at me and he says, so how many people are you? I said, he says, wow, you've got to be having a hard time breaking onto Wall Street. Yeah. He said, I can't buy from you. And I'm looking, the penny hasn't dropped for me yet because I'm sitting here. The man's senior architect of all just told me how wonderful my product is, but he is not going to bet his mission critical move of all of their business applications onto an unproven operating system called Windows NT on the backs of a 50 person startup. Not gonna happen. That's what the chasm is. And it's an awful feeling. So there's, the book comes up with a whole lot of strategies about how to think about it. But the basic thing, the language that Jeffrey Moore brought into this world kind of over the next 20 years of writing that he did, it takes you into this place that if your core competency as a company is delivering software, then that software really falls into three buckets. It is your core value proposition to your customer or it's compliment value add. Because here there's that idea that the company that provides the best whole product solution, so the core value proposition and all of its compliments is typically the winner in a market. So you can either be writing core value or you can be writing compliment value add or it's context. It's Netflix publishing Spinnaker or Chaos Monkey. You know, Netflix is a great company for just spinning off context stuff. There is nothing about Chaos Monkey or Spinnaker that has anything to do with their core competency of delivering video entertainment streaming to your devices. So it's context. If we step into this other guy's world, this is Clayton Christensen. He is the guy that gave us the innovator's dilemma. And he wrote that in 97 and it kind of took the business world by storm. The a-ha for him, and it was really fun if you ever got to listen to a Clayton Christensen talk back in that early naughties period, was he would explain to you that everybody was talking about disruptive technology. And he'd given this talk at Intel and it was actually Andy Grove came over to him afterwards and said it's not really disruptive technology, it's a disruptive business model. And the heart of the observation for him in this whole space and he didn't just do around software, he did it across software, hardware, pneumatics, cranes, disk drives. He walked across a whole number of disparate industries and demonstrated that the innovator's dilemma is real. And what it basically means is it's not somebody out innovating you on the cutting edge. It's somebody comes along and solves a slightly different problem with off-the-shelf cheaper parts. Think about the PC. I don't know that there's enough gray hair in this room to remember when the PC kind of really showed up and took off with the IBM PC in the middle 80s. But like, I was already working and I worked on real computers and that PC was a toy. And now we walk around with iPhones, you know, we are all cyborgs with exo-brains that are in our pockets kind of thing, you know? It's understanding that there's a way that technology enters the marketplace that's different. And so he ends up in his second book and I'm not gonna walk you through the pain of all of this. The slides will be published, but to give you a flavor for it, there's new market disruptions and there's low-end market disruptions. So low-end market disruptions, you've got a newer, cheaper disk drive, but it doesn't hold nearly as much information as the other thing. And so that's what we saw as we walked through spinning platters to five and a quarter inch floppies to three and a half inch floppies. All of a sudden, you walk your way down, they came up with a one-inch drive. Apparently it was, yeah, we would never want one of these one-inch drives anywhere near our computers, even our laptops. But it turns out, heart monitors could deal with how slow they were and the rest of it. So all of a sudden, there's a market and once there's a market, the innovation starts to decline. And so they start getting better and better and faster and faster and smaller and better. And so you end up in this innovation cycle once the market exists. So that's kind of the low-end market. New markets, you do something that nobody's ever been able to do before. And you tap a need. So when you start thinking about the iPod, you all kind of looked at the iPod and we all thought, why, I really wish I bought Apple stock back then. You know, and it's one of those things that you park your stuff on a need that otherwise people had to do something awkward. And so there's a set of questions that are kind of litmus tests that you walk your way through if you've got a new business. So this idea, my favorite company we all laugh at from Silicon Valley is Juicero. You know, how can we make juice more expensive for people and less convenient? But somebody had the harebrained idea, but I'm pretty sure if they had to walk through the questions as litmus tests, they might have realized, maybe this isn't a good idea. And there's a company I saw the announcement the other day. And it's basically, you walk into the house, you've got your dirty shoes on, and you step onto this footprint and a section wrap, a piece of plastic around your foot. You do not leave muddy footprints in the house. So they've now created a wasteful, expensive device to replace taking your shoes off. You know, it's like, you need to apply some very simple business logic. There's lots of smart business people out there that have been thinking their way through these kind of innovation problems for a long time now. And just like you need to not reinvent the technology all the time, you need to not reinvent the business models all the time. So let's walk back a little bit through some of the Jeffrey Moore stuff. If your core competency is delivering software, your software is either the core value proposition, complement value add, or context. Let's talk about open source for a minute. If you're building a project community in the context space, this is Spinnaker from Netflix. This is a great thing to do. You know, if you go and talk to the Netflix open source engineering team, you know, they've been using it for hiring, it validated their approach to the problem set. You know, it's a demonstration of committed engineering values. It's a demonstration of engineering prowess in the market. You can publish all this stuff. There's nothing hidden here that's going to, you know, help somebody else build a better Netflix. So this is an easy one. If you're publishing open source software in the context space, party on. If you're building project community in the complement value add space, I'm still a huge fan of this. You're creating stickiness because it's a stickiness of the complement that matches the core. It's, you're playing with your margin game. You're creating experts in your base technology. And so there's a, you're hardening the complements and that's an indirect value back onto the core value proposition. You're actually capturing the direct value into the complement space. If you look at something like Helm, which is something of one of Microsoft's projects, Helm complements the Kubernetes space nicely. So we're getting the direct benefit to the Helm project for all the stuff that flows in, for all the contribution flow because we're managing that community reasonably well. But we also get that that flows back to the Kubernetes community indirectly. And then we pull from the Kubernetes community for AKF and Google pulls for GKE and stuff like that. So again, you're getting this indirect benefit, but it's still a measurable benefit. And it could still be a little bit disruptive on competitors. Here's the but. When you publish your core value proposition as an open source project, you gotta be really careful about, you need to understand what business you're in. You need to think about it really carefully. So this is Docker. This is MongoDB. This is Redis Labs. This is folks that have taken their core value proposition to their customer and they've said, hey, here's an open source project. And they have published it under an open source. Docker built a vibrant community, the whole Docker captains program and everything else. They spent a lot of time and effort building that community. And if you're investing in building that community, you start to run into a set of problems you're certainly creating tension in your own product space because hey, it's an open source licensure. Competitors are happily coming in there to help you. And they may not even be direct competitors. They may just be people that see the marketplace different than you do. They're creating a slightly different value proposition and they want to contribute. The power of that innovation capture, the kind of thing I gave you the reverse direction with what I was capturing in the GCC community of orders of magnitude. But if you reverse that, though, you start to run into this problem where you're diluting your core message, your core value proposition to your customer because all of this other stuff is coming in and you gotta be careful about what changes you accept. Especially if they start to do, if your community starts to do really interesting stuff with your software, that's great. But if it's diluting your message about what your core value message and proposition to your customer is, that's less great. Then you're salarying the, if you create a community, if you go back to crossing the chasm, what Moore was talking about was early adopting customers, not early adopting users. And I suspect a lot of Silicon Valley VCs and a lot of Silicon Valley CEOs have made the mistake that they thought, well, we're gonna capture a whole lot of users and then we'll figure out the business case and we'll monetize it. And the problem is those early adopting users in your community are the very, the smartest people around that are interested in this problem. And you've just given them the tool set to work with you and not do you anything. These are not early adopting customers that you can start to tune a business model and maybe pivot with. These people are actually solving their problem without giving you money. You don't have the feedback loop. And so this is the problem. And so the way I keep trying to reduce this down to simple messages for people. Projects are not products. This is the other boring one. I have friends in the back of the room that have seen this talk before and never heard me rant about this. Projects are not products. I will fight you on this. I have had to fight Google on this before because we will talk about the Google example, but I have been in a room full of smart engineers from Google that want to tell me that Kubernetes is a product and they're wrong. And I will tell you why in a minute. The other thing is your community is not your customer. So why is it like, how do we get to those? So projects are these interesting buckets of technology. They've been developed collaboratively by like-minded engineers that are liberally licensed. That's what that's what our project is. Products solve customer problems and money is exchanged around perceived value. This is a different discussion entirely. And so you can be a company that does open source really, really, really well and your marketing people can even be the people having these discussions, but they need to understand that there are two discussions to have and one is community facing and one is customer facing. These are different. Projects have communities and communities have time and no money. This observation does not come from me. This observation comes from Martin Mikos who was the CEO that grew my SQL and then sold the company to Sun. And that was his huge observation is, hang on, I've got all these community people and I have nothing to sell them. They have no money to buy a solution from me, but they're incredibly valuable and sticky as a community. Customers have money and no time. I just need a solution. I wanna buy something. I wanna buy something that I don't have to worry about it. And so that's the dichotomy you're looking for. We can talk about an observation that I've had in the past about, you'll hear people talk about conversion ratios. I'm not gonna bore you with that quite yet. We'll see if we still have time. But this basic premise of communities have time and no money and customers have money and no time, that doesn't mean your community isn't incredibly valuable to you as a company building products for customers and still running projects for community at the same time. You end up in this space that the community is looking at the free thing, at the project. And that's where they're engaging with you and they're becoming advocates for the technology. You're building a base of knowledgeable experts that there will come a day when they might work for somebody with money. It's a long-term investment and they're making your solution sticky. They're creating inertia in the marketplace. Customers, they wanna buy something and it's a product. At the end of the day, they want the product to work. They do not want to engage with your open source community to get support. I gave you money, I want it to work. We actually ran into this the hard way at Microsoft, it was hysterical. As they took the dotnet world and refactored it into dotnet core and then built a very robust community around there and there's a lot of partners that engage on the outside of that. But remember that for us is a compliment space. In those days, as they were doing that, it was dotnet was a compliment to Windows. We sold Windows, dotnet is a developer environment that runs particularly well on Windows. So that was for us the simple decision. I didn't work for the company at the time, but I'm backfilling in magic here. But there came a point where certain customers that gave Microsoft a lot of money as a customer. They weren't buying dotnet, but they gave Microsoft a lot of money as a customer. They came in and they said, there's this bug in dotnet core and we tried the line on them of, well, you should join our community. And that fell really bad with customers that spend a lot of money. They are the two, it's yours, it's your product, we give you a lot of money, accept it. And so we started to realize that there's product discussions and there's project discussions and you gotta get them straight. There's a problem too in this space. Lots of folks, I worked at Hewlett Packard for a couple of years in the cloud division and I got to see over the transom into a couple of projects there where they were trying to do this kind of thing and they thought all of our partners should come participate in our project. And again, this is misunderstanding the business relationship. Partners, they wanna co-sell, they wanna co-market, they wanna do things that are valuable with customers. It's all about the business relationship. That doesn't mean you can't do things with them in community or make the community the focus point for certain engineering collaboration, but you have to do it thoughtfully. You can't walk into that discussion going, it's open source. And that's my frustration in so many of these discussions is people apply the words open source and then they think magic happens and they step away from all of the critical engineering thinking that people have had to do in this collaborative space for decades and decades, like all the way back to 1950. And they step away from all the critical thinking that you have to execute as a business. You know, Silicon Valley businesses, you know, for every 10 that get invested once the home run, that apparently proves the investment model, not the business model, but the investment model, three of them will be mediocre and six of them will fail. Three mediocre ones get cut up for parts and that's the way that process works. But bringing open source into that discussion doesn't change that. I said the other thing I need to convince you of is freeloaders in your community means you're doing it right. Because this is the other frustrating mistake that you will see businesses trying to do open source things screw up all the time. And I want to kind of back you into this discussion with an example. So, in the world of Adam, the world of brick and mortar, we all choose our neighborhoods for very personal reasons. So, the first time I ever did this, I did it with a room full of community managers with 200 people rooms, so the numbers worked out really well. But you basically got three sorts of people. You have most of us. We just want to live in this community. I'll ask you the same questions I asked all the community managers. Question number one. How many of you know how to report either a pothole on the street where your house is or a street lamp out? Ooh, we are above the odds here. Looks like it feels a little higher than 10%. But typically that number floats in that space. And then you step into the how many people in this room organize the block party for your neighborhood? Because every culture has one. I mean, the three cultures I've lived in, the Canadians we all do, the Labor Day weekend picnic, kind of barbecue thing, Americans do the Fourth of July weekend barbecue thing, and sooner or later there'll be a royal wedding in England. So, you know, and there's a block party. How many people in this room organize the block party? Okay, in a room full of 200 community managers, two people put up their hands. There might have been a third. So it's the orders of magnitude problem. Lots of people just want to live in the community. They did, it wasn't GitHub, it was one of the other open source companies that regularly does studies on an annual basis. And their published study two years ago basically pointed out that people that just use the software, they contribute nothing, not a bug report, not a patch, nothing. They still self-identify with that community. I'm a Rust user. I'm part of the Rust community. They just want to live in the community. And, you know, there's the sort of people that report potholes and trash and this and stuff. The first time I came across this rules of some orders of magnitude, I was sitting in a usenix presentation about 20 years ago, and the person doing linux video device drivers, go back 20 years ago, that's not a big community, was giving a talk. And they said, you know, for every thousand users we have, I get about 100 bug reports of which 10 people might give me a patch of what one actually knows what they're doing. And I happened to be sitting beside somebody that ran one of the truly large communities of the day and said, Eric, does this feel right to you? And he thought about it for a moment. Yeah, for every thousand users, you get about 100 bug reports, and you get maybe 10 patches and maybe one read your community guidelines, your actual contribution guidelines. And that's the kind of orders of magnitude we're dealing with. You know, you keep scaling down and your software community is the same thing. There's a people that want to report it. There's about a, you know, you step down and order a magnitude to the number of bug reports you'll get. Step down and order a magnitude to the number of actual contributions you might get. And then you step down to the person that might actually, you know, give you that. They've read your contribution guidelines when they offered you the patch. So there's really three on-ramps that you need to run when you're building community. And this applies to every community. It does not matter whether or not you're a company trying to run a community or you're just a project community. This is, these are rules for your project community. Because you need to be, you know, encouraging the people to use your project. So you need to be building that on-ramp. You gotta make it easy to use. So that you'll find the developers that actually want to do something amazingly selfish for themselves. They're living in your neighborhood, but it's not like they're inviting you over for dinner every night. They just want to solve their own problem. That's the, again, this is the backwards thinking that I'm sorry, the reality of the open source world you've given me access, you've shared the software with me. I want to go, I want to go do this thing for me. And then you need to encourage them to give it back to you. You know, that's a really, really nice bug fix that you just did there. Can you contribute it back, please? That's the order of the social engagement in an open source community. People aren't running around going, hey, brotherly love, I want to free the software. No, you need to make these things work in the way that human communities work. Just because it's not a bricks and mortar community doesn't mean that suddenly we've elevated and evolved into something that, you know, we globally share stuff. The other thing, coming back to the customer side of the house, so we're back in the business world. This is one that keeps hammering home. And this is a hard one for people to take on board if you're the software engineer that was doing the work. Theodore Levitt was an economist at Harvard and he made the observation that, you know, the customer didn't want a quarter inch drill. They wanted a quarter inch hole. You know, I have worked for software companies where, you know, marriages were shattered. People didn't spend time with their children. You know, they wrecked their health, building incredible monuments out of the software. So it's gotta be the software, right? It doesn't matter what the software does. The software is important. Customer problem, they, and that's the problem for us is we end up in this space thinking that the thing that we have built is the thing that the customer's buying. And it's no, it's the customer's solving a problem. We're solving a problem for that customer and you gotta stay focused on that. This is my other favorite for the debates that we're going on right now. If you park as a company, your corporate identity brand on an open source project that you have basically licensed to the planet to use, this might not be the best thing to have done. We have seen successful fixes for this. 2002, Red Hat has gone public. Their stock has soared. The internet bubble has burst. Their stock has collapsed. And they go through a rebranding exercise and Red Hat Linux became Red Hat Enterprise Linux. And the open source community became Fedora. It did not happen that easily or in a couple of sentences. But that is roughly the model. We have just most recently seen it in the Docker world. You know, when, hey, do you use Docker? Yeah, I love Docker. Okay, so are we talking with Docker the company? Docker the product or Docker the project? Docker. Okay, so this doesn't give your sales folks a really crisp message to sell on or your marketing folks to build a message around. So they went through the rebranding, should have been two years ago now, that because everybody understood Docker and Docker was the value, they kept Docker the company aligned with Docker the product. And the entire open source community they shoved over the line into the newly branded Moby project. And they were basically following on the Fedora Red Hat Enterprise Linux model. So the idea though that you're gonna park your identity brand on the project, not the product, that dangerous place to be. And then you can walk your way through all of the companies right now that are bemoaning their licensing structure. They're bemoaning their licensing structure. But the reality is they've parked their identity brand on their open source project. And not the product that solves customer problems for money. So open source software is all about engineering off economics. There is no open source software business model. I should have put the third thing up there that basically said, remember, freeloaders means you're doing it right. And so it is about keeping those ideas of customers and community separate. Customers have money and no time. Community has time and no money. Partners don't be thinking your community project is a place to do partnerships. Somebody enters the room late and has personal experience with this one. And keeping the idea of products and projects separate is a really important idea. So I wanna finish off with just some examples. Everybody's favorite example. Actually I am just realizing there is a quote I should have added on a slide for this one. But this is the story of Red Hat in three CEOs. Do we have anybody from Red Hat in the room? Because this, you don't work there anymore. Because this often upsets Red Hat engineers for the next couple of minutes of this talk. The gentleman left to right, that is Bob Young, the founding CEO, that's Matthew Zulik who took over after they went public. And then you have Jim Whitehurst on the right hand side who's been CEO for 11, 12 years now. 11 years now I guess. It's always more interesting when you put the stock price underneath. There is no stock price under Bob. Bob was the guy that grew the company and took it public. And in growing the company, the joy of Bob, if you ever get a chance to listen to Bob Young speak, it's a joy. It just is. And I had the chance, even though he sold, he basically took Red Hat public in the summer of 99. And then he stepped away as CEO within that next year. And then he even stepped away from the board. And he's been off doing wealthy tech guy things. Except it didn't ruin him. He didn't make so many gajillion dollars that he moved to California and is living large now kind of thing. He stayed in the Northeast. And he is this quiet Canadian guy. And the talk he gave just a couple of years ago at All Things Open was fabulous because he's still this diminutive quiet little polite Canadian guy. And he's standing there. And he basically says, you know, I realize in my team that I'm the dumbest guy in the room. So I've always surrounded myself by smart people. And he was raised in a family of business people. He was not a technologist by training. And so he quickly realized that, you know, not only do I have to surround myself by smart people, but it was beaten into him by his family. If you make your customer successful, you will be successful. So that was the entire work ethic of the early Red Hat. And he was a brand manager in his head. And so the reason that the Heinz Ketchup is there is he literally used to freak out his investors by saying, well, you know, I'm running a Heinz Ketchup marketing program. And they just like, nobody, we're doing cool technology. No, we're doing Heinz Ketchup. When you think Linux, the next words in your head need to be Red Hat. And that was the brand program that Bob knew how to run. And it was very successful. They took lots of money, they went public. So now there's a stock price. And Bob has stepped away. Matthew Zulik, who was there towards the end. He's a very competent business person. He's there, it's starting to grow. The bubble burst, the stock crashes down to $3.50, I think it was. But Matthew realizes that there are a lot of people in financial services racking up Red Hat Linux. Typically the thing you were still getting on a DVD out of the back of a book in financial services. So he pivots and creates RHEL, Red Hat Enterprise Linux. And he starts to build a brand around RHEL and focusing absolutely on, this is not the best Linux distro. This is cheap Unix on Intel. So instead of paying a gajillion dollars to Sun for expensive Spark servers and expensive Solaris because it was no longer SunOS in these days, we're gonna give you cheap Unix on Intel. And he set up the ISV program and he burned his way through the Unix ISVs, getting them all up on Red Hat. So all of a sudden it looked like this was a real Linux company for Enterprise. Not only that, this is the period, this is the rise of app servers. So all we need an app server. So what do you do? They spent $350 million and acquired JBoss. So, and JBoss, that was Mark Flurry's third business model. He almost didn't make it as an open source company. But now he doesn't have to because Matthew looks taken him off the table. And then you get to end of 2007, early 2008. So just before the crisis. And they switched CEOs again. And the guy that steps in is Jim Whitehurst, who is a technologist by some of his training, loves the idea of this company. And his previous engagement was taking Delta to its chapter 11 protections. So we're talking about an executive that knows how to grow a company and maintain enough employee morale and enough customer loyalty in a vicious, margin-thin game of commercial airlines. This is now the man at the helm of Red Hat. And you'll notice the stock has had a decidedly upward turn. Despite the economy, and as the economy approves, certainly his stock price improved to the point that they just said, always forget the number, is it $34 billion, $35 billion, whatever. A lot of money. IBM just bought them for a lot of money. This is the story of Red Hat. We do now have a Red Hat employee in the room, so I will quickly finish my story before I have said them. But this is the story of Red Hat as a successful enterprise software company. This is not a company where we are not talking about open source here. That does not mean they aren't, Red Hat is gifted at their ability as engineers to build products and engage in open source communities because it started that way. It's part of deep culture. But the business is a software business. They are an enterprise software company. And Paul Cormier, who was a president at Red Hat, not a CEO, but ran the business, so to speak. In the IBM discussions when they began, was clearly on record saying, we're not an open source company. And it's like, yeah. And when you actually look at the history of them as a software company, they're a software company. They're an enterprise software company. And they took that pivot and they ran with it and they have executed to deep culture. It's about brand management. If you touch a line of Fedora, you can't call it Fedora anymore. It's not very open source. It's all about brand management. It's about making your customers successful. That's what they've done for 1994, you know, 20 years now kind of thing, 24 years. So to me, it's an amazing company. But it's not an open source company. There's no open source business model here. The last quick example, because I think I'm coming up on time. Kubernetes, the Kubernetes discussion that I gave you earlier. Yeah, I've had this fight. And the fight is, well, and the statement from the engineer was, five days after a major Kubernetes release, it is up and running in production. Okay, I'm an old product engineer. What happens in that five days? Well, they plumb in a whole lot of proprietary drivers that speaks to their proprietary hardware in interesting ways. That's a good thing. Yeah, thank you. They plumb in all of the proprietary billing software so that you know how much money you're giving them for what. Okay. They put in place all of the, there's extra testing and such that happens to make sure that that's all gonna work. And they basically go through a set of steps to turn Kubernetes, the project into GKE, the product. We do the same thing. It takes us an extra few days because we didn't create the project. So we haven't been actively testing it on our farm inside of the Google firewall. So it takes Microsoft an extra few days for us to take Kubernetes, the release, and turn it into AKS, the product. So that's, again, it's this idea that don't be let astray here by engineers thinking they're talking business to you. OpenStack was a classic. It is a fascinating collection of projects. I was in the cloud business unit at HP so I got to watch the Helian fiasco from the inside and watch the cloud business unit implode. But Helian failed. So three companies making the biggest contributions in terms of actual pull requests into the OpenStack communities were Red Hat, Hewlett Packard Enterprise, Rackspace. And we were all kind of up in the 15 to 20%. We were always fighting it out. You can pick one randomly out of those three every six months and that would be the top contributor. Helian exploded and it's gone. Rackspace suddenly didn't want to contribute quite that much anymore. And I think it was the depth of the experience that Red Hat engineering had with projects versus products. And I don't know that they would ever say it this way. I think this was more culture that allowed them to survive this. They backed off and refocus the whole RDO world into telco, which is where OpenStack has become very popular still. You don't hear about this mad craziness of OpenStack anymore because that world kind of disappeared into the maw of telco and that's why. So Red Hat, again, understanding exactly how the project product thing works has rescaled and it's focused on a different market and that market is dramatically different from the IT market. IT flows differently in that market. Patents flow differently. Software flows differently. Product buying cycles are different from IT. It's just a different world economically. And so Red Hat has, they refocused that world really nicely. But we've all kind of known this for a long time. Again, that idea that Linux is a project, a product. Fedora is not even a product. It's almost a product. But it's a really well run, tightly trademark managed community. It's a distro. Rel is a product. You, if you're a Rel customer, you give Red Hat a lot of money every year to ensure that that's running all the time in very specific ways. And so that's the talk. I'd like to thank you for your time this afternoon. And I will, what are we doing for time? I am right on time. So I've got time for maybe one question from the audience or I'll step outside the door and you can ask away. So thank you very much. Thanks a lot for coming to my talk. So I give a lot of presentation, a lot of conferences. Usually about Next Cloud and all kinds of other open source projects that I'm doing. But this is a talk that I, for the first time, gave at FOSTEM a year ago. And it's a bit of a special presentation because it's not really about the technology or stuff I'm doing. It's more like a personal story. So at the first time I gave this talk at FOSTEM, I really got great feedback. This is why I recycled this a few times already and I hear that it's interesting because it's, yeah, maybe give you a few insights about the problem that you might run into if you're doing an open source project or an open source company or both. I also want to do this in a more interactive way. So I have a lot of slides, of course, but please interrupt me all the time or during the talk if you have any questions, if you want to know more details. I want to be as open as possible. There are a few things that involve other people that are not very detailed. I hope that's understandable, but in other things I really tried to be as open as possible so please always interrupt me and maybe we can make this more interactive. And I have a bit of a cold as you can hear so I hope it's good to understand. So my name is Frank Kaliczek. I'm from Germany as you can hear, obviously. I'm an open source developer for a long time for over 20 years. I contributed to all kinds of different projects at the beginning, mainly KDE, the KDE Linux desktop where I did coding and artwork and marketing and did websites and event organization and was a board member for some time. I also contributed to other projects and started my own things. And I'm probably here most well known to be the founder of OnCloud and founder of NextCloud which is a successor and it's the topic of this talk of course, the history behind that. So first of all, take a few aspects about my personal history as I said, I've been involved since the late 90s in open source. KDE at the beginning. I still remember, I think it was 96 or 97 where a friend of mine showed me the first beta of KDE 1.0. Now I was really blown away at the time. I thought, wow, this is as good as Windows 95. So obviously this will be the future and this is done by this volunteer community. There's no real company behind it. It's all volunteers from all over the planet working together doing good thing and it's as good as Microsoft. So this will be the future. So obviously next year will be the year of the Linux desktop. That's what I thought and many others too. And this is where I really invested a lot of energy in. And I was really impressed because this was all community driven. There was no company behind it. Everybody could contribute. I remember when I went to the first hackathon, the first hack event of KDE. It was just like a room with tables and chairs and you just sit down and you do stuff. You don't have to ask for any permission. You don't have no one to approve your work. You just say, here's your account, do good stuff. And that's how it works. And I was really blown away by that. Of course, 100% free software, 100% open source. Of course, the community decides about the features. There is no big manager behind it. It's all community driven. And like at a time, it was really going strong. Like every release after another was significantly better than the release before, like in all areas. Three of the Linux desktop. One problem we always had in KDE was the changing of members of the community, right? You always get the new volunteers, the new students and the good stuff. And then like two, three years later that drop out of the community because they're done with their studies, have a real job, maybe have a family, and then no longer have time. And they're moved into the proprietary world. This was a bit of a problem. For me, it was always the dream can be somehow create a situation where people are actually paid for doing free software. That was always something I wanted to achieve. Then the own cloud. Own cloud was something I founded in January 2010. It was actually a KDE project at the beginning. I was still a member of the KDE community, of course. This was a KDE project. KDE had and still has the mission to create a complete free Linux desktop environment, of course. And nowadays, this involves cloud services, right? You need like cloud applications, syncing sharing, syncing your settings between your laptop and your desktop and so on. So this whole cloud thing was for me always part of the desktop experience. So this is why own cloud was a member of the KDE family. It was HGPL licensed. For me, this was a natural choice. Was just like the nice copy left license which protects the right of the developers and the users. It was growing nicely. We got more and more contributors. Released version 1.0, 1.1, 1.2 and so on. It was really growing nicely and was very quickly the most popular open source file syncing and share solution. I think file syncing and share the term wasn't created by then, but it was the most popular software for this kind of thing. First developer meetup, good press coverage and so on. And for me, then when I saw this momentum growing up, I was wondering, okay, is there a way to pay people to do this because that we don't run into the same problem again? Is there a way to have like real full time people writing free software? And then, what an opportunity we popped up. I got in contact with two other people. So other people were also like doing open source company business for some time. And together we decided, okay, let's take this open source project and let's try to create a company around it. A real nice open source company because then we can actually hire people and I can do full time work on that and it becomes even faster and more successful than a test of pure volunteer community. So this was my idea at the time. So one of the persons took the position of CEO and the other sales and marketing and I was the CTO. That's what I did. We founded this company, OnCloud Inc. In 2011, end of 2011, like a little bit like two years after OnCloud was founded, it was based in Boston and the US here because we had like collected venture capital at day one already. So that's what my co-founders told me, that's what you have to do. This is how you create a real software company. You need to have like investors. It needs to be based in the US and that's how it works. And of course, if you know how this venture capital world works, then you know that this is all optimized for fast growth and fast exit. This is what investors want of course. I'm not really interested in a sustainable, stable company. It's really about growing fast, selling with a big profit or if it doesn't work, then you just kill it fast and you do the next thing. This is how the venture capital world works, which I didn't know at the time. So we got this money and what do you have to do with the money? You have to hire like a lot of people very fast. You don't have the time to look for the right people. You have to hire like as fast as possible because you have the job to spend the money really fast. So we hired a lot of management which was unfamiliar with open source and created this software company. Some friends from my KDE times were skeptical if this was the right decision from Frank and at the end they were right to be skeptical but that's what I learned later. Of course, with this whole setup that I did, of course there were some issues popping up. At the beginning, we still had this big momentum which was growing strong but there were some issues popping up. First of all, the bad alignment between the management and the investors and the open source community because a typical volunteer, we had like hundreds of volunteers already contributing to the code base. They were interested in something that's really sustainable and fun and easy to use and open and free for everybody. And the investors and their management were really interested in building like a proper terry software company to maximize the revenue and to sell it to customers and so on. And there are some overlap but some other things were not really that well aligned. So this led to the situation that more and more of the contributors were unhappy with the situation that actually left the project. So they had different reasons. I have a few examples later. For example, an open source community usually do what's fun for you but if the whole project is controlled by a company then the company has like product managers and they have a roadmap and they have strategic features and they really have a lot of planning and management. And if you're a volunteer and you're just sitting there on a subtle they think, I want to create a nice feature for own cloud then you're not interested in management structures and where we have to ask for permission you just want to do what you want. And you don't really care if the product you're building fits into a certain quadrant of the partner, magic quadrant or whatever just do what you like. And this is not really compatible often with the way this kind of management structures work. Of course, the company and the investors also have an interest on making money obviously which don't be mistaken. I also was interested in making money I wanted to pay the people obviously. And we paid a business model actually several business models to monetize own cloud at a time. First was dual licensing. So the idea is that everybody who contributes code to the product has to transfer the ownership of the code to the company. So the company is the owner of everything. And then the company is in a situation to do dual licensing. So what we did at a time, we released like own cloud as HGPL, which means open source free software license copy left license, which means you can take the software you can do whatever you want with it. But if you change it, if you modify it you have to open source your changes too. You have to open source your changes back. That's what the GPL or the HGPL service of that says. And a lot of companies don't want to do that. They want to take it. They want to create some connector to some other software but this connector shouldn't be open source. And then the company can say no problem just buy this proprietary license from us which costs a lot of money. But if you can get own cloud under the second license then you don't have to do that. Cost a lot of money, but no problem, just do it. This was the first boss business model. Second is open core enterprise edition which basically means that there are two versions of own cloud available to community edition which had limited features which was open source. And then the real version which was called enterprise version which had a lot of features but was not open source. Of course the software was still marketed as real open source and hey, it's great, you see it, you can do what you want, it's awesome. But there is a customer really, okay, I really want to have this objects or connector or this advanced firewall rules or this other security feature. Then the answer was yeah, you have to buy the enterprise edition for that and this is no longer open source, just proprietary software, pay us money, you get it, but you can't distribute it around, you can't change it, it's just proprietary software. And this business model created conflicts between the community and the company interest. I personally think that open core, the name of this business model is inherently unstable. We had a lot of situations where the community wanted to develop a feature and the company said, well, we can't really accept your feature because this feature is in the enterprise edition and we want to sell it. So if you write this feature as an open source feature for a community edition, then no one pays us anymore. So basically it was, we created a situation where the employees of the company are fighting with our community. This is just bad, I mean, this is just very bad. Another area, because very critical was product management. So the company really wanted to have control over the roadmap and the features. They really wanted to have a plan, okay, next release comes out in half a year and the features will be in and after that, not a half year next, this feature will be in and so on. But if you have volunteers who do what they want, then this model really doesn't work. So projectability was really a problem. One example is that we released own cloud 3.0, 4.0, 4.5, 5.0, 6.0 and so on. And you wonder why was there a version 4.5? That is weird, we always incremented like the major version with every release, but there was one 4.5 in the middle. Well, the answer is that someone promised our investor that a certain feature is in version 5.0 and it wasn't ready at the time because the community person did something weird and then we couldn't name it 5.0 because it was promised to be in the version and we had to, whatever, so it basically is a tension between an agile community process and a planned real enterprise software development workflow and this just didn't work out. The other examples were like the actually market where we are in. So when I started with own cloud at the very beginning there was no name for it. At the beginning I just called it open source Dropbox because there was no better name. Of course it's a stupid market and you shouldn't identify yourself as with your competitor. A little bit later, Gartner created the term enterprise files you can share. So then this kind of product that I did was called enterprise files you can share. It's about syncing and sharing of files. But our community, they didn't care about what Gartner says, right? They just did what they wanted to do. For example, they developed a calendar and email and contacts extension for own cloud and actually they were there still today one of the most popular features because really people love to synchronize their calendar and their contacts with the software. But of course the management of our company like what are you doing? This is groupware. This has nothing to do with the enterprise filing and share market. We promised our investor that we're doing ESSS software. You're not doing groupware here. That's crazy. You can't build a car and a plane at the same time. I mean stop doing this. And this is just this kind of tension which wasn't really working out. It's actually funny because nowadays Gartner renamed it to content collaboration platform and it includes calendar and contacts. At the end the community is right of course. The community is always right because the community does what the community wants. So I have some wisdom there. But at the time it was just not compatible with the management structure we had. Okay, so this led to the situation that in 2015 and 16 our community were really unhappy. A lot of volunteers left the project. The employees were not happy. I mean most of the developers they were friends of mine and I think they thought that they're working for an open source company here but in reality they worked like proprietary features. And the customers are also not happy because they thought they're using open source software. At the end they had a vendor login same as with Oracle and Microsoft and the others too. So this created some tension. I tried to fix this internally. I had lots and lots of meetings and discussions but at the end I really couldn't. And of course this also created financial trouble so we actually burnt a lot of the investment money because it just didn't fit together. So what happens then? I mean if this would be just a normal close source startup normal close source software company the company would just die. I mean the investors were not interested in investing anymore. It's not the business model is not working. Okay the company goes away. We all look for other jobs. Okay no problem we start the next company. But actually the software was not bad and the customers really liked the software and the employees really liked working on the software. So there was something to it. But the business model was just broken. So because it was like in the core still open source there was the opportunity to fork it and to fix the mistakes. And this is a quite unique situation because with no proprietary software you can't do that. But this was an opportunity. So this led to the next cloud fork. So in May 2016 12 of the core people actually left own cloud including me and we found the next cloud as a successor. So this was possible because the core of the software was still open source and we could just take it and start from there. The first thing we did we all locked ourselves into our house in Germany for a week and we did a lot of brainstorming and discussions what to do now. So what was good? What was not so good? What can we do better? How should the business model work? And so on. And the result of this brainstorming was that we came up with a few principles that we wanted to follow. The first is that we decided that next cloud should be built around sustainability and we don't want to have any external investors anymore because external investors is of misconception. People think that is just free money that you get. Of course that's not the case because they expect something back. So I want to have a return of investment and fast, that's not in 50 years, but like next year. So this is just something which I think is often not really compatible with open source in my opinion. So next cloud should be something that's sustainable. We want to build a company and a product on the project where we can still all work at still in 20, 30 years because we really like it. Second is we really decided to need 100% open source and free software. We don't want to do this dance or at all that's a proper territory feature that's an open source feature. We just want to do it 100% open source. And there are examples for that, right? There is like Rattat and Susan and many other companies who also do 100% open source and they're also successful companies so it's possible if you do it the right way. The third is we don't want to have any contributor license agreement anymore, which means next cloud works very similar to the Linux kernel, right? Everybody can contribute a patch or an improvement or something, whatever they want, but everybody keeps their own copyright. But Linux towers doesn't own the copyright of all the code in the Linux kernel. It doesn't matter, right? Same for us, it doesn't matter. The only thing that matters is that the licenses are compatible in our case. The server is written in HGPR, it's a license under the HGPR license so everybody who contributes code has to give us the code under the HGPR license. But the copyright is shared, which means next cloud nowadays is actually owned by thousands of people. That's not by one entity, by thousands of people. Same as the Linux kernel, same as many other open source projects, KDE, GNOME and many others. And I think this is just healthy. And the drawback is that we can never, never change the license anymore. It's just not possible because we would need the agreement from everybody, which is not possible if you have thousands license owners. But it's okay, it also makes it very stable and very reliable. No one can decide, I'm as the project founder, I can't decide that tomorrow it's proprietary. I can't do that. I don't own, I own nothing here. And that's a good thing. Number four, open standard. So we want to use open standards for as much as possible. We want to focus on federated and decentralized architecture. So nothing should be like centralized in one instance. It should all be federated and more about this later. And we want to more make all important decisions in an open community process. This is why we have all the discussions, roadmap, docs and features and everything on GitHub and everybody can contribute. If you're an employee of the company, you have no special rights, right? You don't have the right to overrule a community member. Everybody is the same. And we really care about diversity. So we really want to build an organization which is diverse, which I think is in a healthier community. Okay, so that's all nice, but you're wondering, okay, how do we actually make money? It's also important if you want to pay people. So we want to focus on big customers only. Very similar to Linux and to other open source products. Where we concentrate on monetizing the big enterprises and not the home users. We looked at Red Hat and SUSE and others as inspiration and we picked the same business model basically. So what we are selling is an enterprise subscription that you can buy on top of the software if you want. And for that you get support, telephone support, email support, you have direct access to the engineers. If you have any questions, you can talk to the engineers directly and you can create workshops and supply you with patches. And we help you with scalability and with branding and with other things. Similar to what's included in the Royal subscription or the Slash subscription, very similar. But if you don't need this, you can use like Fedora and open source and the others of the class, fine. And it's exactly the same for us. You can use next cloud, there's no limitations, no features, it's restricted man limitations and fine users or storage or file or whatever. We just think that if you're a big organization, if you're a few thousand users, maybe you want to have an official SLA and that's what we offer. Okay, so where are we today? I'm really happy, I'm really happy that it worked out. It was a bit of an adventure, I have to say. But today I really have to say that we have more contributions than ever so the community actually came back. This really worked out. As a company, we have over 45 full-time employees now and we are growing and we are actually profitable, which is something the old company never achieved. We have a very fair business model which will be concerned for all the employees and all the customers and everybody. This is working. Companies are paying us for our enterprise subscription and it's working. We don't have any external investment so we just, no one was telling us, hey, your quarterly numbers need to be better or you really need to have an IPO next year or whatever, we don't have this pressure at all, we can do what we want. And we have a growing customer base from German government, for example, to a big service provider here in America with 20 million users to big enterprises like Siemens and the French government and many others who really like our product and we're still growing nicely and hiring. We don't have this Contribute Agreement, 100% open source, the community was really happy. When we announced the fork, I thought that it takes a few weeks or months before we have everything settled but actually our community managed to two weeks after we announced the fork to already release the first version. So it took the existing code base, changed everything, replaced logos and trademarks and everything and released it and was just very faster than I expected. Then our community wrote blocks anymore. I mean, everybody can do a pull request, there's a contribution to Next Cloud. You need like review from two other people. None of them needs to be an employee, just two other involved people and then the features in them. This really helps to accelerate everything a lot. And everything is managed on GitHub. Even our company website is on GitHub. So actually the design of our company website which I think is very nice is also done by a volunteer. So this is really interesting. So really, our community really likes us and that's really nice. So that's a photo of our last conference in Berlin where we have like 200 volunteers there. So 200 volunteers came to the event for a week to work on Next Cloud in their free time. So that's really nice, really growing people like what we are doing. One challenge is of course the trademark. I mean, I came up with the name OnCloud and I think still think it was a good name. My wife did the logo, but of course this is no longer own it. So we had to create Next Cloud as a new trademark. And here maybe you know how it is. It takes time to convince people to switch over to the new name. If you can talk to the LibreOffice OpenOffice guys, they're still like OpenOffice is still so popular. I mean, the project is obviously basically that. But still a lot of people know OpenOffice and use OpenOffice and they have never heard about LibreOffice, so it takes some time. So that's a tool from Google Cloud, Google Trends, where you can monitor like how often the search term is used and mentioned on the internet. So the red graph is like OnCloud over the time and the blue is Next Cloud. So it's actually happy to see that we overtook the popularity of the old name already. But as you can see, it still takes still many, many years before it's basically clear that we are the full successor. It's just people have good memories. That's just how it is. From a customer perspective, I already mentioned that we have many well-known customers from governments to universities to enterprises all over the world on every continent. We have a nice initiative called Next Cloud Include where you can, if you're from underrepresented group in IT, you can get mentorship and internship, crowd support from us. And I'm really happy that we can do this. But I have to say that the thing where I'm most happy about is the progress of the software itself. And I want to bore you with many, many marketing slides now, but just to highlight a few things that we did the last two and a half years, which were mainly not really possible. The first is, this is the main web interface of Next Cloud. You can see your files and folders. You can drag and drop and filter it and so on. Sorry. And for example, in the sidebar on the right-hand side, you can see that there are comments and chats and activities and there's a call button. So we already have functionality which is outside the typical file signature. And that's fine. I don't really care if you're fitting into the Gartner quadrant or whatever what people think, what the software really is. I mean, for me, it's only important that we do something that's useful for the user. So we already innovate in the space. So this is not a really, you don't see this in Google or Microsoft products, but our people really like this integration. We have really nice, completely open source iOS and Android apps, of course. Also with innovative features like push notifications, we are not possible for and support for smartwatches and something is changing, okay. You can still hear me? Yeah, okay. Then the desktop client, it's also something that we can maybe innovate a lot. So four weeks ago, we launched a feature called Drive, a Drive feature where you can see all the files that are on your cloud server, on your local disk, even if you don't have the local space to synchronize everything. But if you click on a file that's downloaded on demand and then cached locally, it's an innovative feature, again, which was not possible before. Two factor authentication is something that we can do via the OTP protocol, via SMS text messages or hardware tokens. The federation feature, for me, is personally very important, I mentioned this before. This is the idea that we want to create a solution which is, from a user perspective, as useful as Google Drive and Office 365 and Dropbox and all these other centralized services, but something that's really decentralized. So you can see here, all these clouds here, you have these different next cloud servers and they have different users attached to the next cloud servers, but you can all share files with each other. So it looks and feels like a big Dropbox service but there is no centralized server. So we, for next cloud, we host nothing. We have no infrastructure, we have no users, we have no files, we have nothing. We just want to encourage the rest of the world to create their own little note of this network and we can all share with each other. A lot of people think that's not possible, that's why you need to have everything, one big data silo, but that's of course wrong. I mean, if we all remember how email works, right? We can all host our mail server, you can use the mail server from your university, from your company, from your service provider, or you can host it yourself, but you can all send each other email, right? And there is no central mail server on this planet. It's not needed. No company owns email, it's not needed. And for files you can share and a lot of other things, it's the same, right? You don't need a centralized instance. Maybe if you are an investor driven company, then you want to control it because control then means value and then the company is more valuable and then if you do the big exit, you can make more money. But at the end of the day, I think a decentralized approach opens our self-host it is better here. We support end-to-end encryption now. We launched this last year. It's also a very, very nice feature. We also support enterprise key management. So it's also useful for companies. Because you're fully open source, it's really easy for us to collaborate with other open source projects. Moodle, for example, is e-learning software. We have really nice integration. In Moodle, you have support for two file management back-ends, one is one drive from Microsoft and the other is next cloud. Native directly into the core. I'm really happy about this. Also the reason why a lot of universities use us. And for us, it's really natural. I mean, just we're open source, compatible license talk to each other, discuss the APIs and it's working, right? No one cares who owns the code and who controls what. It's just equal playing field because of the copy left licenses and it's just nice. And the same with RocketChat, it's a nice chat solution where we also have integration. That's also very nice. Of course, we can also scale to a lot of users. The next cloud is something that can be installed on the Raspberry Pi at home. But the biggest instance, I mentioned this before, has over 20 million users. So everything in between is also possible. So the typical customer from us, they have like a few thousand users, which you can do this with a nice little links cluster. But if you have 20 million users, you really need to have different hosting centers on different continents. And this is what we also developed the last few years. Then we have this group component. I mentioned this before. I mean, for some people, this was like weird because it's not really part of file thing and share, but I don't care. It's useful. And our community develops it. And we have it now and we fully support it. And surprise, we even have customers who want to have support for it now. It's actually working. So sometimes the open source community can be really nice help in market research. Usually if the community wants something, then often customers also think it's useful. So we also have a crew banner. And we have a project management tool, a deck, a Kanban board. It's also very popular. Last December, we launched integration into the MasterDone social networks. MasterDone is like a nice distributed federated social network using the ActivityPub API. So every next cloud server can also be part of this network now. So basically you can host your own Twitter replacement node as next cloud, which is nice. We have this new communication product called Next Cloud Talk. This is a group chat. Looks very similar to Slack. We have different channels. We can have lots of people in the room. And we have completely open source iOS and Android apps where you can also chat on your phone, get push notifications, someone mentions you in a channel, very similar to Slack, but again, 100% open source, 100% self-hosted. And of course you can press this call button and then you have a video call. This is using that RTC, completely end-to-end encoded peer-to-peer video calling and directly integrated into Next Cloud. What you also can do is editing office documents directly in the browser. I work together with the LibreOffice community. There's a tool called Collabra Online where you can edit Word, Excel, and PowerPoint files directly in the browser. But you can also do this in groups. You can also do this several people with different courses at the same time. And on the sidebar, you can have a chat with the people and a video call with the people while editing the same document at the same time. I'm actually a bit proud about this feature, but this is something that doesn't exist anywhere else. If you look at what Office 365 for Microsoft does, Skype for Business is also there, but it happens to a completely different window. And the same for Google Docs and Hangouts. So this is a bit, for me, also proved that crazy open source community can also do innovation, which is quite nice. Okay, so the summary is we want to build something that has the same use experience and features than Office 365 in Google Suite, but you host wherever you want, on your Raspberry Pi, on your Linux server, on your data center. You can deploy this one click on AWS if you want on a big cluster, whatever you want. It is compliant. I can say this because it's basically always compliant because you can always host it the way it is required. You can basically decide about availability, about how long files are backup or archive. If you have an auditing log, if you're what kind of authentication you use, it's super flexible because it's open source and on your infrastructure. Again, 100% open source, no vendor log in. You just can take the software, you use it. If you want to have an enterprise subscription, support from us, come to us, we help you. If you think that we're doing a bad job, the cancer subscription, you can keep on using the software. All right, there's no vendor log in. I think this is very useful and a lot of customers from us like this freedom. Yeah, if you want to use it, you want to try it, next-low.com slash install, and if you want to get involved, everything is open. You have a community of 1,800 contributors, only for code at the moment, so everybody's welcome to get involved. So, this was my presentation, thank you. It's a good question. I mean, you can imagine that there might be conflicts, but there are not a lot, I have to say. I mean, the decision happens basically in GitHub, in the tickets or in the pre-request, and I can rarely remember that there were some heated discussions. I mean, there were some exchanges about arguments. Some of the things here, you should do it like that, you should do it like that. Often, the people who have the highest reputation in the community basically are, I don't know, have high credibility, and if they say something, they're not to believe it, or there's also the rule that who codes decides, right? I mean, if someone does a feature and someone comes along and says, this is totally wrong, you should do it differently, then the answer is usually, okay, show me. And then they're free to build an alternative implementation, and that's fine, and then there's more discussion, and at the end of the day, then some solution is picked. I don't actually, don't recall a lot of conflicts there. Yeah, yeah, yeah, yeah. I'm not a big believer in voting of random people. I mean, you really have to do something to have a voice, I think. I mean, we have a feature that in feature requests, you can actually vote. I mean, everybody can go into GitHub and say, I like this feature plus one, and it's a little bit higher on the list, sure. But this doesn't mean that someone really develops it, right? I mean, it's developed if someone develops it, and not because it has a highest score. So I think, yeah, it's the code decides not to vote, yeah. How's the company organized? Like, up to 12, four, 12-cloud, yeah, yeah. Like, where are they now, and how's your organization organized? The company is boring organized. I think it has no magic source there. I mean, we have a, we have a sales department, we have a marketing department, we have an engineering department, man, this is maybe a little bit different. So for example, we don't have a separate support organization. Usually companies have a separate support organization, and engineering is different. I do this together. So the person who develops a feature is also the person who then has to help the customer to fix it. I think this is healthy, I think. And also the customer appreciates to directly talk to a competent person, not to a random call center guy who has escalated five times before, I don't know. So what we are selling is really premium support, right? This is also not cheap. But customers that really talk to the people who wrote the code and who can help with everything. And this is why we have support, engineering is the same thing. And then we have a small professional services department that doing projects. I am, project business is something you have to be a bit careful because it doesn't really scale. I mean, a lot of open source companies try to do projects to finance their product development, but there is a bit of a conflict between consulting work and product work. So we do projects or consulting work, but only for big customers. That's basically it. There is no real magic source. I mean, we are really distributed. So we have employees in nine countries. So we have offices in Stuttgart and in Berlin in Germany, two offices, but most of the people are just work from home. The reason is that hiring good people for me is really easy because I can just look in the community. If I need to develop in one area, I can look who is doing work there in a contain. What you do as a hobby, do you want to be paid to do the same? So this really, they know the code. They are motivated. They are behind the product. They already know the people. They are productive from day one. So this is hiring for me is very easy. The job I guess that they work from somewhere, right? They are not in the same city as the offices. But that's okay. I mean, the whole community works over the internet anyways. So employees can do the same. Speaking of money, how do you make provisions regarding money? When you are paying for offices, do you have contracts with your customers? Is there a lot of positions that you can make? I guess that's the same as with every company. I mean, me and the leadership team, we have to do the hard decisions at the end of the day. Sure, it's our job to make sure that everybody gets paid next month. So do you have like the leadership team? Yeah. They make budgeting decisions? Yeah. I mean, I don't know, 98% of the money is salaries of course. So budgeting is, yeah, but yeah. Yeah. No, we are, it's, I mean, I believe in a nice community. Everybody is welcome and everybody can be part of it. But as a company, I of course also am responsible that everything works, right? I also hire people if they're not the right people. I don't hire community people. I can do what I want. But for employees, I have to make sure that everything is working. Of course, yeah. Companies owned by me and some other early team members. They're no external investment. Basically everybody who owns shares of the company, it's just a few people have the interest of doing this the next 20, 30 years. So there's no real pressure there. At the moment, I think it's a good situation. I don't want to change it. I would never say never. But the problem is if you accept external investment, I mean, I get calls from VCs all the time, right? I say, hey, I want to have some money here. But this of course means, I mean, I guess most of you know how this game works, right? I mean, it's relatively easy nowadays to get money. But the deal is that you basically pay like 10 times this money back in three years. Why 10 times? Because like only one from seven startups survive. So I have to compensate for the ones that fail. And the ones that survive really have to pay like 10 times this money back. And then they can make a profit. And the profit should be a little higher than on the normal stock market. So they really expect to get like 10 times back. So it would be super easy for me to get like, I don't know, 10 million of investment. If I somehow explain to them that I can get 100 million back in three years. Easy. The question is where does the 100 million come from, right? So it usually, I mean, you can get a lot of customers. That's tough. A lot of money. You just raise the next round. This is how it usually works. You just do the next round and pay the early investors back from the next round. But for that, you have to grow, grow, grow, grow, grow. And you lose like control of your company more and more and more. Or you do the big IPO, which, yeah, sure. I mean, that is like, I don't know, CEO.1% of all companies reach that state. So I mean, accepting investment is just like the huge risk. And if I can avoid it, I don't plan to do this at the moment. And then about VC funding, by the way, don't get me wrong. I'm not saying that this is always bad, right? It has a place and for some industries and some markets, maybe even open source, it can work out. The problem is I really think that everybody should understand what it means. Everybody, including the community, should be on the same page to understand what it means. Because if you decide this, then on the road, there are certain decisions already pre-made for you for the future. And if it's okay with you, it's all fine. I'm not saying it's bad. But often open source communities don't really understand what it means. That's all I wanted to say. But you re-question other mistakes. I mean, obviously license decisions are very important. You can't change them easily. You really have to think about it. And I'm not saying, I mean, we are happy with HEPL. But I'm not saying this is the perfect license. It really depends on what you're doing. You see these discussions with Redis and MongoDB and others are really struggling with their license. Pick the license and then they said, oh, it's no longer the right license and change it. And license is really an important thing. It decides about the playing field between all parties. That's something you really should think about it. And at the end of the day, community building. I think community is the most important value of open source. Open source has lots of values. You can audit the code. You have no Vandalogue and blah, blah, blah. But at the end of the day, the biggest differentiator of open source to other, the proper terriers that you have to community. I mean, we are still like small, right? 45 people is nothing compared to Microsoft and Google, right? Why can we do a product which is half very comparable? And only because we have 1,800 volunteers. Otherwise, there would be no chance. So I think thinking about how to build up a really good, working, happy community, it's also super important, I think. So you're referring to what Redis and MongoDB, the challenges? Yeah, yeah. That's a challenge, yes. That's a challenge. I don't have a good answer. I mean, just summarize it for everybody. It's basically, I mean, we are selling and end up by subscription, which give you like support and help or scalability and patches and like all kinds of things to make it run smoothly. But if you take the software from Amazon, take care of that. You basically don't really need our subscription anymore if you would get LexDot as a service from Amazon. And this is a challenge from MongoDB and from Redis. They also have the same end up by subscription as we have. But if you don't really need a subscription, if you just get a service from Amazon and then economy of scale, right? It's like, you don't need to care about patches. I mean, Amazon patches like all the instances in the world and that's done easy and no one needs to care. That's a challenge, yes. In fact, there are already, next lot is already uploaded by some other, I don't know, by some people to the AWS marketplace. And you could go there and say click, deploy this on this huge cluster. I don't know if this is properly done, but if it's properly done, that's all you need. You don't need our subscription anymore. Basically, you don't need our business model anymore. You just take the resources from Amazon, deploy with one click and then you have your cluster for 10,000 users. This is a challenge, yes, for our business model. I don't have a good answer for that. All I know is I'm not a fan of the comments clause licenses. I think this is not a good idea and I especially don't like that that call is open source because it's not, but I don't have a better answer either. I see a lot of product perspective. I see a lot of companies and enterprise organizations switching to Office 365 for Microsoft, a lot all over the world. And I think this would be just huge for them. Maybe this would be even more profitable than the old licensing business windows on Office for them. I think, I don't know, maybe a good idea to buy Microsoft stock. I don't know. But I think there will be like 10% or 15% or maybe 20% of the world who really want to be in control of their data and their privacy and after data and their jurisdiction and integrated with other software. Maybe want to audit the code, want to have their own encryption, blah, blah, blah, blah, blah. And this is something that we want to have as our customers. So because we are basically done, we want to be, we want to do the same than Office 365 from user perspective, but on-premise or at least where you want, not in the Microsoft cloud. And I think there will be a small part of the pie, but there will be a part of the pie who like that. That's our, that's our direction. Is it that you most enjoy doing? You look more into it. Me personally? Yes. I like innovation. I like crazy new ideas. I like, I don't know. We have like next week, we have another, another meeting in Germany where we plan the next release next month, 17, 16 will be out in a few weeks with nice new stuff. And then we are sitting together and think, okay, what is, what can we do for the next one? Just we do this group exercise with beer and pizza and takes like long time. And this is what I like the most. I mean, I sometimes look at what the competition is doing, but actually not that much. And just think, okay, what would be cool? What we can, what can we do? And then just, that's what I always liked about IT and software. Because I don't know, if I would be interested in cars, I couldn't build a car. No one can build a car at home. It's not possible or plane or whatever, but you can build software at home. I just find it's quite powerful. I always enjoyed it. We can all do something, some innovation on our own with open source, standing on the shoulders of giants. I find this amazing. I can do, I can be an inventor here. I can't invent a car, but I can invent software. And that's what I like. And let's see. Thanks. Okay. More questions? Thank you. I did not, I did not mean to get rid of the, can we adapt it? This is mostly just me checking mic level, so I understand how bad it is or how good it is. No. Is there a switch on the very, very bottom? We can just present for each other into our massive audience. Oh, no. And it's, it's sort of a nature of, of less technical talks, even though this is somewhere in between at scale. The technical talks definitely draw better. I shouldn't have said that too loudly. We could have lost 50% of our audience. I think it is. If it's too high level, there should be ample time for Q&A at the end for you to say, now wait a minute, that's too high level. I sure would like to see something a little more practical. Say that again. That's your feature request. Your feature request is that we are concrete and not conceptual. We get pretty specific about what we measure and where and how. All I have to do is keep my hands from freezing off. There we go. Yep. Let me turn this off. That makes a kind of sense. I'm going to start muttering quietly to myself as I put everything on mute. You should mute your phone, especially if it goes crazy on notifications. Let's go ahead and get started. I don't know if I'm supposed to remind everyone that it's being recorded. I'm just going to remind myself that I'm being recorded and try to stay in this approximate area to make that easy. Thank you for coming to this talk. We are in the open source and enterprise track. This talk is titled, your company cares about false sustainability, but are you measuring your contributions? My name is Dwayne O'Brien. I'll be speaking today with Danny Gellis. In my past life, I was sort of a Dev Ops-ish, Perl-ish guy before it was really referred to as Dev Ops. I was often referred to myself as the Perl guy on the Java team, but mostly responsible for making sure that things stayed up. After that, I was a JavaScript ruiner. That's not self-effacing. Legitimately, I was not a great JavaScript engineer, but I was hacking on JavaScript code for a while. After that, I stepped into sort of an agile facilitator role, helping a company through their agile transition. Then I was an open source enabler. I was running day-to-day operations of an open source program office over at PayPal. My current life, I am the head of open source at indeed the world's number one job site, which means I'm responsible for open source for the company, both in program and in sponsorship and in many other ways. My next life, I see myself as some intersection of a rock star vampire wizard robot. I haven't quite figured out what that is, but they always say that you should create the role for yourself that you want. That's where I'm trying to get. I'll be a full-time engineer, so I decided, well, I'll keep taking classes that I started teaching adults to code, which was great too. Now, my current life is I am a full-time engineer for an individual program, which makes me very happy. This was the first time I'd seen that, so now I know in what direction to help her develop. Apparently, both of us are trending toward automation and robots. Let's go through an overview of what we're going to cover in the talk. I'm going to give a really high-level overview of some of the goals and the thinking behind the program that we're building, mostly as context for the things that we decide to measure and how we measure them. We're going to look at what we decided to measure and why. We're going to look at the tools that we looked at, what we implemented, and the things that we built. Then we're going to take a look at what we've been able to learn from using those tools so far, and then where we're headed next with measurement and what we hope to use and build. Putting Indeed's open-source program together, we really spent a lot of time trying to align the team and a lot of thinking around a few core values. I don't want to share the whole doc today, but there's a couple of things I wanted to copy out. One of them is obviously that open-source is more than software, and this informs how we measure things because it means we want to look at more than just code contributions when we're looking at healthy open-source activity. We will meet you where you are. No matter where you are on your open-source journey, whether you're just taking your first step, whether you are someone who contributes on a daily basis, whether you're someone who made a contribution or a couple of contributions and had a negative experience and doesn't think it's worth their time, wherever you are, we want to come meet you where you are and help you onto your next step in the journey. Then that predictable long-term support is the ideal. Drive-by contributions on projects are great. Drive-by contributions of sponsorships and to foundations are also great, but the ideal state for both conferences, for foundations, for projects, for anyone is predictable long-term support, not just blips of contributions. With these core values in mind, we set about with this one goal, to build a culture of active and recurring open-source participation within Indeed. We want Indeed engineers and even people outside of engineering to be actively participating on a recurring basis. I called out in the abstract for the talk that you encourage the behavior that you measure, which calls back to Peter Drucker's management consultant, legendary person. If you can't measure it, you can't improve it. This here is Peter Drucker. Actually, that's Lord Kelvin. Lord Kelvin, you can trace Peter Drucker's comments back to a famous quote from Lord Kelvin. I often say when you can measure what you are speaking about, it expresses it in numbers. You know something about it, but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind. It may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the stage of science, whatever the matter may be. Peter Drucker's comments, not particularly new, they go all the way back to Lord Kelvin. Let's take a look at what we decided to look at as a contribution. What are we going to count? Before we get into what we decided to count, let's talk about things that we decided not to count and things that we think make bad metrics in and of themselves. Lines of code is one. It's an easy thing to count, but easy things to count tend to be low-quality metrics. If you count lines of code, you're going to encourage the behavior of creating lots and lots of code, not necessarily any good code. You might unintentionally encourage the behavior that people are not writing very dense code, and so maybe the code will be a little easier to understand, but if the thing that you're measuring is lines of code, people are going to make lots and lots of code regardless of the quality. We also didn't want to count just individual contributions for the purposes of determining program success. If the thing that you're highlighting for the company is individual contributions, then you unintentionally incentivize a couple of bad behaviors. The first one is people who are prolific contributors will find other people who are prolific contributors, and they can turn it into a kind of competition, and this can be tempting in the beginning, especially a few years ago as gamification was a somewhat more common concept. Let's put up a leaderboard and see who's making the most contributions. Well, if you have really prolific contributors, people who are making 20 or 30 contributions of some kind today, if I show up to the company for the first time and the leaderboard has someone who's contributing at that velocity, I'm unlikely to want to jump in and play the game. There's just no way for me to catch up. Counted contributions, if it encourages competitive behavior among engineers, it can actually discourage new contributors, and it also puts the onus on projects because projects can then sometimes receive low-quality contributions as the people are trying to push their numbers up, and that isn't a burden that the company bears or that the individual bears, it's a burden that the receiving project ends up bearing as they have to push back contributions that are lower quality. There's some other considerations that you should keep in mind when you're looking at what you're deciding to measure, and one of them is whether or not you're going to share raw numbers inside the company, outside the company. And one of the values that I didn't list there is that we really try to default to open out everything. Our conversations are open. We try to be public about our metrics, at least in the confines that we can. But if you come back to that idea that competition will discourage new contributors, if you're sharing raw numbers widely, it is a thing that can affect your culture in ways that you might not intend. We also have to decide how you're going to account for personal projects and what that actually means. I, taking off any kind of Indeed hat and putting on my own hat, I think the division between company time and personal time in many tech companies is very artificial at best. And trying to figure out which projects happen on company time, which projects happen on personal time, and which ones actually are related to company work, or which ones might be less directly obviously related to company work, right? It's a thing that you have to work through when you're considering what to measure. So what we landed on as far as personal projects and what company-related contribution means is in the beginning we're really going to try to solve this problem one way or the other. We consider if you're making contributions to an open source project on your own time that are going to improve your collaboration skills that are going to make you a better collaborator internally and we're not going to try to filter those out, at least in the very beginning. Let's start very broad in what we're measuring and then as we gather more data, let's start to refine our metrics. Take a drink of water. So what we landed on for the main thing that we were going to measure is this idea of active recurring participants. And I'm going to unpack this. Let's go back to that goal that we have within the program. Active means that they have triggered some kind of an event that we care about. And when Danny is digging into the tooling, she's going to talk about what those events were and what those events weren't. So active, they've triggered some kind of event that we care about. Recurring, that means two or more days of activity within a given timeframe. Right now we're looking at this over a quarterly basis. It's not a terribly high bar, but that is the thing that we want to grow. Recurring participation. And participation means a broad category of events. So more than just code contribution, participating in code reviews and comments and so on. Does anybody, this looks familiar to this graphic here? Some seeing yes, some not seeing, okay. So this was rolled out, I believe in the last six months or so, on GitHub, it's the new activity indicator. And it gives you an idea for what kind of activity that you're involved in. Obviously we care about pull requests and commits, but we also care about the people who are participating in code reviews and issues. And this is I think indicative of a broader trend in the open source metrics community to recognize that just looking at code contributions is not the path to success for open source projects. Now before anybody starts getting ready to go collect stones to throw at me as I go through the project, I understand that this has been very GitHub focused so far and that open source happens in many places that is not GitHub. In fact, I have a talk about why you should not evaluate candidate during the hiring process based only on the GitHub profiles that centers on this very thing. In order to understand why it's very GitHub focused for now, I want to talk briefly about the difference between precision and accuracy. It is not important to us that very precise numbers that reflect all the contributions that are being made. What we want is a general sense for which direction the trend is going and is that trend, do we feel like we're more or less accurate? So we started measuring with GitHub, we know we're not collecting everything and in point of fact, there's a friend of mine, Cedric Williams who works a bit in the intersource community, sometimes talks about the concept if you went across the street to Cali Burger and said, how many French fries did you sell yesterday, individual French fries? They would say, I have no idea. That's kind of a ridiculous question to ask. But you might be able to say, how many pounds of potatoes did you go through yesterday? I think it's like, well, you know, 2,500 pounds and you can say, okay, well, 2,500 pounds of potatoes, maybe 12 potatoes to a pound, maybe a dozen and a half French fries for potato. Okay, you can get approximately an accurate guess, right? And as you reproduce that approximately accurate guess over time, you're still going to tell, are they selling more over time or less over time? So when it comes to non-GitHub contributions, we wanted to provide some mechanism for people to report that they were doing GitHub activity, open source activity outside of GitHub. And so we did what I think any reasonable multi-million dollar to put a Google form up and asked us to tell us more about their open source contributions if they weren't happening on GitHub. And this allowed us to do a couple of different things. It allowed us to determine if people were eligible to participate in the FOSS Contributor Fund, which I'll talk about in a little while. But it also gave us the ability to say, okay, now as we see, if we see a bunch of things come in that are happening on BitBucket, we know this is the place that we need to prioritize our next piece of work. There's a bunch of projects that people are contributing on GitLab or a bunch of projects that people are participating elsewhere. We know where to start, rather than trying to pick the thing that we think is going to be most useful to us next. So I'm going to hand it over to Danny for a little while. She's going to talk about the tools that we looked at, the things that we implemented, and then ultimately what we decided to build. An interesting challenge in that we're measuring something very different from what our open source programs are trying to measure. This is also an opportunity because that means it's an opportunity to contribute back to the open source community and it makes people think about this other way of thinking about contributing. Which is that existing tools measure the open source project health. What are our projects as a company and are people interacting with them, are people using them, things like that? It's Oregon Repo Focus. We however, at least for now, are more concerned with indeed employee contributions. Are we giving back to the projects that we use? Are we giving back to the community? How can we help the open source community essentially? And that is a more user focused thing to be looking at. So there are a number of different tools. This one is a list that came from the to-do group of various dashboards and crawlers and ways to get get contributions. And unfortunately they're all basically what we were talking about before. They're org and they're repo focus, not user focus. Getting the problem with trying to use those projects as they are for us if we're worried about user contributions is that if you're getting them, they will get all the users for an org and for a various repo, all the users that have interacted with it by doing events. But that will, for example, miss some of our indeed employees that are contributing to open source but not to indeed repos. On the other hand, it will also get us a bunch of users who aren't indeed employees that is not what we're trying to track right now. So we really needed to have a tool that can look at all of our employees and whether or not they're contributing. So the question is there were all those ones before can we figure out a way to adapt those tools to our needs that we're not creating the 15th competing standard. So we looked at some things. Let's see. So we decided on using the GitHub crawler for Microsoft to get our contribution data. As Dwayne mentioned, GitHub is not the be all end all but it is a place where there are a lot of tools that are made for it because it has a very robust API and it's where a lot of the contributions are happening. But Tergia also has a really great solution that looks at more than just GitHub but for us right now it's the easiest to do the GitHub crawler. A large part of that is just because up until very recently I was the only engineer on the open source team because we're a very new team and as you know, hiring engineers is hard and I know full stack JavaScript and I'd love to learn Python but we wanted to get some information so it made more sense to start with the crawler. What it does is it gets information about events on GitHub. Like all the others it is org and repo focus but we were able to adapt it to actually crawl through a user and that user's event. However, there are some pros and cons to using this crawler. Some of the positives are that it is a really expendable project for us to be using because right now we care about only our user events. Very soon we will also start measuring the things that everyone else cares about the org and repo health. It's one of the things that we care about and we'll be able to use this tool to do that very easily since it already does most of that. Another thing that's really nice about the crawler is that queuing and rate limiting are all handled in terms of using the GitHub API you have to get a token of course and it can do so many requests per minute which right now we're not hitting but when we're doing more we will. And the other cool thing about using the crawler is that I'm able to contribute back my contributions to the open source project so that other people will be able to also crawl user events. Now the negatives are that it being a large robust code base means it's also a large robust code base that's difficult for a newbie to figure out where things are how they're working and I've gotten to the point where it's working, it's doing the thing and I still know that it could be doing it a little better because sometimes I still want to tweak and make better before contributing back. The other negative to it is that one of the really cool things that the crawler does is it uses the webhooks from the GitHub API to see when a new event has been made and then and only then does it crawl it except that the GitHub API does not have webhooks for user events. It has webhooks for repos for orgs. I believe this is because of privacy concerns. I'm hoping that maybe we can convince them to create some webhooks for users. If not I'm starting to look into either using eTags or they do have an if modified header that you can do a little check and see like. If I am going to look at githubapi.com slash user slash danicella slash event, has anything been modified since the last time I looked at it. There are ways to theoretically look at it but they won't come out and tell the crawler like hey, you should crawl now like the webhooks do. There was definitely a moment when I was talking with the crawler people and the issues about what I wanted to do and they were like why are you using the crawler? You can't use our webhooks. We were like that's true but you do other cool things so that's why we are. Before we figured out how the crawler works as I said it's a large code base. We did just want to get up some numbers. I started at the very end of August and we had Hacktoberfest for October so it was pretty important to be able to get something there also when you think about quarterly things. You want to have some baseline metrics. So I basically just wrote some code that pokes to get hubapi for user events and then we filter it by the events that we care about. And then as I said before we just put that info into a Google spreadsheet. So we were able to look at it, get some basic metrics. What's kind of cool is that if you are just wanting to know some basic information that's really all you need to do. And I'm going to clean up my code for that and open source it so that's an option. For example, one of our initiatives means that we just need to know who has contributed over the course of the given month. For that you don't need the whole big solution that we created. You can just poke the GitHub API with the basic code. I wrote the interim dashboard code and it will give you that info. This was super useful just for counting Hacktoberfest. So I mentioned that we are filtering through the events once we get them. So these are the ones that we're measuring. Any sort of comments on various things, on issues, on pull requests, different things. We're measuring the pull requests, the issues in the code reviews. We're not measuring push events for two reasons. One is that often, probably even most of the time, push events are two personal projects. Like if I've got something up on GitHub I'm just going to push to it that it's my own thing. I don't want to be counting a few of those personal practice projects as possible. The other reason is that it's really not good open source hygiene to be using push events. So we're not counting them. So once we had that contribution information we needed to show it somehow. So we tried a project called Measure Off that's on the to-do list and it was also organ repo focused. How to make it work. It was going to be two completely separate paths that the code would take. Whether you were looking at an organ repo or looking at a user. The dashboard similarly would have two different parts. It would be like a flash repo and a flash user. It would have been really confusing. I was okay with it but when I talked to the Measure Off team this is how it seems like we're going to be doing it. They were like, we love what you're trying to do but that's not what our tool does. They were perfectly happy to let me fork in and do whatever I wanted. But specifically if we're doing all that work we wanted to be contributing it back to open source. It's an important thing in general if you're contributing to open source to ask the people whose project it is do you want this? They asked them and they said I'm not really sorry and I was like that's cool, we'll do something else. So we did. What we decided to use in our case was something that is specifically an Indeed project. It's called Imhotep and what it is is it allows you to build and query large data sets and then you can build tools for analysis and dashboards and things like that. Indeed it even came with a dashboard maker. This is a really big robust solution that made sense for us because we already had it set up at Indeed. Once I stopped trying to throw things into measure and just was like okay let's just do what Indeed is doing and now if I have any questions I can ask Indeed engineers it was up in no time. So that was pretty cool. It's something that you could use also it is open source but it would take a lot of work to get it set up and we're happy to help with that. So we made two different dashboards with it. The contributor dashboard for individuals and the aggregate dashboard for the program. And so the first one the individual one it provides contribution insights to a person which is nice for them, people love the little you know everyone always loves gold stars so you can see that you've made the contribution, you can show it to people it's also really useful for quarterly reviews and a number of our engineers have been have let me know that they're very glad we had that. Indeed is very data driven when we do our reviews and so being able to have a little like see this is what I did this is something you should care about is really nice. And then the second, oh and then this is what it looks like some of the things that it shows are weekly contributions total contributions you can see kind of the bottom of it the blue line is actually everyone at Indeed and then there's another line at the bottom that's an individual you can kind of see where you're at and as Dwayne said we don't want to be promoting people competing but people also do like to have a sense of where they fit in so we found that useful and the other thing that it shows which you'll be able to see a little bit on the next slide is there's a breakdown of every repo that you've contributed to and what sort of what sort of contribution a pull request or an issue comment things like that and at the end if you want to come up I can show you the dashboard in full there's loads of room on the slide for the whole thing and make it so legible the aggregate dashboard is just used by the open source program office and it provides us with program insights and it's useful for improving the program it tells us are our initiatives working essentially as Dwayne said we default to open on our team so there have been people who have asked me various questions that are answered by this dashboard and I've been happy to share the link with them and because we default to open which is not something that we're going around being like hey everyone look at all of these numbers and start comparing yourself so this one tells us all contributions contributions by month which has been super useful for figuring out how things are going with our initiative which projects you can kind of see at the bottom that little bit and then active recurring participants which Dwayne mentioned which is not currently on there but will be very very soon just because of the way the tooling worked out and that's one of the most important ones ok so what's next we are going to be adding other online code repositories like Bitbucket and Apache and stuff as soon as we can and also organization tools like JIRA and Slack anywhere that people are doing things that are helping open source projects and as Dwayne said it's not just the code design is important program management is important legal is important as much as we can figure out how to track any sort of contribution we want to put it in there as possible and of course the other reason to track everything there are we even already have people being like my stuff isn't on github and we're like we have the form and they're like not enough and we're like we get it soon soon soon people are also very nice they get that this is the one but we want to get it in as soon as we can so that's the first thing we're looking at adding soon another one is we mentioned we're not counting push events however the same way that if I have a personal project I'm likely to just push to it a lot of indeed engineers push to indeed open source projects it's not ideal and we kind of give them a little depth about it but it is what people do a lot so we're thinking about adding that in because it is still a contribution to an open source project we'll see as I mentioned this is the metric that everyone else is currently measuring and we want to pay attention to that as well we are looking at having some projects that open source projects the community will be excited about and doing more filtering of events so the question there is do some repos have more weight than others do we care more about contributions that were made to a project that indeed is using versus one of our most prolific contributors does a lot of work with a home automation repo not really helping indeed but it is still open source and that's something that we care about so figuring out if we're going to weight those differently or not and we want to as I mentioned stop measuring a user's personal project so it's not though as simple as am I contributing to a repo that's under my name because I could have made a tool that other people are using so we're going to look at things like are other people forking it are other people contributing it to it things like that so we can tell whether it's just a personal project that you happen to have up on github versus an actual open source project and then the last one is we might put in a toggle so that you can on the dashboard actually look and see what does this look like with only indeed projects without indeed projects with everything just be able to look at different factors now I'm going to turn it back over to Dwayne to talk about what we've learned so far there's a thing I really want to emphasize about Imhotep as the solution to the problem here it is a large tool to solve large data problems and if this was the only problem that we were going to solve with it it would not have been the right solution to use what made it one of the things that made it such a desirable solution was not just that it was well understood by people at Indeed who could help us implement it but it spoke a language that was well understood kind of across the organization it is the same tool that we use, for example to get insights about A.B.Test that we run on the site it is the same tool that is used to figure out if we make a change to something what was the actual end impact on revenue and it contains a vast amount of data that is used to answer other questions so by using the tool that already existed and was well understood within the company to answer the same questions but about open source we didn't have to do a whole lot of education around the tool itself people could just provide a link to a query and there it made sense and everybody understood exactly what that looked like and what that meant let's say I have Gilbert says we send things out to the people who contributed and so of course our community manager was like I really don't want to really find everyone's address can you do that programmatically I totally can because our information is in Inhotep which is the same place that our employee information is so I can do essentially a join it was super useful it was the right solution for us because of the constraints that we were working in but I would probably not encourage anyone in the room or anyone outside the room to build a solution on top of Inhotep just to answer this constrained set of questions there are much easier ways to get there and much more robust tools for that and another thing that I realized we were going to add to the slide deck and then forgot to was the problem of this list of users like what is the list of users that we care about right ultimately that means what is the list of GitHub IDs that we care about in this case now the Batergia lads in the room here already understand that managing identity across different places where open source is happening is a complex problem even if you're only looking at one solution GitHub and trying to figure out the correlation between an individual's corporate identity and their public GitHub identity GitHub doesn't make that easy for you unless you give them lots of money and there's no commonly used way even across all of the open source program offices to solve this problem and to get at this was as simple as taking the list of users in the indeed end org on GitHub that would be fine but there's not an easy correlation there either we don't force people into that process of joining the organization on GitHub so they've self registered they self identified their GitHub IDs the ones who want to participate in the program and now we have a list of end users NIDs that we care about that don't correspond to an org or a repo or anywhere that we want to look at and then we look at the publicly available data and using that let's talk about what we've learned so far so the first thing that we learned is that we had a couple of outliers they were very very active and when I say they're very active I'm not talking about 10 acts I'm talking about 100 acts like these are people who based on the group of events that we were paying attention to were 100 times more active than most of the other people that we were looking at these are heavily involved maintainers of very popular open source projects and it ended up being problematic in a couple of ways let's come back to that whole idea of competition discouraging new contributors again if we highlight numbers of the users across indeed these highly active outliers are going to be discouraging to new people or it could unintentionally set the expectation that this is what it looks like to participate in open source hundreds of events a day maybe for some people but definitely not for others we kind of had to reset ourselves because we were looking at this and trying to figure out how to account for everything we had to come back to the idea that you don't build for edge cases at least in terms of this particular solution if we wanted to be very precise we would have to include all the edge cases we want to be more or less accurate and so the outliers they don't particularly need our help they are already regular active recurring participants and making them more effective we want to help them but they don't seem to need our help and so we didn't need to build something that would take into account those edge cases the second thing is that we expect that the company who have never made an open source contribution and helping them get their first contributions made and we are also going to integrate into the onboarding training to catch people as they are coming in the door and similar learning mindset to see if we are helping people get acclimated and into the idea of contributing open source if we are creating new contributors for the first time I think that is a really great outcome for our program and then we want to pay particular attention to are we actually sustaining the projects that we use and this is going to mean and I am looking over here at Manrique this is going to mean marrying our open source compliance tool chain to our metrics and contribution measurement tool chain because there is not a solution that does this on the market right now there is no one thing that can look at a report from Black Duck or Sonotype or Palomita or SNCC or White Source and say ok here is all the things that you are using that we know about and also has visibility into the projects into which you are making contributions because if we can put those two things together then I can look at the report and I can say hey we are using this project in 2000 different products and indeed we have no contributors that is a place that we want to focus and encourage contribution and this I think is really the long term vision and the long term key to driving programs like this to help drive sustaining contribution into the projects that we use so quick review and then we should have 10 minutes for questions I think you need to start with values first and your goals second and then you get to the tooling when you need it right if you need to be very mindful about what it is that you measure and how it is going to be used that aggregate dashboard only used by the open source program the minute somebody comes to the program and says I want to see contribution numbers of everyone on my team so I can figure out who is doing better than the other like we have to have a long conversation about how these metrics are being used know why before you are building the how we have very specific things that we want to go after again growing that active recurring participation it is tempting to just look at the existing tools that are out there pick one that you think looks good start measuring things but if you don't know why you are measuring it or what you are going to do with it then you are still sort of flailing around to start with what exists again there is a lot of stuff out there it might not solve the solution for you but at least if you start with it you can look for opportunities to give back to the community and you should remember that the measurement is not the goal let's come back to Uncle Calvin over here Peter Drucker says you can't measure what you can't improve measure is the easy part and it is the part that everybody gets stuck on improvement is the goal if you are measuring it and not using the things from your measuring process to learn and improve on the work that you are doing then it is probably not worth it to measure in the first place and with that thank you for coming and listening we will happily take questions and we have got 10 minutes or so to stick around yes here I am curious how we can measure the effectiveness of COVID-19 that we are going to deal with though right now the events that are out there are full requests approved full requests denied and especially as we happily measuring the amount of time spent on COVID-19 and whether or not we are growing or encouraging COVID-19 that provides substance resistance versus rubber stance alright I am going to try to roll that up into a repeat for both the video and for everything else but as the maintainer of an open source project is a member of a community of an open source project one of the problems is that project maintainers have to spend a great deal of time reviewing full requests and it would be great to have some ability to determine when those are effective and when they are not and also helpful to grow people into the community who can take that load off of the maintainers so that they can maintain the project rather than just do code reviews is that fair enough a thing that I think would be useful to go after and I am going to look back at Ranrique here because I had a conversation with I am going to say your boss but I don't think he was your boss at the time about five years maybe four years ago on this the thing that I would really want to dig into there is for a given list of users over time are there pull requests taking more or less time to get landed so is it not about the time that it is open but how many iterations are involved in the pull requests now for a given user between two given users that number is going to be practically useless because no two pull requests are going to be the same you can't look at lines of code to determine if it is more or less complex but for a pool of users over a pool of pull requests I would expect to see that people who are getting better at reviewing pull requests the number of iterations go down over time in aggregate maybe that's right maybe that's wrong but this is the thing that we keyed into on the idea of how do you measure mentorship how do you measure someone's ability to be an effective measure if one project has ten people that are reviewing code reviews and you assume that they are just getting randomly assigned code reviews if one person is able to consistently get them in with three fewer iterations that sounds like that might be a place to really dig in and see if that is really a core competency if there is something else in play and that I think calls to the final thing I would say there that none of the metrics here in any of this will answer a question they will just tell you where to dig I think that's what I would have to say other questions yes we talked about GH archive as a data source and I really have gone back and forth on this to an individual showing up at GH archive there is no easy way to know it's going to be here tomorrow at least when we looked at it it left the impression that it was some person's project and if that person died or ran out of money or changed their mind that it could vaporize the next day now I have since learned that Google is involved in this GitHub is involved in this there are people behind it that give it more credibility than it seemed on the surface but then I actually had a conversation about whether or not to use this as a data source and ultimately decided no and I don't know that I would make that same decision today but I don't know I know that filmage out of the Adobe office the metrics work that he does all of it goes into GH archive a number of other people also look into the archive as well so it's hard to have people use GH archive it's hard to use we had already made the decision not to have all the tools based around it you had a question as well so the question was did we look at the tide lift because they are working on something similar so I know about tide lift I know about their model who don't their approximate model and if Luis hears this he might jump on me and correct me but the approximate model is we are going to take a group of open source projects we are going to offer support contracts on that group of open source projects and we are going to make sure that the money from those contracts goes to the people who are maintaining them and we are going to incentivize them to perform good maintenance work on the project it's much more complicated than that but that's essentially the model interesting model I think there are a lot of different things that are being tried in the world of open source sustainability to try to address the perceived problem that's there I'm interested to see how it works out it's but it's not something we would implement, it's something we would purchase from them if we wanted to get support from them my personal goal and my personal drive in the way I approach open source programs is that I want companies to be involved in the projects they used not just because altruism is great and I'm a very altruistic person I want that to happen just because it's good for the project but it's also just smart for the companies if you are involved in the projects that you use you can see problems that are coming down the pipe before they land and impact you you can help make sure the only way to make sure that project is going to be sustainable long term is if you're part of a sustainability solution for it tidelips model might help solve this open collectors model might help solve this and models like the fosk contributor fund that encourage both participation and donation into those projects may also help to solve this I'm excited that there's a whole bunch of different solutions out there and I think it means that the industry is taking it seriously and then you had a question in the back what is the business value for our company to measure the open source contribution of employees in the company the only so this is actually an interesting question and I think you may have nodded as well because you might have intuited on something we had one incident where we sent someone their individual contributor dashboard and they said please forget everything you know about me because they found it creepy right and that was you know we kind of acknowledged that that might be a possibility but it caused a little flat flooded so we forgot everything we knew about them and his issue was I only contributed on personal projects and having my company have visibility into that felt weird right it was publicly available data we didn't see a problem but we honored his request the business case for us measuring this is really around driving the wider program the company itself does not really care about the number of contributions the individual makes or outside the legal implications what projects they're contributing to as long as they follow good hygiene and good policy they're staying away from sort of the core IP areas identified for the company and that they're contributing consciously but the goal is to again drive wider participation to grow employee collaboration skills exposure to technologies and to help make sure that we're ahead of these kinds of problems that I was talking about earlier so it is really thought of more as an engineering culture ad as opposed to anything else we are literally the only ones who use the numbers outside of individual to manager conversations do I think it's possible to automate software management I think anything is possible dot dot dot that's probably a conversation we should have after the talk were you just giving a thumbs up or are you doing that because I think we're at time thanks for the great questions everyone I've got a little bit of time Danny have some time that we can take around as well thank you it's important to measure important to measure contribution like the health of your projects sometimes stars just don't cut it giving back to the project that's something no one else is measuring it's something that's actually kind of difficult to measure with the way they get to have ideas yeah even if you had a number of users a number of commits a number of merges one merge isn't really equitable to another merge or comparable rather we have some baseline numbers then we do things like we promote October Fed be like oh we really promoted this the numbers went way up November we didn't do anything and the numbers went not as far down but somewhat down and then we just went for bullet points and they went back up and even more so we just keep trying different initiatives and we're going to be giving classes and about contributing and things to try and get the numbers up and up and up that's fantastic there's actually I think a lot of a lot of organizations that can really benefit from a packaged open source program dashboard sort of the hell you know where we're using it, where we're contributing to it what's the activity, what's the velocity how long we have an outstanding issue almost the same way in which you'd run an internally developed proprietary piece of software but then even a little harder maybe to measure some of those intangibles about influence and health of the community and velocity and chaos and get up crawler that you were talking about and even for security the truffle hog or a number of things that might just crawl your repos for vulnerabilities you might have is that mostly for attribution for that recognition and credit for that developer or for different purposes of just measuring the company's overall contribution it's a lab to nominate a project and anyone who has contributed in a given month can vote on which open source project gets to be about 10,000 per month and so it of course has to be there are a few caveats that have an LTI license that have to be a way for us to give them money it can't be a project owned by an Indian I think those are the main three probably up do they have to be projects that are maintained by does it primarily maintained by your organization? no, no look at our react, it's still amazing we're all worried about that we're worried about are we giving back the project to the developer and this is is it Uber? oh indeed very good you just said lead by example is that what you just said? yeah now I totally interrupted your conversation I did it well entirely to kick off the next talk I guess so I'm not here today representing them a company that I work at full time is SolarWinds a monitoring software company but I'll disclaim it again not speaking on their behalf today but share experiences over the last couple years of trying to have established an open source program office and this is your opportunity now to not say if you don't want to say you may or may not find this insightful but to that point it took me about two years to form an OSPO an open source program office at my current company I'll repeat it of which I'm not here representing today but do consider that open source program offices are growing in their importance and that we'll see many many more of them popping up some of the experiences I've had the environment in which I've had these experiences have been in a company that has about 50 products products that are sold as a service, products that are sold as shrink wrap software delivered on premise products that are taken to market directly to end user and products that are taken to market through channel so pure software company hundreds of millions of lines of code of software so and have products that are using you know comprised of like 90% open source and other products that are comprised of 90% proprietary code and so and then everything in between open source happening in this environment and I don't know if this has been the experience of some of you but certainly for me when these two terms come together open and source that occasionally has the effect of producing an almost physical allergic reaction to those within our legal department being just very uncomfortable with what that means to the company and how they perceive the company's value how they perceive how much intellectual property is within the proprietary code that we have also how much just the heavy consumption of an ingestion of open source software and whether or not we are complying with those licenses gets people pretty animated or allergic hence the creation, the formation of open source office open source program offices are all the more important so I'm here today to share those experiences with you and not necessarily tell you that this is the one way and the cookie cutter way that this should be done but rather this is how you might do it. I'm going to reference the to-do group I'm going to reference the to-do group is an open source group a collection of companies that engage in open source communities and have put together a lot of their experiences and shared them I don't know if it's a sub-project to the Linux foundation but it's certainly associated with the Linux foundation I'm also going to reference a survey that had been done between the new stack, the Linux foundation and the to-do group and so my name is Lee Calcote this and other talks like you can find at CalcoteStudios.com so if you don't suffer enough today you can go and suffer some more there for some other recordings get a particular focus right now technologically toward service meshes and there's a recently published e-book available here in case that's your thing and for some of you I know it is so reasons why an open source office is needed to be created well there's a number of reasons within there some being for speed for pace of innovation to have influence in those communities in open source communities for compliance I think I think one of the ways to explain why you'd want to form an open source program office if you take this tweet here from my friend Nithya who recently established a small open source centric conference out in Philadelphia works within the open source I think stewards of the open source program office at Comcast it's great that she formed this put on this event but why did she do it and interestingly for this event this is the short description of her event and it says she's putting it on to help connect innovation and drive technology forward speaks in large part as to why you'd want to create an open source program office why it is that open source is so centric to really any digitally transformed company any company that has that software is used at the core of their business now most of you or all of you have probably heard of software eating the world certainly not something that I had said but since you're at this conference you're probably also aware that open source is eating software most major areas of innovation in software are happening in open source and in case you're living under a rock cloud is eating open source lots and lots and lots of the cloud offerings are based on open source so open source super important to many organizations be to more and more certainly for technology organizations and like I said any that have been digitally transformed if software is important to your business open source is important to your business of the benefits for creating an open source program office again this is from a survey that I said that I would reference a couple hundred between two and three hundred people went through and took this survey from various organizations and some organizations that have already established open source program offices some that desire to and some that have said that they never will or they don't have plans to irrespective amongst all of them the top benefits that they noted were awareness of how it is open source is being used within their by and large the focus of that being how open source is being used in their companies or in their products in their offerings or in delivery of their services they think that if they have got an open source program office that they benefit from development velocity the developers can work more quickly they've got an understanding and structure around when they can contribute externally when they can receive contribution how they can engage in community how they can represent their company or not and then to the extent and then the program office often times on compliance and ensuring that the legal rules of consuming or contributing to open source is complied with as well as them to be influential in the open source communities that are important to them what kind of an interesting take away here is that that open source is important to developers developers don't necessarily like to do things more than once don't necessarily like to repeat themselves if they're going to do it once many not all clearly would like to do things in the open and be able to leverage that wherever they go be able to assign attribution to the works that they've done be able to show off their works be able to have people reflect on them and see the things that they've done not necessarily have their works held behind the firewall so to speak that's certainly attractive to having an open source program office can be very beneficial to attracting talent to attracting developers and engineers so interestingly the respondents to the survey that already have an open source office are not really don't really consider that a top benefit is talent attraction which is kind of funny because they already have much of the talent that they're looking for because they've got the office in there they've brought in folks organizations that haven't established a program office consider that doing so will help them attract talent so I get kind of a chuckle out of that as you go to form an open source program office you need to consider part of your strategy in doing so and from my perspective there's kind of five C's to formulating an open source strategy and that is about consuming, complying having community receiving and giving contributions and considering how open source is potentially competitive to your offerings and so addressing each of these five C's is something that a well-rounded open source strategy needs to do it's not all about compliance that also if you consider these five C's I consider that there's a particular path to mastering open source and that an open source program office can help with that that most organization's journeys start with consumption that they start for needs of either speed or not reinventing the wheel they go and consume some open source they use those as either tools or they ship them in their products or they use them in the delivery of their services and as they begin to consume open source they probably very readily need to begin to comply with the licenses that are associated and so the journeys for most sort of start from bottom up they consume, they comply maybe they do maybe they begin to perform a little bit of inner source which means that they might have code bases internally that they govern and steward much like many open source communities govern and steward their projects companies might do inner source both to benefit from the flexibility that that provides the flexibility of how developers are assigned to projects they might do it to get ready to engage more earnestly externally and kind of understand the mechanism, the mechanics of how to how to engage in communities like that and then some companies ever graduate from these first two rungs and that in part, that in large part depends upon what's core of their business and whether or not contributing to external projects is important or hosting their own and receiving contribution is important that they do, I would consider that their next step they need to consider whether or not open sources if open source projects are competitive to their offerings how are they going to either complement open source projects play within those ecosystems or maybe just outright compete with them all throughout here there's a community whether that community is internal or external community is core to the open source way recognize that companies that software companies, those that have software offerings source code from a variety of places it's really kind of three places but the combinations of those are kind of interesting so it may be that the products or the commercial offerings that they have are just pure open source that's all that it's comprised of or maybe it's a bit of proprietary software and some open source software maybe it's third party commercial software so not necessarily open source software but software that they've licensed and OEM'd or licensed and incorporated in and so it's a combination of these three types that they might meld together and create a product out of this is I had mentioned that for the company that I work for of the 50 or so products that we have the gamut that we span it goes from very little open source in our commercial products to almost nearly entirely open source in the products and for on average most software products today have a healthy bit of open source in there and this is really measured in terms of like lines of code so as you go to address each of these five strategies for consumption there's a bunch of compelling reasons we highlighted a couple of these but it's to move more quickly to speed up the delivery of your solutions it's to not reinvent the wheel to share the cost of development of that software there are some projects that really only make sense done in the open maybe that's for compatibility reasons there's so many open source projects maybe it's to innovate I mentioned before that most of the innovation within software is happening in open source ecosystems in open source environments it's to maybe keep pace to attract talent to be influential as I said before all of these are they'll pile up to reasons why it is that companies, if they want to be competitive if they want to keep pace they're likely at least minimally going to need to consume open source if they do they're going to need to comply things that you need to address as you go to comply with open source is that not understanding which licenses are being incorporated in your projects may mean that you get delayed in shipping your product if you've got a license that's incompatible or that you consider to maybe copy left you need to understand whether or not that means that you'll lose some of what you consider your intellectual property if that license forces you to publish the work if you you might find that you're doing a bit of rework if you use a package that's incorporated into your product and turns out that license isn't compatible and you're not going to use it then you've got to go do some rework or if you ignore it and you ship it and later on get sued for not complying with the terms of the license it might be embarrassing to you you might have punitive damages so some of the goals that you need to that we had set forth as we went to go establish what it meant for us to comply it meant that whether we're shipping the product as a piece of software you download or whether we're offering the product as a service that not only were the packages that were incorporated into our software that those were using licenses that we approve of but also that the packages that we're incorporating in are secure at least with the world's known published vulnerabilities so it's both license compliance and it's also making sure you've got secure code so you need to make sure our goals here made sure that we were upholding those licenses that we're tracking vulnerabilities that we're also giving the appropriate attribution to those that are contributing to the projects that's both engineers internally and engineers externally so that means we need to wrap a process around it and part of that process was to ensure that we were educating internally on open source that we acknowledge that there's in fact a difference for many of the open source licenses depending upon whether or not you were shipping software and distributing it if you're redistributing it or if you're hosting as a service so there's different licenses that apply to those irrespective we wanted to try to hold all software to the same standards we also wanted to empower the engineering teams themselves to be as self-serviced as possible to make even, for the most part I don't think I've ever heard an engineer say that hey this is the fun part of writing software is focusing on what license there is and going through and trying to identify all that and fill in the forms and track all this that's generally not what they're excited about they want to write some more code so to the extent that your process can facilitate them self-servicing and make it as friendly and easy as possible those are part of our goals we wanted to streamline that execution we also wanted to make sure that we were counting for the fact that there's third-party license code that gets incorporated proprietary code and open source code that gets incorporated again the inner sourcing that companies may or may not choose to do so maybe they can establish an open source like culture inside their organization many organizations have yet to cut their teeth on participating in public communities so doing it a bit internally first maybe lets them work out some of those kinks or kind of come to understand it it's a little bit of a chicken before the egg maybe they want to go out external and contribute a little bit kind of play within the communities understand how they work, see a few of it bring it back in either way they can benefit from some of those efficiencies they might be able to standardize on tooling I don't know that I mentioned this before but the environment that I'm within hundreds of millions of lines of code that makes different types of source code management systems so Github and GitLab, SVN CVS, Perforce VSTS and then lots and lots of code in and amongst those so not even the tooling is standardized so I think there's a potential benefit of practicing some inner sourcing that in order to do that effectively if one engineer wants to go help advance a given component of code and they're using TeamCity for continuous integration in this organization, in this business unit in this team for this product they're using Travis or CircleCI or this language or that language or this type of repository that of the source code management systems that I just mentioned they're not even all Git based so even just standardizing on something like that can really help and it needs to be done to facilitate inner source hopefully part of inner sourcing then outside of establishing that open source like culture that also you begin to benefit from reuse and how many times certainly in larger organizations you find different teams creating the same capabilities and really it turns out half the time some of the biggest competitions that the teams have are each other like the internally who they've got to watch out for it's unfortunate sometimes companies actually do that maybe pit business units against one another and see who kind of let them race it off and see who comes out first but anyway that doesn't need to doesn't always need to happen they can certainly share and I think if they were adopting some of those open source ways maybe they would be sharing more so again I'd said that depending upon the type of organization you're within they never aspire to this third rung of contribution I think it confuses a lot of folks to understand that contribution means both maybe upstreaming some changes you've made in open source that you're consuming so you don't have to maintain a separately forked copy and float all of your changes that you can do the right thing both for yourself and being efficient by not having to maintain that and also in just being a good steward of the community or not steward of the community but rather being a good citizen in the community and maybe there's some good will that happens out of upstreaming your changes so contribution needs your strategy here needs to consider outbound contributions as well as inbound the outbound that you're giving is a lot less complicated than receiving inbound contributions and actually hosting a project and all of the things that come with that probably an easier place to start with with outbound is probably more natural place anyway if the reasons that people contribute externally most often is because they're consuming some open source project they either find a defect or they need to augment it a little bit to be compatible with add a feature or what have you and so they might start by contributing outbound which is kind of a nice organic way of starting it's the easier way of starting whether interestingly whether you're receiving contribution for a project that you're hosting or you're giving contribution externally you're probably going to run into or need to consider whether or not there needs to be a license agreement signed by those that are contributing code again whether they're contributing to your project or you're contributing to theirs you'll commonly see a contribution license agreement a CLA or a DCO a developer's certificate of origin a bit of different philosophies and opinions about the impediments that these present to people as they go to contribute and how what the reward is how much risk they reduce between them and so if you're not familiar with these maybe very quickly the DCO generally facilitates the process of ensuring that the person contributing code identifies themselves and kind of authenticates if you will identify who they are and as part of that also agrees to the fact that they've got the right to contribute this code so it's just code that they've written themselves and they're donating it to the project or they source it from a different project that has a compatible license and so they develop the DCO sort of addresses those two items by and large the CLA that type of license agreement takes a little bit further and also tip, you know, there's different agreements but we'll typically address things like intellectual property and copyrights who continues to own the intellectual property of the code that's being written things also like who has right to file a patent for that type of code lots of things to consider like things get much more hairy as you go to contribute again, either inbound or outbound whether you are contributing externally or internally or you're receiving contribution community then becomes important and how earnest you're engaging in open source means is an indicator of how important community is going to be to you, to your organization easy to get wrong, lots of lessons to learn from other open source projects lots of lessons that they've learned, also lots of things that open source projects are doing well if you are on the show floor here there's the cloud native computing foundation the CNCS, they have some very well to do emergent open source projects and their governance model and stewardship and support of those projects is probably a healthy example of how to get community right I've mentioned before competition whether or not you address, you have a strategy that addresses competition is entirely dependent upon your business but in the environment that I'm in we've kind of got two mostly competing schools of thought and my philosophy is and I consider that there are a number of open source projects that people will choose to use instead of our products and as we go to help people understand how these products are maybe better or maybe why they would want to buy these products is that the strategy there is to help complement the open source projects that are necessary to come in and try to displace them outright I think that's one approach but if that's not necessarily what's good for the customers and certainly why would you want to do that so go in and complement maybe fill in some areas within that open source project that are a bit weaker or don't integrate well into your product set so complementing is a great way of assuaging the competitive nature of open source projects just a couple weeks ago I'd seen a mail thread internal to my organization that said hey customers are asking whether or not our products are integrated with this open source project with this competing one in this case it was Prometheus Prometheus is an open source monitoring tool monitoring is centric to the company that I'm at and the product manager's perspective was well I scoured the mailing list I've looked for Prometheus as the keyword and every time it comes up really what customers are asking what customers are doing is like weighing whether or not they should go use this Prometheus open source project or buy our stuff from his perspective this customer that's asking for us to integrate we don't need to we just need to outpace this open source project and beat them by going deeper and better and that's certainly one approach to that I say we sort of with my corporate hat on and trying to raise money for the company but that doesn't mean that you wouldn't also want to have your software compliment that open source project and allow the customer to continue to run the open source projects but just augment them so anyway different strategies to consider companies so the role we talked about why you want to create an open source office why what I consider five C's that you're going to want to cover and address in your strategy we talk about the role of an open source program office it's tend to be kind of the center of the universe within your organization for all things open to provide a structure and a framework for addressing how and when you engage in either communities or use software of the survey that I referred to in the past that question was asked to a couple hundred organizations and interestingly there's a lot of aspects to the role of an open source program office some of the top ones here I'm going to talk about more in a moment but is number two is to ensure that compliance happens you know there's a long list but there's a lot of things to be covered it's actually ends up being the full time role for a number of people so an open source program office needs to be aligned with your business needs to certainly engage with your legal counsel if not be led by your legal counsel needs to be aligned with your product management you need to make sure that the way in which you are using or contributing to open source aligns with your product strategy if not then your open source program office isn't going to really reach its full potential you do a word of caution as you go to engage with legal counsel is that for the most part it's been my experience that those folks the role that they play is to minimize risk lawyers are risk assessors and what they want to do for their clients is minimize the risk that their clients have in this case being the open source program office or those that are engaging in open source it's easy to maybe overrevolve there so my word of caution is to make sure that you're striking the right balance the legal group may stifle innovation a bit that would be just the question of well if this is a cross functional mix of different teams that form your open source program office where should you land it what business unit or what function rather again the answer is it depends maybe if you're an engineering driven organization and you're looking to optimize developer productivity maybe you'd land that in engineering and you're just trying to facilitate for engineers consuming open source and contributing to it and the process by which they do that how you track it, how you dig through your code and identify packages and things register them, keep a list get approval or maybe you land it legal if you're more conservative really what you're concerned with is reducing risk and so on and so forth I think that if you could if you have your choice maybe that's within an operations team kind of a program management team maybe that's within an organization like that sometimes those organizations are sub organizations to engineering organizations like a build and release team an engineering ops team irrespective all of these functions probably need to be involved to some degree in your open source program office if you need infrastructure maybe your IT team needs to be included to the extent that you're publishing notifications and you're redistributing software that you're using notifications of what open source packages you're using maybe procurement to the extent that your licensing or OEM OEMing third party software your talent acquisition team, your HR team hopefully is there raw-rawing about what you're doing openly and can attract talent your corp dev team if you go to make an acquisition of software that needs to be scanned through and understood the disposition of all the packages that they're using and so on and so hopefully your marketing team can go talk about all the great things that you do so it's a really cross functional office here's an I-Chart that talks about a number of the specific responsibilities that those different organizations might have maybe you suffice to say that one of the organizations that I didn't list on the last slide is something of a committee maybe an open source executive committee so if you consider that the open source program office really probably handles much of the day-to-day stuff around someone saying hey can I use this license I want to use this software is this license okay hey I've got a project I'd like to open source is that okay I want to contribute to this project externally is that alright in this sort of process of approval that OSPO that office is dealing with day-to-day things there's going to be the time where use of an open source package that uses a license that you've identified in a gray area or maybe you've identified as hey we don't use that license don't do that there may be extenuating circumstances that need to be escalated up to a higher council if you will and so for our organizations that really falls between our executive engineering leadership and legal counsel and so we try to make the call between how risky is the use of those things and we wanted it to open up a certain code do we have intellectual property within there and so it's kind of that that's who forms our open source executive committee that compliance process that I talked about for the open source program office kind of the day-to-day for us it looks like this and it's really the notion that code comes in from two ways down below it's either that we've got ongoing scans of all of our code bases leveraging a variety of either proprietary tools or open source tools to scan either literally the lines and lines of code itself or talk to package management systems to identify the bill of materials of all of our software what are all the packages that we're using what are the associated licenses for them if we run we're scanning our code constantly for us too we also acquire things occasionally so our corp dev is sort of an ingest point the other ingest point is either just engineers themselves or product teams saying hey we've identified that we could really use this capability we'd like to incorporate this piece of open source into our product and they go over and submit a form for us so either way whether they're requesting to use it up front or maybe they just skip that they went and used it put it into the code base checked it in merged it that we're going to want to have a process that scans after the fact to catch that just in case and so then there's a process by which kind of different phases that are pretty straightforward about identifying what license it's using whether or not there's approval to use it we need to then publish the notice of it we need to redistribute the code you know itself so this compliance process of the survey that I've been speaking about this is like this is what like those organizations consider like 74% of the responsibility of an OSPO is that is that compliance process so another important thing for well whether you're whether you're creating a product or whether you've got an open source project and you're open you want to usually measure what you're doing measure the success of what you're doing and so if you an open source program office isn't any different if you've established one at some point someone's going to say you've got 30 people participating there's an org of like 30 people participating in that that's a lot of headcount that's a lot of salaries what value are they providing how is this why should we continue with this and so there's things like reducing the number of license violations you have maybe it's important to you to increase the number of contributors to open source projects that you're hosting there's a lot of different ways that you can measure success it just kind depends on what's important to your company maybe it's just measuring efficiency productivity how fast you deliver to market so to that end of the various things that you're measuring certainly for us and for many others that I've seen this is a snapshot of Microsoft's open source program office dashboard that you're going to want to measure kind of the health of your either the health of the projects that you're stewarding or maybe the health of the projects that you've become dependent on maybe you're dependent upon you know open SSL and all the maintainers have left and so you're you've got to figure something else out you should be paying attention to that so a lot of metrics to track both around compliance and contribution that we talked about and I also previously mentioned security there's all kinds of security vulnerabilities that are discovered on a daily basis understanding where you're vulnerable is important to do so having a dashboard that is important so as you go to establish an open source program office I told you guys that it's taken me about two years to get one established and that was that means that you've got to believe you got to keep the faith so sometimes I've seen more and more an increase of job postings that are hiring open source leaders someone to come in and establish this type of an office because open sources becomes so centric and important to businesses they're gonna have to have a bit of fire to them probably be passionate be a bit forward leaning and probably have some thick skin be ready for a lot of ignorance in a negative way the innuendo nuances of how open source ecosystems work and how their licenses work not necessarily isn't the day job of anyone outside of the program office so usually much education needs to happen so much patience needs to that you need to have when you go to establish one a lot of times these program offices start informally there's a working group of folks that get together that say hey we're using this they say any number of things maybe we're using this open source package we're having to maintain a private fork we need to get together and figure out how to contribute back or upstream that and so a lot of times there's sort of an evolution that happens over time of just people internally that are kind of passionate about either they're experiencing enough pain or they're passionate about trying to get this figured out within their company so it's about half the time little less than half the time that that starts within the engineering groups now I'd said it's going to require probably one or more people to champion the creation of an OSPO you gotta these are some of the top challenges you're going to face though I went through what I consider my five C's of strategy you gotta do your strategic planning there's probably a long form document in there that may need to start with an opinion piece about helping educate others as to what the heck open source is and why it's important and hopefully you can bring some statistics about how prevalently it's used within your company already or within the ecosystems that you're participating in then you go about the much more laborious and probably boring effort really defining company policy maybe based off that opinion paper and turning that probably into a couple of things maybe part of your employee handbook so as you go to hire a software engineer into your company they're signing the employee agreements that part of that is you generally hand them an employee handbook as well and that within that handbook you should probably have policy that says you should be proactive on my open source here's what you should do or shouldn't do another challenge here is executive support and that actually goes back to something I just said and that's education sort of ignorance if you consider today's this is a big generality of those that are in executive positions certainly in large organizations usually that's someone with a rare number of years of experience maybe that's 20 or 30 or 40 years of experience open source and its prevalence and its popularity I guess it's probably a safe guess to make that those executives probably didn't grow up in open source ecosystems that a little bit of this is unfamiliar turf to them that they're probably not coming to scale and sitting through talks like this they're not getting exposed to how open source works and so challenge number three is this executive support is just is helping them understand keep the faith the report that I was talking about says of the respondents there 70% of the respondents believe that are the ones that didn't have a program they believe that creating one would have a very positive impact on their company so I guess what I'm trying to say here is if you're often trying to create a program office keep the faith many people I think inherently see the value within there but the journey towards establishing one could be pretty hard fortunately there's some resources I mentioned this group earlier the to-do group and the Linux foundation and really the companies that comprise the to-do group and select individuals within these organizations that have contributed thought to much of the same things that I've discussed here today so there's certainly a great set of resources there with that feel free to reach out ask me questions off camera willing to be much more candid and share with you some of the stumbling blocks that I come across and what it how great it feels to have had established an office and how it is that at least for us we value that or which functions value that so don't be shy questions that I can take now let me ask this well I guess this is how many of you have are in an environment where there is an open source program office I know at least one of you that's true and then for the others of you I guess is software would you consider pretty centric to the value that your business delivers like either it's okay okay good and then of the software that you're using is there a fair bit of that okay very good yeah but sometimes it can be important well yeah I talked to a lot of consultants in that regard that's sort of the same position sometimes they end up engaging with customers and the customers say what we really need is this Microsoft product or this proprietary thing or an open source thing implemented but we need it changed we need you to develop a little bit around that for us to do that and as you go to see have that same ask from multiple customers you start to question whether or not you should be making each customer pay for you to repeat that implementation each time or maybe it's the first one that pays for it and then what to do with that I think for that first customer they say well wait a second I need to retain the rights to that the intellectual property and the copyrights and you can't go publish that if you're going to make me pay for it then as you go to you've got to make a choice I guess part of what I'm trying to say is relative to your environment you may end up facing a situation where you're asking yourself if open sourcing this type of integration so that you can use it a few times over make sense and one way to maybe assuage their concerns that company's concerns saying why am I paying for you to do this implementation where I know you're just going to go make money off of it a bunch of different times over they may feel better if it's an open source thing yeah and what people understand and know as well if they've been using a particular piece of software for a long time they understand how DNS runs within Microsoft in Windows Server versus Bind or whatever else so you could get big big challenge I've got a couple of employees in Germany actually in Berlin and yes Microsoft is prevalent there fair enough, very good any other questions before we close down yeah so the question was hey do I know of any other ways outside of the ways that we talked about to maybe measure the success of an open source program office are there others or maybe speak more to that so my mind immediately goes to a dashboard and the metrics of the dashboard some of these are intangible but others not I've certainly seen some of our engineers be choke on their own choke on the frustration of not being able to contribute something externally and for our company not having policy to do so and not being well understood or something that they can go self-service on so a metric being I probably don't want to have a dashboard on this but a metric being the count of how many engineers you've lost because you just didn't kind of get your act together around it's not that you need to that every company needs to say well yes any engineer can contribute whatever code they want to externally and that's okay rather to have at least a structure around their language around that so that they can engage in there's a process by which they can get those answers come to mind at least the end of our the the notice files that are published for the environment that I'm coming from some of those are updated like back in 2014 meaning we were selling, actively selling products and we'd be lots of open source but we haven't really told people what's in there for three years so anyway to not have published those things so the last updated distribution files the number of security vulnerabilities in the open source code that you're reliant on like hey that's an important thing to maybe track I think inherent to that is like if you're saying hey here's the number of here's the number of vulnerabilities that were within our code I think my assumption is that people are going to inherently understand oh there's a piece of value in there, there's risk in there that's being minimized and identified that oh maybe one of the things the metrics that you track is of all of the public facing code repositories that we have as a company how many of those have a contribution file that says here we either want to encourage contributions or we don't if maybe you're hosting on github okay how many of those for the environment that I'm in we've got like 16 github organizations and they have hundreds of repositories themselves there's lots of settings that you can have within github or any of your source code management systems some of those settings empower the users to open source things I was going to say willy-nilly just empower them to open source things maybe you wouldn't want to do that so some of those metrics can be things like hey what's the general health of our public facing in the environment that I'm in we've got hundreds of public facing repositories that have no license on them at all so inherently they're probably public domain because it's not defined so that's like an important healthy metric so I think some of these some of the metrics that I'm calling out are is like how exposed are you as a company in a variety of ways you I gotta imagine that people I've got to inherently understand that there's value in an open source program office tracking those things because you're just flying blind otherwise you have no idea how exposed you are although other things I think are if you're measuring like the even being able to understand of all of the this varies from environment to environment if you've got hundreds of thousands of repositories which ones are which ones have been updated which ones are moving the fastest are reviews being done across like this is I think some of these concerns are both centric to open source or public facing code and also just like interesting to understand hey how much how many lines of code do we even have and of that that's public facing what languages are those within or do we have how many how long the issue has been open on those projects do we even have a healthy community or so we said in the past part of our justification for opening up this piece of this project was because the engineers that were working on it said we strongly believe that there isn't intellectual property within this and that others would benefit and would bring goodwill to our company and it would make us happy and then we would also maybe hire some developers because they would get interested and etc maybe we'd be leaders in our space that things that you could use to measure the value of an open source project I'm sorry of an open source program office could be or is the health of those is how many contributors you have where they coming from but it both in good both in good ways and then also in bad ways like if you've got a bunch of unaddressed issues or if you've got or those are some of the metrics that come that literally you could have in an open in a dashboard some of them become a little less tangible I would think it was the first example that I'd given around engineers quitting or a little harder to attribute between them quitting and also some being attracted but our as an example and I try to use this occasionally internally I was giving a talk on Prometheus at KubeCon EU in Berlin 18 months ago a year right after I got on talking a gentleman came up by the name of Alex and said I've been thinking about I know a couple of people at the environment that I'm within and and and I'd really question whether or not it was right for me if the culture was right if I wanted to join now I see some of those individuals at the company here investing in the community sharing knowledge et cetera wow I'm a truck so anyway this individual is our director of platform for one of our more significant SaaS platforms and so my point is it's not always easy to say yeah they came in because they were but this is a good example of right after an open source talk where we're engaged in the community I didn't necessarily even open source any code we're just participating he came over we had a great talk he joined the company and has had a dramatic impact on the company how you can measure or like you know harder to explicitly quantify but very meaningful yeah the excellent question so I want to say that this screenshot of Microsoft open source program office dashboard is done in Node.js and that I want to say they had opened it up this was in advance of Microsoft having acquired github the the if you hit this slide deck which is public right now I think it's on the resources slide you will oh actually you can it's here it's where I was giving the disclaimer that hey this is how I did it maybe this isn't how you want to do it this quote comes from Jeff McAffer he's the director of open source program office at Microsoft these links right here this link right here there it is yeah very good I appreciate you guys coming today alright