So, Duane, I will just head over to you and I see you in the same colors as the opening screen. It's almost like it was on purpose that I matched the slides. Yes, awesome. So this is really great. And we would like to hear with you how you engage in FOSS projects and like we are recording it because I was already thinking when I read your proposal we should share this with all the companies who come here to the FOSS Azure Summit and supporting it because I think it's a really great way what I read and looking forward to hear more about sustaining FOSS projects by democratizing the sponsorship process. Thank you very much for joining us, Duane. Great, thank you. Okay, so I want to apologize very briefly. This is my first time to FOSS Asia. It's my first time to Singapore. I'd like to get an understanding of who's in the room. So students in the room, how many students? Probably more than half. How many people who currently work in software engineering? Okay, great. And how many people make open source contributions as part of your work? Wow, okay, quite a lot. So the context for the talk that I'm about to give has a lot to do with working in a company where you are trying to get more people involved in contributing to open source. There is a thing that can happen when you make that transition from being a student to being a full-time employee where work can consume a lot of the engineering time that you have and you find yourself slowly contributing less and less to open source over time. If you find yourself at that point in your career, I hope you'll remember back to this talk and become the open source and free software advocates that your company needs in that moment. So my name is Duane O'Brien. I work at Indeed.com. Feel free to take pictures, videos, write blog posts, tweet at me. Come up and ask questions later. Come down and meet us at the booth. There's half a dozen folks from Indeed. We're pretty easy to spot. We're either all wearing orange jumpsuits or in the Indeed shirts. So about me, I started off kind of as a pearl guy on the Java team that kept servers running. We didn't call it DevOps at the time. I was just that guy who knew pearl. After that, I moved on to JavaScript and did a not very good job of writing JavaScript code for a while. I then was working with Adobe while they were going through their agile transformation. I was there during their transition to creative cloud and the things that came along with that. And after that, I was working in the open source program office at PayPal before I took the job I have now as the head of open source at Indeed. So I am responsible for sponsorship decisions. I'm responsible for designing and driving initiatives and programs that get people involved as well as helping Indeed release good open source projects. And basically anything that people have a question on for open source, they come to the open source program office for answers. In my future life, I'd like to be something between a rock star, vampire, wizard and robot. I don't know what that looks like. I might have to craft that role for myself. So I joined Indeed in late 2017. And the annual budget for 2018 for the open source program was already decided when I joined the company. And they had earmarked several sponsorships that they knew they wanted to make. The Apache Software Foundation, the open source initiative, the Python Software Foundation, the Cloud Native Computing Foundation. They knew that they wanted to have a large booth sponsorship at OSCON. And there was also $10,000 set aside to go to Webpack, which is a technology that was extensively used. That is still extensively used. At my request, we also got in contributions to Outreachee. Anyone familiar with the Outreachee program? One person. Okay, I have lots to tell you about it, but it's off topic on here. They give paid sponsorships for people to make their first contributions into open source.  And I asked how we got to the point that we were sponsoring this one piece of software, and the story went something like this. The leader of our front-end core team says to my boss, we should give money to Webpack. My boss said, I think this is a fantastic idea. And then it just happened, right? There was money set aside in the budget to give to Webpack. Now, it was a little bit more behind the scenes, but not a whole lot. Now, the way sponsorship decisions supposedly work is the program head defines a budget and says, here's how much money I think I need to run our program. And then the program head selects some strategic sponsorships and things that they think are going to move their program forward. And then every quarter or so, you sign the sponsorships that are designed to hit on that quarter, and then there's world peace. Everybody gets the sponsorship money, and everybody's happy with how everything goes. That's how it's supposed to work, but that's not how it actually works. How it actually works is the program head requests some budget, and then you get an adjusted budget back. So it's always adjusted down. It's never adjusted up. You ask for $10,000, you'll get $8,000 or something like that. And then you take the money that you have and you figure out where you think you want it to go. So you earmark it for certain sponsorships. And then if you're me, and I'm looking at my team members here, January 1st hits, and you get all these crazy new ideas of things that you want to decide to do at the last minute. So now Michael's laughing because he does the same thing. You have all these new ideas of different things that you want to try, and you're kind of rearranging your priorities. And while you're doing that, some senior folks elsewhere in the organization come and make recommendations of their own. Hey, we should show up at this conference, or why aren't we sponsoring this initiative. And then there's a series of high level discussions between everyone involved, and then those people have reasonable disagreements about where things should go. And at the end of the process, you wind up with a compromise, right? Half happy. There's some people who are very happy with how it went, some people who are kind of sad about how it went, and some people in the middle who got a little bit of what they wanted. Now, nothing really inherently wrong with that. It's kind of how the sponsorship decision-making process has been going all along, except for everything. The first thing is that these high level discussions are really exclusive. If these are the people who are making the decision about where sponsorship goes, that's not what the company looks like. They have direct reports. Those direct reports run teams. Those teams have team leads and engineers and designers and marketeers and people all throughout the organization who were not involved in this process in any way, right? So it's an exclusive kind of decision-making process. And because it's exclusive, the decisions are very seldom transparent. Unless you go through the explicit step of saying, hey everybody, here's the sponsorship that we signed. Here's why we signed it. Most people that are further down in the organization don't know why any of this is happening. They just know that it happens. Which comes into, if they want to raise their own voice on things that they think should be sponsored, they have to escalate those kinds of requests. And that's easy if you sit one or two rows down from the decision-making process. But if you're a designer way down in the org who thinks there's something really important that we should be sponsoring, you've got to escalate your request through seven layers of people and it's competing for information, it's competing for attention with a lot of other things. So we decided to try something new indeed this year to hopefully address some of these. And this is called the FOSS Contributor Fund. And I'm going to break down during the rest of the talk what it is, how we run it, and what we've learned from it so far. So the FOSS Contributor Fund is a pool of money that is in the budget for the open-source program office that is unrelated to organizational sponsorships or conference sponsorships. So sponsorships like FOSS Asia come out of one side of the money. There's a second pool of money set aside just for this. And we will sponsor software projects out of that pool of money. Those projects are nominated by employees. So anyone who is engaged with the open-source program has the capability to come and say, hey, we should be sponsoring this because it's important to indeed. Those projects do have to meet certain selection criteria. And I'll talk about what those are in a little bit. And then anyone who makes an open-source contribution over the course of a given month gets to decide and cast a vote on where that month's allocation should go. So everybody who made some kind of open-source contribution in January, they got to decide on where the funds for January went. And that allocation is $10,000 a month. So every month indeed gives $10,000 to an open-source project that meets certain selection criteria. The first one is it has to use an OSI-approved license. It has to have an open-source license, one that is recognized as an open-source license. It must be used by indeed. So it doesn't have to be in our product stack. It doesn't have to be in our infrastructure, but it has to be somewhere. The example I always give is the imaging software that IT uses to provision new laptops to new employees when they come in. If that's open-source, it qualifies. We use it at Indeed. So we have to use it. It has to be an OSI-approved license. It must not be owned by an employee. I'm sorry, you can't nominate the project that you wrote if you work at Indeed to receive $10,000. That's kind of cheating. And finally, they have to have some way to receive funds. They have to have an open collective. They have to have a Patreon. They have to have a foundation that can receive money for them. Just some way for us to give them money. It can be a PayPal button. It doesn't really matter. The thing that matters is our procurement department, the people who actually write the checks, have to be able to get money into their hands. Now, the fund has a few different goals. Obviously, we want to support and sustain our dependencies. But the secondary goal, and really a primary goal of mine, is we want to drive open-source participation within Indeed. He was saying at the beginning there were 700 participants in the CodeHeat hackathon. My personal long-term goal for everyone is that after something like a hackathon, they will continue to make those contributions down the line. I want the same thing for people who work at Indeed. We want more people to be involved. We want more people to be involved regularly in contributing to open-source. We also want to highlight projects that are important to everyone in the company. So not just the ones that the senior leaders might think are important, or the ones that I think are important because I have visibility into certain parts of the organization. I want anybody in the organization to have the ability to say, this is important, we use this everywhere, and we need to be supporting it. In any company of any given size, there's going to be hundreds and thousands of open-source dependencies that your company relies on. I could probably name 10 to 20 off the top of my head for Indeed. If you wanted to say, hey, what are the top 50 things that you use? I've got to go to software that's going to pull that out for me. There are thousands of things that we use, and there's only so many that I can know at any point. So giving everybody the ability to highlight projects that are important. We also wanted to try something new in the open-source sustainability space. There's been a lot of conversation ever since Heartbleed about open-source sustainability, what it means, trying to help maintain projects, addressing maintain or burnout, and so on. We talked to a lot of people who are involved in sponsorship, in particular in open-source sponsorship. This is not an approach that other people are taking, so we think it's new and interesting. We wanted to see what happened. And what happened is there are several things that could go possibly wrong. Money might be the wrong thing for a project. Not all projects know what to do with money if you show up. And not all projects want or need money. I talked to someone who maintains a very popular project, and money was not his problem. What he needed was someone to be a product manager for him because he didn't have the ability to interact with users. So money might be the wrong thing for the project. Maybe they need infrastructure or something else. If we put it out to a vote, voting might select a problematic project, a project that has a very toxic person running it, or that has some other problem with the project that indeed would not want to be associated with for one reason or another. Our process might break down. We might set up a thing and have a vision for where things are going to go, and then our processes might come apart at the last minute. We also might need to curate nominations. Depending on how many people nominate projects, if there's six or 10, put forward and you're going to vote on that, that's easy. If people nominate 50 projects and you need to vote on your favorite, that starts to get hard. And so none of these feel unsolvable. They're just things that could go wrong. Now, in order to actually get the fund implemented, I had to get executive buy-in. I had to get my boss to agree to give me $120,000 to give away to open source projects over the course of the year using this thing that nobody else had tried. And so I want to talk a little bit about getting executive buy-in. For me, it looks a little bit like this. I wrote him a document and I said, if you don't want to read it, I want $120,000 for a sustainability fund. Now, underneath this, there was a paragraph. I'm asking for a budget of $120,000 allocated in 2019 for distribution to open source projects which indeed consumes. And then that goes on to explain the approximate idea we had for how voting would work and everything. And Jack's response was, I think this is a fantastic idea. And that sounded familiar to me because it was pretty much the same thing he said to Webpack. There was a little more involved in this, but I lucked out in that I worked for a boss who really understands what it means to give back to free and open source software. But the big learning here, I think for everyone, if you ever find yourself in this position, is always ask. If I hadn't asked, he never would have had the opportunity to say yes. And I went back and forth on that $120,000 number many, many times. It was 60, it was 10, it was 12. How much money do I want to ask for? $120,000 was the most I wanted to ask for. I asked for it, I gave him the opportunity to say yes, and he did. So always ask. You'll be surprised at what can happen. Now, let's talk about measuring success for the program. If we come back to the goals of the initiative, the thing that I really want to focus on is this driving open source participation within Indeed. For people who work in corporate open source program offices, metrics is a big conversation, right? Because you always have to be thinking about how you can demonstrate that your program is doing the things that you want it to do. And so there's lots of ways that you can measure open source participation. There are good things to measure, there are bad things to measure. I'll say out of most of the conversation, I want to talk about what we landed on, which was this idea of active recurring participants. So active means that they have triggered some kind of an event that we care about. It's not just that we know what their GitHub ID is, it's that they've done something within the time frame that we care about. Recurring, we're looking for two or more days of activity within a given window. We measure this currently quarterly, so we're looking for someone to be making a couple of different open source contributions over the course of a quarter. In the Linux kernel community, that might be a significant amount of activity, and in the JavaScript community, it's for lunch. It just kind of depends on what your ecosystem is. But a couple of different days in the quarter, that's what we're looking for. And participation is a broad category of events. It is not just measuring code contributions. It is filing issues. It is doing code review. It is doing triage. It is participating in the broader set of activities that we know go into maintaining an open source project. So this is the thing that we settled on to measure. This is the thing that we want to grow. And this is the thing that we believe will tell us if we're making a difference. So we've been running it since January. Let's talk about what we've learned so far. January was our first month, and then January contributions went up. Hooray, graph goes up and to the right. How far up? So I'll break this down very briefly. This was October. This was the first month that we were actually measuring any kind of contribution activity, and we were promoting participation in Hacktoberfest. This is November in America, giant holiday, huge lull. We didn't actually do any promotion of anything. And so we saw a significant drop in contribution activity. In December, we were encouraging participation in something called 24 pull requests. We saw a nice jump in activity again. And this is January, the best month ever as far as contributions go. We had 20 projects that were nominated to receive funds from the Frost Contributor Fund. That was more than I thought there would be, but that wasn't the thing that really got me excited. Ten of those projects I knew about, I probably would have listed as things that we were using. Five of those projects I'd heard of. I didn't know we were using it indeed. Five of them were completely unknown. I had never heard of them. They were open source projects that were in use at Indeed that someone thought were important enough for us to support that they nominated them to receive $10,000 that I'd never even heard of the project. Now, that shouldn't be terribly surprising. There's only so much actual open source software that you can know about at any given time, but this really excited me, because this was one of the things we were looking for. People to nominate projects that were important to them, not just to senior leadership. As far as our participation numbers, those went up as well. As far as participants, it was about 12% higher than the three month average previously. Just slightly fewer participants than we had in October, but significantly more than we had in December. We did see a nice jump in people who were active recurring participants, like I said, about 12% over the previous three month average. The project that they voted to support was Django. It's used a lot to roll out products and used a lot in our incubator. Let's go into February. February contributions went down a bit. This is February contributions, lower than January, higher than December, so they dropped a bit. I would expect to see that as a new initiative, kind of exciting, and then a little dip at the end, but we only had six nominated projects, which was really interesting. In fact, three of those were carried forward from January. We were scratching our heads about this one a little bit. We did learn something from it, and I'll cover that in a moment. As far as participation goes, participation was actually down. We were 8% lower than the previous three months. It was not quite as bad as November when we had that significant dip. It was still higher than that, but well below October and January. What's interesting is we had fewer participants, but the second highest month of contributions. That's kind of interesting, and I'll come back to that in a second. In February, the money was given to Git. Git, which is managed by Software Freedom Conservancy, will be receiving a $10,000 donation. What we learned out of February, was that promotion matters. In January, we were pushing a lot of that information about, hey, there's this new thing, you need to come participate. In February, we didn't do any of that, and so we definitely saw a drop in participation. We also learned our nomination process is unclear. When we went and talked to previous participants, they said, wait, I have to nominate them again? I didn't think I had to do that. I'm not going to do that. In my mind, just having to go nominate a project, and that was just filling out a Google form for maybe 10 seconds, that was the minimum amount of interest someone needed to show in order for this to be a thing that they wanted to pursue. But that's not how the community received it. That's not how they viewed it. So the nomination process was unclear, and hey, our process can break down. It wasn't so much that we decided not to put out slides in February, it just kind of fell through the cracks on us. So we're working to implement processes that keep it from happening. And we left with this question, our average contributions going up. We had more contributions, fewer contributors. And maybe something we should keep an eye on. So in March, March contributions, I don't know yet, we're only halfway through March. This slide was a couple of days ago, so it was missing some information. When I put the information in, we had slightly fewer contributors than we did at this point in January, but more contributions per contributor, which is another thing that makes me wonder, our average number of contributions per person going up. I don't know, but let's keep an eye on it over time. So where do we go from here? What are my plans and dreams for a FOSS contributor fund? First off, we'll be releasing a CC licensed blueprint document. I had wanted to do it in March, but I didn't feel like we had enough data to really provide a good blueprint. So we're targeting July for the release of a document that any company could follow, that anybody could follow to implement something like a FOSS contributor fund in their own company in their own place. What comes after this is, I really want us to focus on growing those participants into maintainers. Now, the sustainability conversation, a lot of the people try to solve the problem by putting money at the problem. Money does not magically create time. Money does not magically create labor. Money does not magically create help. It can help some projects, but what projects usually need is just someone to show up and help. So we want to grow those participants into themselves and picking up some of the maintainer load. And last, hoping over the course of the rest of the year to find 10 people who are willing to try to make the case during Q4 in the budget planning process to try to start their own FOSS contributor fund of their own. I think if we can get there, I think that will be super exciting for 2020. Individuals in the room, what can you do? If you're interested in seeing how this goes, you can email us at opensource.indeed.com. That doesn't sign you up for anything. It's an alias that goes to me and two people at the table over there and say, hey, I want to know how this goes or I want to try to convince my leadership to do something similar. Always advocate for the projects, whether you are involved in an open source program or an employee who wants to make contributions to open source and see your company supporting them, always ask, right? Advocate for those projects. Ask someone to pick up help on those projects. You'll be surprised who can say yes. If you work at a company and want to take your own steps to democratizing the sponsorship process, you can start now, Open Collective, if you're familiar with them, they have a great gift card program where you can buy digital gift cards to give to individual engineers and say, go sponsor the open source project of your choice. You can do it with very little funds. It's a very easy way to get going from there. I have a slide here that says I'll ask questions and I have one minute for questions. So how about question? The question in the back was how do you measure contributions? I don't have time to go deeply into it, but this is very GitHub focused and that's more or less been okay. Tons of open source activity happens outside of GitHub and if people indeed are doing activity outside of GitHub, we have a form where they can just say, hey, I'm doing other kinds of open source activity and they tell us what it is and send us a link and we trust them to be more or less accurate. But that can also include things like organizing a meetup, other ways that you can be involved. Other questions? Did you ever find a project you want to contribute to but then you can't find anyone to give money to or any way to contribute? Haven't yet, but we're only two months in. What I'm hoping is that the nomination process will filter out projects that we get that far into the process and then don't know how to give them money. But that'll be a problem we solve when we come to it, but it hasn't happened yet. Hi, so a more basic question. How does the conversation even start with sponsoring open source projects within the company? How does the conversation start with sponsoring open source projects within the company? In the case prior to my joining, it really just starts by someone saying, this project needs help. The reason the Webpack got the $10,000 is because the leader of our front-end core team saw Sean Larkin from Webpack on stage saying, hey, we just went to self-funded model and we could use your help and they said, okay, and they talked to somebody and asked. There are people inside any given company who either have the responsibility to do these kinds of sponsorships or have the capability to do these kinds of sponsorships. But very few people ask and sometimes it's just feeling like you are enabled to go and ask that question. If you're not sure where to start, I would look for the most senior person you can point to in the company that cares about open source and ask them. If they don't know the answer, they can probably point you to someone else. One question. You propose one contribution per month, right? You propose every month different contribution to different nominations. Yes. So it could be just one short contribution to one project one month and there is no follow-up after that. I didn't talk about any follow-up after that but it is a very good question. The best outcome for any program or any project is continued long-term predictable support. A drive-by donation of $10,000 to a project is great but it's very hard to plan around those and anyone that's done any kind of fundraising knows that that can be very hard. As far as following up about the donation, we're just now to the point that we want to follow up with Django and say, hey, how did that work out for you? Do you know what to do with that? Do you need help with that? Because if they need help with figuring out the best way to use their money, the people at Software Freedom Conservancy and some of the other open source focused nonprofits can help them. We also take projects that are nominated and funnel them into our, would you like to get started in contributing to open source? Select these projects. Here are great ones to get started because we know we use them and we want to push our open source participation or contributions in that direction. And so the hoped end effect is that we may not continue to send money but we are sending people to help them do their maintaining. That may be all the time we have for questions. I'm looking to you. I'm happy to answer questions all the time. Yes, I mean like there's a lot of interest and as you mentioned we can follow up at the booth. You also have another talk specifically on GitHub. That's on Sunday. Yes, I have another talk on Sunday about why GitHub is not your resume and we need to stop using it that way. So even though this was very GitHub focused, it talks about why that's a bad idea. And please do come by the booth or stop me. I'll be easy to spot in the blue and orange jumpsuit. I'm happy to answer questions and keep talking. Okay, thank you very much and a big round of applause please.


I bring greetings from Kenya. It's really a great honor for me to have received this invitation to chair this session by MSF, which is an amazing organization reaching out to areas where other people don't go. I really appreciate the things I've listened to this morning from your directors about the value of implementation science and its place in improving the work that we do, constantly questioning how we do it, questioning our processes, and seeing how we can improve them. I think that we all know medicine is full of wonderful interventions, which are in dustbins, literally, and have never been implemented or well-intended programs that never took off and never achieved the goals they were set out to do. So when I went through the program this morning, and I looked at the diversity and the work done by various people from MSF who will be presenting this morning on various projects from TB self-testing, which is a pet project now for pre-exposure prophylaxis. Thank you for having those presentations. Maternal child health care, palliative care, and keeping in mind what we had from your director, but always keeping in focus the people that we serve and being clear on the goals of what we do.