 Hi everybody. My name is Dwayne O'Brien and I'm the Director of Open Source at Indeed. I've been working in open source programs for about eight years and I get really excited when we start talking about topics of open source sustainability. I want to disclaim at the beginning of this presentation that some of the opinions that I'm going to share in this talk are really my own and not necessarily those of my employer. Now in the open source program at Indeed, we do a lot of different kinds of work. We craft policies about how to use and contribute to open source. We support open source contributors and maintainers who work at Indeed and we sponsor foundations like the open source initiative and events like FossAsia. But another thing that we do is we sponsor a lot of open source individual projects, open source contributors, events and other foundations as well. We're pretty involved in the sponsorship space. A lot of this we drive through a framework we developed at Indeed called the Foss Contributor Fund and this is a blueprint that your organization can use to identify projects that you might want to sponsor directly and you can get the report that we developed with O'Reilly over at opensource.indeed.com. So by the end of 2020 we will have sponsored about half a million dollars worth of open source projects using just the Foss Contributor Fund. But that's not the only way that we get involved in sponsorship. We also sponsor a lot of individual developers who make contributions to open source dependencies that we use. Right now we're sponsoring 118 of those developers through GitHub sponsors. That number goes up and down as we look at it on a quarter by quarter basis. Supporting open source projects on behalf of an organization is complicated. This is something that we've learned as we've done experiments and we've been involved in a lot of the open source sponsorship space. And I want to spend some time explaining this process from my perspective as someone who sponsors projects with an eye toward giving you some tips that you can use to help make it more likely that other organizations will show up and get involved and sponsor your project or contribute to your project or advocate for your project internally. Before we do that there are some things that I need you to understand about the nature of my role. And I'm going to talk about my work but you can assume that many of these things are also true of other people who make sponsorship or open source decisions on behalf of their respective employers. The first thing is that decisions are made by people. An organization doesn't decide that they want to suddenly show up as a sponsor for your project or to get involved in your project. Some person at that organization makes that decision and it's an important nuance and it's important to understand because the person making that decision they have to make those decisions that are governed by policy. There might be local laws that are in play. There might be company policy that is in play. There are just rules that we have to follow when we're deciding which projects we're going to support and which projects that we aren't going to support. The next thing that I want you to understand is that I already want to support your project. You have friends in companies who want to advocate and support your project. You already have adopters who are looking to get involved in the project. People want to support your project but it's not always easy for them to do so and one of those reasons is because your project is one of thousands and it can be difficult to remember this or view this from the perspective of someone who's making decisions on behalf of an organization because as a maintainer or as the owner of an open source project you're used to being the person talking to a lot of people. You might have a lot of users that you're communicating with or a lot of adopters and you may feel like you're having this conversation with a large group of people. It's exactly the opposite problem if you are in an organization trying to make decisions. There are thousands of projects all trying to have conversations at the same time and remembering that can be important and help you on this path to generating more support. The last thing I want you to understand is that there are just limits to philanthropy. There is only so much that an organization will do for your project in the name of goodwill or because it's the right thing to do or because they want to be a good citizen. If you want to push past those limits of philanthropy you have to be able to articulate your value to an organization. We'll talk about that a little bit later. There's really about five reasons that I want to talk about that are reasons why I wouldn't decide not to support your project or reasons that I can't support your project or reasons, things that might get in the way of supporting a project. Reason number one is that I just can't find you. If you look at this blog post by GitHub they said that the average open source project has about 203 dependencies. They might be direct dependencies or transitive dependencies. So just for one project you're already competing with 202 other dependencies within that project who all might be looking for some kind of support. And within an organization you might have dozens, hundreds, thousands of individual software projects that you're using and building and maintaining so the number of dependencies can very, very quickly escalate. If you look at the size of the overall ecosystem two years ago there were already a 1.3 million MPM packages and that's just within one language ecosystem. If you look across multiple language ecosystems and you start to factor in things that aren't package level dependencies, something infrastructure dependencies, the number of open source projects that need to be supported is very vast and it can be very difficult when you're looking at them altogether to figure out who in the crowd is asking for support or looking for support. So my guidance for you here is be easy to find and there are a lot of different ways that you can do that. To keep in mind there are automated tools and there are automated processes that will make it easier for you to find your project. By way of example backyourstack.com will help you identify projects that have signed up for GitHub sponsors or who have otherwise signed up for an open collective. People who are making sponsorship decisions might use a tool like this to go find your dependencies or go looking for dependencies that they want to support. So making sure that tools like this can find you is a good first step. One of the great byproducts of GitHub sponsors is this creation of a machine readable file that describes funding mechanisms for packages. If you sign up for GitHub sponsors, you end up with this funding.yaml file and it describes different ways to fund your project and now I can write tooling or other people can write tools to go look for these funding files and amplify those projects who are asking for funding and that can make it easier to find you. There are other machine readable or common ways that will make it easier for projects to find you. A good example here would be to use the well understood issue tags for people that you want to get involved in your project. So this website here, Good First Issue, just looks at that default issue tag on GitHub for Good First Issue and it aggregates them all in one place so that somebody can go and find them. If your project is using custom tags to identify beginner friendly issues that are different from the rest of the ecosystem, those beginner friendly issues aren't going to show up in places like this and so it's going to be very difficult for people to find ways to support your project just because there's so many projects asking for help. So that's my first piece of guidance, be easy to find. The second reason that I might not support your project is that I just don't know you and I don't mean here that I don't know you personally. I mean that when I go to see who's involved in this project and who might be responsible or who I could go talk to, I don't have enough information to make good decisions. So you've probably seen GitHub profiles that look like this one. There's this default image instead of a personal profile image, sometimes called the space invader image. There's no information here about who this person is or who they work for or what they do. We don't see any contribution activity. If this looks anything like your GitHub profile or if this looks anything like the information that's available for you as a maintainer and as the person who owns the project, it's unlikely that companies or organizations are going to want to get involved in your project because you don't look like a real person. So identify yourself as my second tip. Make it clear who you are, make it clear how you can be found, contacted, where you can be reached for support. By comparison, let's look at the profile here for one of the chief maintainers and creators of ESLint. Now if you are a maintainer or a software engineer or otherwise an open source contributor, you might have immediately drawn your attention down to the contributor graph and seen that this person is very active over a large number of days. And that's useful information. But as a sponsor, I tend to pay attention to these other pieces of information. Do they have a picture that looks like they're a real person? Is there a little bit of biographical information? Are there different ways that I can go and contact them? Do they have a publicly verifiable identity? If you have a publicly identifiable, if you have a publicly verifiable identity, it's easier for an organization to support you because we know who we're talking to. So that's my second tip. Be easy to identify. Third reason, I might not support your project because I don't feel like I trust the project or I don't feel like I can trust you. And this is about being predictable in your communications and being predictable in what your project does. When you look at a large number of projects, the more investigation you have to do to figure out if the project is active or if there are really people there or if it can be depended on, the more investigation you have to do, the less likely the organization or the person is to decide they want to use it. By way of example, it's very difficult to know just by landing on a project. If this is a project that is updated on a slow basis, maybe it's sort of a slow burning project that is under active development but isn't updated very frequently, and a project that appears to be clearly abandoned where pull requests are piling up and issues are piling up and no one appears to be paying attention to the project. One of the ways that you can help distinguish your project against other projects is to communicate frequently. And there are many ways that you can do that that send good signals to organizations that you can be depended on and trusted as a project. Publishing good change logs every time you push out a new release that describe what the new features are. Even if there's not much information in there, publishing this information sends good signal to the organizations that you are a professionalized project and you can be depended on used and should be supported. Publishing blog posts whenever you release a new release is another good example. The more you talk about your releases and your process, and the more you talk about them in ways that are easy to find. If you're having conversations in a private discourse channel or in a discussion mechanism that I'm not already able to go in and read, I'm unlikely to be able to have the time to go do the investigation for these projects. So communicate often, communicate frequently, push out predictable releases, do it on a regular cadence even if the changes aren't very big. The more predictable you are as a project, the easier it is for an organization to depend on you. And constant communication and effective communication is a good indicator of predictability and trust. All right. So the fourth reason is that I just don't know what you need. And here I want to spend a little bit of time talking about the difference between helpful requests and unhelpful requests because we see many times within the open source community requests for help that just aren't very helpful. So what are some unhelpful requests? Help. I don't know if this means you're trapped under a bookcase or if your car is on fire or if your open source project needs money or if you're trying to push a release and your build is broken. It's a help is not a very helpful request because we don't know what kind of help the person needs or how urgent it is. We need more contributors. This is a better request than help, but it doesn't tell us what kind of contributors it doesn't tell us what they'll be working on. It doesn't tell us what the intention is or what will happen if more contributors come to the project. Please sponsor my project. I don't know how much money this project is asking for. I don't know what I get as a sponsor. I don't know what the project hopes to do with the funds. I know that you're looking for some kind of sponsorship, but I need more information than this before I can make a good decision. I can't keep up with issues. This isn't really a request. This is more of a complaint, but it can be translated as a request. You need some kind of help with issues, but I don't know if this is because they're coming in too frequently or if you've just had a baby and you have less time or if suddenly you're in this massive adoption phase and issues are coming in quicker than you can triage them. By comparison, here are what I think more helpful requests. They're not perfect, but they're more helpful than the last set. I need help organizing. Even though this is a very simple short request, I immediately know from looking at this, sending in someone with project management skills would be very beneficial for this person. They don't need help with code. They need help getting the project in order and getting different pieces in place so that they can understand what they need to do next. I already know the kinds of people that I can go ask and see if they're available. We need more tests. I think this is a useful request and a helpful request because we know that this isn't just about making code contributions. It is about having good testing expertise on the project, and it tells us the kind of developer or the kind of contributor that we might go looking for to write some tests. We need $5,000 to host a hackathon next month. This is extremely useful as a request for me because I know how much is being asked for. I know how it's going to be used. I know how soon they need it. As someone who sponsors a lot of projects, I almost certainly know immediately if I have that much money in my budget and if I can get this through procurement and time to be useful, and if either one of those things are false, I can immediately say no, and we save a whole lot of discussion about the nature of sponsorship. We need two to four hours a week helping triage issues. This is a very specific focused request. We know that the need is triage. We know that issue triage is something that can be done with an hour here or an hour there, and we know the time commitment from somebody. If you ask for help or a maintainer or a new contributor, that feels like an open-ended time commitment. When you're asking for a specific fixed scope of time, it empowers people from the other side to be able to say, okay, I have that much time in the week. I think I can contribute to this. So the more specific you can be about your needs, the more likely it is that an organization is going to be able to support your project. Some good examples of this that I've seen in the past. One is this fundable packaging improvements repository hosted by the Python Software Foundation. This is a list of improvements that could be made to the packaging ecosystem if someone wants to pony up the money, if someone wants to provide funding for that improvement. This is great because it tells me what the scope of the engagement is, and it tells me approximately what it would cost to engage with the project on that. This project here, NEJSON, has used one of the GitHub native tags for their project to say maintainer wanted. They know that they don't have time to maintain this project anymore. They're open to bringing in a different maintainer or maybe handing this off to another maintainer. This is a useful tag. And if you go to GitHub, you can search for projects that have maintained or maintained or wanted and find projects that are looking for help or for a new maintainer. Now, if you're signed up for GitHub sponsors, you have the ability to define these levels of sponsorship for your project. And within these levels, here's a good example of someone being very clear about what you get as a sponsor. And this takes us into a slightly different kind of relationship. There are sponsorship perks that have to be managed here. You know, you get access to their cash flow sheet so that you can see how funding is going for the project. And you also see that they will take some of those funds and pass it on down to their own dependencies. What's important here is that the maintainer has spelled out for potential sponsors what they will get as part of the sponsorship engagement. So the more specific you can be about your needs and how you're going to use the funds, the more likely it is that an organization will be able to sponsor your project. The last reason we discussed today that I might not support your project is that I just can't pay you. Now, I've encountered a number of projects over the course of our sponsorship engagements that have very peculiar or very unique needs when it comes to sponsorship by comparison to other projects. Here's an example. If we wanted to support this project, and if these were the only payment mechanisms they had, it's bank transfer to someone in Europe or in the UK, PayPal to some person or some cryptocurrency transactions. If I go to my procurement department and ask them to transfer some funds via wire transfer to a person somewhere on the other side of the world, my procurement department, the ones who are responsible for making sure that we pay people, they're going to say no. And this is because decisions are governed by policy. The procurement department has rules they have to follow and those rules are there for a good reason. They enforce international law, they enforce local law, they help protect the organization from fraud. So be easy to pay. And there are several ways that you can be easy to pay for an organization. The first is to sign up for a program that's well understood like GitHub sponsors. If you've signed up for sponsors, then my organization doesn't pay you directly, they have a financial relationship with GitHub. And that makes it easier for the procurement department to understand who they're paying and how they're paying them and they can engage in a contractual relationship with GitHub. You can also set up an open collective. This is a fairly well understood platform for raising funds for your open source project or for your collective project and having transparent finances. And open collective again gives our procurement department someone specific to deal with. They don't have to process 100 PayPal transactions or some wire transfers and there's not a whole bunch of things that they have to do. They can just deal with open collective and that simplifies the procurement process. You can also get a fiscal host, a nonprofit organization who is there to receive funds on your behalf, provide legal assistance or other kinds of assistance for your project and give the organization's procurement department an entity, a nonprofit entity that they can deal with and again engage in a contractual relationship. So being easy to pay and not relying on a PayPal button for your project or a wire transfer to some person somewhere, that will make it much more likely for an organization to support your project because it fits within the policies that govern procurement in different organizations. So those five tips, be easy to find, identify yourself, communicate frequently, be specific about your needs and be easy to pay. If you do these things and none of them are very complicated but they require some intention and some thought, if you do these things for your project you will significantly raise the likelihood that you will be able to get support from other organizations, that you will get code, that you will get sponsorship, that you will get advocacy within those organizations. Thank you everyone. Enjoy the rest of FossAsia.