 we're going to run through essentially the very beginning of what I wanted to talk about, and we will definitely have questions and I'm around for all kinds of conversations throughout today and even tomorrow. So let's run through it. We're not going to have much time for fluff, like I said, but this is me. I've been around, I've done some stuff. If you have questions about that, that's easier to talk about not here, but we're just going to jump into it. I also think I'm really funny. I hope it's okay. The thing that we're going to kind of talk about, which is a little bit muddy in the spaces where we operate, is the definition of open source. If you're here, you probably know this. The definition of open source comes from the OSI. We are all familiar. We've seen it essentially it says if you are releasing code on a license that allows pre-production redistribution or free, that generally that's an open source license. If you want to go look at them and spend many days with many cups of coffee like I did, link at the bottom of the slide, we'll show you all of the OSI approvals. It's very fun. It's a lot of time. Be prepared for that. But like I said, if you're here, you're already familiar with open source. You know open source is a great way for new developers to get real world coding experience, real world collaboration experience. It's a great way for people who have been around for a while, like me, to get back to a community that you've gotten so much from. It's a really great thing, but there's always this kind of uncomfortable spot that you end up with when entering a new open source community. If, to be clear, I'm going to assume that once you get to the spot that I'm talking about, you've already done all of the initial work. You've decided where you want to work. You've decided what you want to look at. You've decided what languages you want to work on. You've decided what your goals are when you contribute to open source. You've decided you've identified your strengths and weaknesses, all of that kind of stuff. You've already gone through your evaluating projects, evaluating where you want to put your time, your investment. If you haven't, go find a guide. Google it. It's very simple. This is one that I found that was generally when I skimmed it. It's pretty comprehensive. It's a great place to start. You can also find these slides later. If you want to take pictures, you can, but you don't have to. But there are millions of guides, go pick some. The thing that none of those slides or none of those guides seem to address is money. As much as we don't like to talk about money in open source, you can't do open source without money. It's not possible. Even if you are a one-person shop doing a project that you care about, you are investing your time and no matter how much you make it work, your time is worth money. Don't devalue yourself. This open source code, this open source definition also doesn't talk about money. There's no mention of how these things get funded in whether or not it's defined as open source. I thought with myself a whole bunch about how I was going to break this down. But I ended up in this spot where you're dividing. The first thing we're going to do is exclude all of these single contributor, single funding like you and your buddies got together and made this thing project. We're talking about bigger communities that have real money behind them and they're going to be broken down into either corporate backed or foundation backed. For corporate backed, we're talking about things like automatic and genetics, chef, red hats. There are many, many companies that have successfully monetized an open source project. Or in whatever way it happens, there was a project that has now become a product and these companies make a lot of money in sustain an actual very big business next to an open source project. We're talking about foundation backed, that can be broken down into two groups. We were talking about just 10 minutes ago. These are these big foundations that become homes for a lot of very small projects or very big projects for that matter. The Linux Foundation, these foundation, the Apache Foundation, there's all kinds of each of these places have hundreds of thousands of projects that they're providing cover for. Whether that's legal stuff or just a marketing machine or anything like that. These are very real problems that can't be solved when you're off and on your own independence thing that require money. These foundations go out and do the fundraising for you and then offer you a home for that stuff. The other option is a single project foundation, single product or single project foundations that you're probably very familiar with. Well, at least two of them are the Rust Foundation, the GNOME Foundation, and I wouldn't get away with not adding a plug for my foundation, the Elmendix Foundation. We are all backing one specific project. There might be a couple of other small things in there, but our focus is one thing. We have funding coming from sponsors and that money goes directly into our primary project. I'm going to pause here because I want to make it very, very clear. I am not making a judgment call. I can't tell you one is better than the other. There are different motivations and that's what we're going to talk about. There's no right or wrong way for you to walk into a room at the site where you want to put your time. I'm not going to make that call for you. I might have opinions, but I'm not going to tell you which way you have to do it. But if we're looking at this situation, the motivations are where we have to decide. If you walk into a project that you say, say you're using Chef, say you are extremely excited about Chef, you love it, you want to fix a bug or contribute a feature, and then you get to watch that feature, yet you isn't adopted by other people, you're going to get the same amount of satisfaction as you would whether or not Chef was a product being sold somewhere. It's still open source, it's still participation in the same way. You still get to be excited about it. It is very likely that you're going to encounter a situation where you want a feature and say you don't have the time to put into it at that time where you need help from the company that is backing it. The company is going to have to balance customer requests with open source community requests. That is the thing that they have to put together. If their customers are asking for something that is counter to what you want, the money is going to come into play. I'm not going to say it's always wins, but it's definitely going to come into play for them. With the single project foundations, same thing, you've got fairly, even in this case, fairly secure funding. The money is there, but you can be fairly sure that what they're doing is what the community wants them to do. It's going to be things that are asked for by the community very unlikely, especially if they have diverse funding, they're not going to be focused on any one thing that needs to be provided. Multi-project foundations, especially the massive ones, the communities are going to be doing whatever they want with very little oversight from the foundation. Again, it's all about participation and how people contribute in the way that they want to. Occasionally, when you walk into a small project, it looks a little bit chaotic. You're going to walk in and want to say, I have this great idea. I have this thing that I would like to give you, and the floor is going to be on fire. It's going to feel a little uncomfortable. That is not necessarily an indication that everything's terrible. It is very real when you bring a bunch of people together with different ideas about what they want to do and different amounts of time and different amounts of commitment that they can provide to a project, that things are going to progress at different speeds. Things are going to get prioritized and deep prioritized very quickly, depending on who can be there at that time. Sometimes the floor will be on fire, not really. Not really on fire. Not actual talking about fire. But you do have to recognize that in open source, I'm sure we've all experienced it. No matter where the funding is coming from, there's going to be a situation where you have motivations that you are walking in with that are not always the right time for those motivations. So you have to keep that in mind. Back here, we all have goals around open source, right? We all have goals. We all have things that we want to provide. We all are going to walk into every situation with an idea about how good or not good the project that you're working on is. Where that funding comes from is part of what you need to consider about what you're investing in. Your time is your investment. The one thing that I can always give you, but it comes from a good friend of mine, and I think that he got it from somewhere else, but it's always follow the money. If you are concerned at all, it's fairly easy to look at who's sponsoring and then figure out, like, just think about why they might be investing if they're there for whatever reason, right? And in almost every project, there's somebody that you can go to and say, how much of money are they giving you and why? And at that almost next time, that person, like I could talk to you about why each of our sponsors are there, right? There's always somebody I can talk to about funding and why they're there, and it gets to help you weigh projects against each other and where you put your time. I was going to go into a whole bunch more, but here's my 20 minutes. So what questions do we have? So we were talking about, you know, the money, following the money. So I work for a company, one of our products, we use an open source project, right? I have a team that is working on projects relatively small. There's a feature that we need to be implemented in this open source project. And so the debate was like, do we implement an upstream it, but we don't have the people to do it? But what you have is money. And so we paid this project to build this feature board, right? Which I think is still a good way to support an open source project. But I did wonder, is that unfair to the rest of the community who is contributing and trying to steer the direction of the project? And then like is us showing up with money and saying, we really want this feature for something that we're building? Is that unfair to the rest of the community in some way? Is that unfairness balanced out by the value we're giving to that organization in the form of money to support the project? It's a really good question because to repeat for the people that are not in the room, the question is if I as a company walk into an open source project with a feature that I need and want to pay the projects to build that feature, am I unfairly tipping the scales in my favor because I have money to give to it and I'm obviously leading the community at that point. My opinion is it depends on the situation, right? The projects that have a let's say a relatively small amount of people actively contributing will welcome that kind of investment because ultimately if you're going to get invested like that, then you're going to be able to over a longer term you're going to bring more people into the project. Absolutely. If there is a situation where there are bunches of people contributing to the project and the community is actively against what you're asking for or avoiding it for some reason, say you want to add tracking to some kind of software or something like you want to start harvesting data, that's the kind of stuff that would get very sketchy to me. If you walk in with good faith and are open about it, then I think that that's okay. One of the best ways to approach that if anybody else ends up in that situation would be to whatever way the project takes feature requests, put in a feature request in a very public way and say this is what we want to do, can we pay you to do it and the community will respond. Like there is no shortage of opinions on the internet. We'll make it happen, right? Does that answer your question? That is how we came to be sponsoring the project. Yeah, that's the exact right way to do it. That's why I said very intentionally, money is not the problem, it is a person, it is one thing that you have to weigh in everything else that's going on. Well said questions. Go ahead. There are some organizations that have some things like it. There's an open collective that allows you if they're there then you can donate there. GitHub sponsors exists. There's also this place that I just read about yesterday, today I guess, it's called I think it's thanks.dev or something like that. They're attempting to make it so that like you give them access to your GitHub repo and then they go through your tree, find all of the dependencies and you give them your budget and they say this is where you should give all of your money. Like if you have, say I have $5,000 it'll go through your tree and say these are the projects that should get your money and this is how much they should get. That's how they're evaluating that as a whole other conversation but it's certainly, there are definitely ways that you can give money to them in a more regular basis. Open Collective is my favorite because then you can also give it to organizations. If you don't know, Open Collective allows people to join their organization and kind of be sheltered as a nonprofit without having to go through the process of filing as a nonprofit. It's a really cool, it's a really cool thing. I love it. Who else has questions? I answered all of your questions. I'm the best ever in 20 minutes. Thank you.