 Hey everyone, my name is Andrew Gaul, today I'll be talking about maintaining an open source project while sustaining your sanity. If you'd like to follow along with the slides, you can see them at gaul.org slash talks. A little bit about me. I'm a maintainer of several small and medium sized projects. What these projects do in particular is not important, they're cloud related. But I've been working on them for five and 10 years now. And it has some thoughts on how we've sustained those over a long period of time. These projects have only a few maintainers, a larger number of contributors, and a much larger number of users. More than the maintainers can really satisfy all the issues. The virtual format makes this difficult, but I do live in Tokyo. Okay, let's define what project maintenance means. So there's a lot of different tasks in here, more than just programming or generally software engineering. So it's working with users, triaging issues, cutting releases, scoping the project, coordinating contributors, working with external projects, improving quality, and writing new code sometimes. And as the commit strip comment suggests users believe that there's a lot of different individuals doing all this. But there's usually just one or two people that are actually working on these projects. And so it's pretty difficult to do everything. So you will burn yourself out if you try to do everything, try to all of these maintainer tasks and all the programming and all these are interaction. And so to sustain your sanity, I'm going to recommend that you consider your project from different vantage points. I'm going to map these onto functional roles at companies, but it's kind of a series of values about different people in the process. And to do this, you have to try to do less work, but different work over longer periods of time to sustain the project. And this may allow you to keep the project going for years. But you'll have to make a deal with the devil. You'll have to get into management, which is challenging for ICs like me. So the project maintainers wear many hats. The first of which is the product manager hat, where you advocate for the user. The second is engineering manager we advocate for the team. Third is technical lead we advocate for the code. And so this talk explores these three roles and what you can do with few resources and lack of corporate sponsorship. The first role is doing only a product manager. And this, this role is really advocating for the user. And so the first thing you want to do is evaluate the project against the ecosystem. And there's a lot of different sources of information from hacker news to stack or workflow on Twitter. But you're trying to see what people are saying about the project that may not be reflected in your issues. And so this, these could be compatibility with other software. It's the incompatibility in another piece of software that the bugs found there. But it's actually related to your project that maybe you can do something to help them, or maybe people are complaining about performance or some other use case they don't think scopes in, and there's just not an issue for it. The second important thing pms do is they think about how users interact with the project. And this could be configuration right like how do you actually set this up or they're saying ways to do this or is required a bunch of fiddling with different bits doesn't work at a box. Are the releases regular releases that users are consuming or they have to compile it themselves. Packaging, are you in the, are you in Linux distributions are you in on Docker hub. It is easy to start using your project documentation is important. In one sense just to tell people what's going on, but also to protect your time so they're not constantly asking you how do you use the software scaling trick. And backwards compatibility is an important thing as well. In the real world people mix and match software versions and data formats, do you fail cleanly when you try to use an unsported configuration you corrupt your data. How does it actually work in these mixed environments. The third thing that pms do that you're probably more familiar with is prioritizing the features and critical fixes. And so if you have to evaluate the project. You can, you can kind of determine what's most important and say that hey this this is something we want to address sooner rather than later. There are other tricks here, but not everything requires like a code solution or even a clean code solution. If there's an easy immediate workaround for a user, either, you know, avoiding a certain configuration or turning off a feature, or something that works around things in the short term that that's oftentimes more impactful. Immediately, then saying hey can you wait six months or maybe never to get a proper fix. The second thing I would say is that pms like a competing projects competing some of a nebulous term in the open source world, but there's essentially things that we can coordinate on so that it doesn't stress out users as much, whether it's similar terminology or sharing between different projects. Maybe if you think with the SQL ecosystem from my SQL to SQLite, trying to have code run on all three is pretty difficult and if they had used similar, similar words and sounds that would have been better. Okay issues, issues everywhere. So most projects are drowning and issues, things that are not able to be immediately addressed. But these can be the highest quality feedback from your users. Some people really go out of their way to minimize a test case or tell you exactly what's going on or test the latest version and the development branch. And so issues can be super, super valuable. Or they can be a junkyard of vague unresolved symptoms and peace. Usually a little bit of both in my, my experience. And so the way that you can improve your issues is that you want to groom them. And so this is to help you understand the state of the project, you know, what are the most critical issues, you know, what's, what's still pending. But also to help your users understand the project. If you attach the right kind of metadata, you can tell them, you know, nobody's working on this right what help or something like that. You can, you can say like hey this is really your responsibility to move forward on this. And so the three things that will improve the average quality of your issues are clarifying the issue, you know, how does this happen. You know what configuration are using which version do duplicating issues. Oftentimes a popular should be open several times because people don't understand that the commonality between that and the previous issue. I'm finding closing stale issues. Somebody's not working on. If it's not actionable. If there's not enough information it's been stale just disclose it. It's okay. Somebody will open another issue again someday maybe higher quality one. And the two bits I really want to emphasize here is I like to mark issues with the help wanted label and the need for label. The help wanted means that users that no one's going to work on this and it's requiring a user to step up as a contributor and to fix it for the project. And in this kind of avoid some silly comments like when is this going to be fixed. They see the help wanted they will hopefully they understand need info is a good one as well. If you can't act on an issue if you're waiting for something just swap that need info, they blow on it and this this avoids ambiguity and misunderstandings. Sometimes the bug reporter is waiting on the maintainer and maintainer's been bug reporter and things just stalemate accidentally. So try avoid that. I'm going to do a couple case studies as we go through here. I'll talk about some of the projects and the problems and successes we've had. The first is S3FS. This mounts S3 bucket as a file system. It's a very old project. I came into it. It's not seven or eight years ago. It's hard to remember when. And there were tons of issues and I was just trying to understand what's what's going on in this project. And the grooming process revealed that there were two major themes that I thought were actionable. The first was a small issue where POSIX or Linux permissions those kind of 644 and 755 bits. They mapped poorly onto S3 objects and created an interoperability problem with using other S3 apps. And there was a workaround for this that someone had contributed that you just needed a flag with the compliment of the bits or something like that. And it was super unintuitive to do this workaround. This was actually a really satisfying and 20-line pull request that fixed multiple issues, both in GitHub and on Stack Overflow simultaneously. And it was so little effort that I felt bad that we hadn't identified this earlier in the project. The second major theme that grooming revealed was that there were multiple symptoms of data corruption. And this is kind of the most important thing for a file system, like do not lose data, you must return the data that user wrote into it. So this was not simple. We iterated for years with users trying to understand the symptoms, things that couldn't be reproduced. We had to improve testing and kind of evaluate new tooling to find some kinds of race conditions. And there were several bug fixes, more than several actually. It was a long campaign, but over the years we were able to improve the reliability and I don't believe there's any open issues today. The downside of this grooming was that there were hundreds of other issues. There was good information in there, but we couldn't act on it. There wasn't enough contributor or maintainer engineer hours in the day to work on this stuff. So I beautifully categorized these and tried to see what they were and then promptly ignored them in the short term. But then we've been making slow progress on these. And so the issue count kind of trickles up, it kind of slowly increases over time and then as we groom things over three months it'll dark down. And it's generally speaking that this variety of issues is going down over time, even with a larger user base. Okay, working with users. I love users. I hate users. They are some of the most helpful people you'll meet that are logically part of your team, even though they don't write code. They're neutral. Many users are just neutral. They're reporting bugs and they're kind of doing an okay job and thank you for your effort. There's a third class of people that are less pleasant, break the standard to two categories. There's just angry people in the world and they find their place on the internet and they make some noise and just recommend ignoring them and not getting bummed out about it. There are abusive situations and please do report those if needed. The second class of kind of annoying users are entitled people. And these people keep asking, you know, when's the fix or, you know, where's the progress in this and you can usually see this more on client, client end user software than back in infrastructure stuff. But these people, they're not bad people. I don't think I think they just, they misunderstand their relationship to the project. You can educate these people. The phrase I like to use is this is a volunteer project. Pull requests are welcome. Just making it clear that your time is not their time, right? They don't have any control of you. And in fact, I would flip the script when you think about your users. Users should work for the maintainers. The maintainers are fewer than users. Users have, there's more of them and they have more time. So if you work in the clarify users, clarify issues and to test proposed PRs, investigate workarounds, improve documentation and wikis, sometimes you just have to ask them, hey, can you look into this? And it's just kind of increasing your team, which we'll talk about later. Okay, putting your PM hat on, I would say that releases are important. Some projects, especially older projects that don't run releases very often. Maybe every couple of years, even when they're merging commits, and at least the kind of forks and kind of duplication and confusion. And so I just emphasize that most users consume release versions, not development branch. So you really want to have regular kind of time based releases, this is pioneered by Chrome, but I think that you don't need such an aggressive four week schedule that can be exhausting for users. But I think even every six months is valuable. And so I plan to run a release of most of my software every six months, even if there's not a huge number of changes. Still people are waiting for some of those those fixes. And of course, if there's an immediate critical bug fix, you try to run a release sooner. In terms of sustaining your sanity, you want to avoid buggy releases. And so this is twofold. One is which is it's bad for your users if they're having buggy code and it creates work for them. The other thing is it actually creates work for you when they file an issue saying hey this this release doesn't work and there's kind of a long tail of people using old versions of the moment that you will essentially be re diagnosed in the same bugs for until those older code filter out of the ecosystem. So to avoid buggy releases I open a tracking issue. I ask some of the users to test it like people are waiting for these releases they're usually happy to test it in their environment. You have to you have to slow down changes during this time. I've had some situations where I had to open PR. I said, you know what this is too risky for the next release we're just getting it next time in six months. And that's okay. You want to be aware of users reporting new bugs against old versions. So this, a lot of people let people run older versions of software and it's worth understanding why there's oftentimes stale Linux distribution packages or API breakers to prevent upgrading important regressions. But these these new bugs against old versions you're basically making more work for yourself. If people are using the old code. So if you can measure them onto the new code, especially mentioned in your issue template, you know, please report against the latest version, and repent to free up some time for yourself. Okay, part two thinking like an engineering manager. So again this is advocating for the team. And maybe the most important thing to do to advocate for the team is to manage the project scope against the goals of the project and the volunteer effort you have available. The second thing that an manager can do is, they can bring more people and resources on to the project is kind of a couple of hacks for that we'll talk about. Third is coordination with extra projects. So you're upstream and downstream dependencies independence and finally dealing with forks kind of a quirk of open source. We have a lot of different conditions of the same thing. Okay management the team. So this, this differs from your normal manager kind of mindset, because usually you can't help people with to do. You can't ask them for help. And you shouldn't feel shy about doing this, just at mentioned people on GitHub. Hey, could you, could you look at this PR you worked on on a similar feature before. And this this is important because people, people don't watch the repositories and times where there's a flood of email or they're kind of batch processing, whatever it is. So the manager should try to identify, are there any blockers to new contributors to bringing these new people onto the team. And so the most important one is, do you have a bad environment. You know, are there people or users that are in your, your, get a repository, they're, you know, me, right or short with people or, you know, is it just a bad project to work with. There's there's projects I choose not to contribute with because there's one or more people that are just not a lot of fun. And I like, like this you're short. So build issues is maybe the second and more easily addressable thing. Can can users build your software out of out of a clean environment. So there's been a lot of progress with containers and other kind of mechanisms to deal with this. But generally is this project easy to run the unit tests on is kind of a metric that you should strive for. And to some extent, you know, there's the continuous integration you set up will have a configuration and figure this out, but you might need some documentation as well. So there's technical debt. If the projects to this was too rotten. If people don't want to contribute. It's just, it's difficult and it's not fun. If you're using older dependencies or older versions of software. It's, it's just exhausting to kind of go back in time and these things that are kind of semi broken. So if you're using license, my employer doesn't allow me to contribute to projects that only have an open source license. So please add one. And lastly, a clear code formatting can block people contributing. Especially in the review process if if you're having to comment on a lot of things and the user has to iterate with you on PRs to have your perfect code formatting. It's usually a bad time and annoying to the reviewer and contributor. So if you use anything that's automated like go format or the equivalence and see if I've lost the job. That tends to be a better experience for users instead of trying to guess what you're thinking. Okay, managing team, you can you can actually nudge issue reporters into becoming contributors. A lot of people are reluctant to, to try to contribute because they don't know where to start code is big, right. Most projects have tens of thousands or hundreds of thousands of lines of code and we're potentially much larger for big projects, but people don't know where to start. So if you just tell them, hey, can you go look at this, this file, right, you probably want to write a test in this other file that can kind of overcome some friction and get you a free fix sometimes. This is an outsource testing of PRs to issue reporters. They tend to be pretty motivated to test these things if it resolves their symptom. So, you know, don't test it yourself outsource it to them. And lastly, dependencies are logically part of your code, you ship your dependencies. So do you have a good relationship with your upstream projects, but do you report issues, you know, do you tell them like how the software is working or not working for you. Okay, managers should aggressively manage the project scope. And so there's a common anti pattern in open source software. We try to be everything to everyone. It's just really compelling that somebody comes by with a pull request passes the unit tests, you know, why not add this feature. And I, there's a lot of good reasons not to your maintenance burden will increase. And all those changes need to be merged upstream, even well written ones. And so look at, look at the, the contribution to say, you know, does this make my burden heavier lighter, if it's heavier. Can I ask the contributor to maintain that code. So came willing to merge this but you need to deal with all these issues that's my expectation. It's very easy to, to widen the project scope and take on new tasks. It's very hard to shed them. This is because there comes constituency within your, your project and one noisy contributor will say like hey I contributed that and I'll fix it, fix any bugs, even when they maybe they don't. I'm keeping practice of saying no or not yet, early and often. It's actually fine. You want for people's feelings just be clear with them about what you're doing. I have a kind of a negative case study for this. So jClouds is a Java cross project structure. This project was very popular 10 years ago. I had a lot of activity, both from contributors and users. The containers have shrunk over time. And this despite their, they're being a kind of stable user base and downloads that we can observe. And what's happened is, is a bad situation where there's more work being done by the fewer remaining containers. And so we take on a bunch of scope that we couldn't manage people that advocate to their feature that disappeared, or people that wanted kind of infinite backwards compatibility. So we just shrink the scope of the project. Kind of right size it. And there were a couple of people we tossed out a bunch of code that was, was unmaintained that there was no one that would maintain it and, you know, get you can always bring things back in later, just revert to commit it's fine. So we remove that stuff that was at flaky tests and that kind of thing. We outsource some difficult features to separate projects, things that we didn't have the expertise for we couldn't maintain. So we just jettison them. We did find other maintenance to them in this, this case, that's not always possible. We dropped a lot of backwards compatibility. This, this was really painful because they're, they're getting interesting hard to run both the newer and older versions of Java. And so we, we had preferred the old versions for reasons that are kind of related to the Java system, but that was the wrong choice for us. So we had preferred dependencies. This the sounds benign but it really wasn't some of these dependencies are really tough, where they have incompatibilities between versions and it breaks other people's downstream software. And so we had to make tough choices there to go forward. And finally we're optimizing the release process. We had many repositories to begin with, and now we're down to four, and that really should be one, just to make things as push button as possible for making a release. It's currently like 100 different steps to run a release and so you end up running releases less often, which is bad for users. And some of the sad thing here was a lot of these changes should have made years ago. We just made their own choices, and not that we're bad people. I don't think, but we just didn't think about our maintenance burden in a very rigorous way. We just kept saying yes. So moving to the forks. Forks and kind of re-implementation have several causes. The most benign of which is users just they need to fix now, they cherry pick a fix into their repo, and they will rejoin you in that release. So don't worry about those people, unless there's a lot of them for some reason go and release them. Or just local functionality that's inappropriate or not ready for mainline. Maybe it hasn't been made high quality enough or doesn't address all the use cases that you want to see done. But the last kind of fork is a kind of hardware fork, and that's when there's a difference of opinion, either in what the project scope is, you really want to expand it and do some different things, or licensing sometimes that can separate people. Interpersonal disagreement people that just can't get along and shouldn't be working together because they're hurting each other. It's actually, you know, some of these are good reasons to fork and don't worry too much about the presence of forks. I will say that reintegrating forks can unify the users and development effort. And this is to reduce user pain users can switch between different implementations sometimes, and that's fine too. We'll say that most forks will just die of neglect. But it's worth understanding their motivations. You know that these really do address pain points for users. But in the long run, whichever whichever the forks has more developers and maintainers will essentially live longer. There's just, it's just too hard. It's too much work to sustain things yourself. All right, part three thinking like a technical lead. This is probably the most familiar role to many of you. This is advocating for the technology. So the first thing you're doing when you're advocating technology is trying to protect the existing code. This tends to be more important than you could discuss a moment. Second, think about the project evolution over the long term. And long term could be one year, maybe maybe 10 years that we'll talk about later. Technically can make proactive technical investments in the project. And these are bigger than a single issue. And these might be using new tooling or rather than set increased the quality or make the project easier to maintain. And lastly, as a lead, you need to lead people need to communicate with your contributors and tell them what you're thinking, and maybe ask them about their thinking, try to understand what's going on with them. Okay, again, existing code is more important than new code. The cost of regression is actually much higher than you think things. It's not just fixing the initial problem, but this kind of echoes through time with with duplicate issues of people using old code. Or other other kinds of interactions in the ecosystem where people start depending on broken behavior or something like that. And so the most important way, more impactful way to to prevent this is to write writes and tests and use continuous integration. People always tell you that it's always true. There's just kind of a limit to what you can do in a volunteer project. But if I had to pick between unit tests or integration tests, I would probably pick integration tests. While a unit test has a high accuracy of telling you, you know, exactly where a problem is, it's low coverage, right, versus an integration test, maybe it does 100 different things, and one of them fails and you don't know which one, you can you can still gate a PR on that one failure and say hey, you figure it out and by the way, can you write me a unit test that for instance in the future. So code review is a great process. It really does increase quality of the project. It's also important to share kind of tribal knowledge about how how to work with the project. So this is really labor intensive open source projects we have a lot of new contributors or drive by contributors. And so you want to be, you want to kind of give the right amount of feedback there and don't don't overdo it. You want to automate things with with either linting or other static analysis tools that that can be good tends to be a false positive rain on some of those, you know, be careful about your time there as well. So one kind of trick for protecting code is that you want to take these giant 2009 PR is that users contribute and try to try to break those up. So once a big change goes in, it's usually pretty hard to figure out where exactly the problem was if indeed something is is progressing. So try to try to encourage people to write smaller PRs, maybe and spread them over a longer period of time where you might be able to either do a get rebase to get bisect to figure out where we're a regression stuck in, or when releases go out, there's gradually making these changes and you're gradually new test coverage. And the existing code you, you want to evaluate the proposed change say how does this interact with the current feature set, and maybe the future future set that we envision for the project, and maybe a simple example there would be a couple of examples for adding more knobs, and maybe you have like some cash size or something like that, and there's a knob for that. And the users will work around their, their whatever local issues they're having with another flag and the cognitive flags is pretty high. How do they interact with each other, do they interact with each other well. And so if, if you think like hey we're going to change how this works in the future, and we're going to have a smarter cash policy or something and this flag is not necessary. Maybe you say no to that feature and that user carries that flag in their local, local repository until you can have a proper fix and they learn. And if I would have technical risk, you really want to critically evaluate proposed changes, like, does it actually improve the user experience, or is it just something fun. You know, there's taking on maybe MongoDB or something I've had seemed really cool 10 years ago. And maybe you say we'll have infinite scale or something like that, but it's, maybe it was true maybe it wasn't. So there's different kinds of databases, maybe you would use and some of them are actually easier for free so they don't need that kind of scale and maybe nobody needed that scale to do this. So there's a proposed change limit your contributors. Let's say you're a Java based project and someone wants to write some closure, which is a Java based common list. And this was well received at the time and then that user disappeared and no one on the team new closure and so it kind of limited our ability to modify that piece of the software. And so, you know, be careful with the things you're taking on. We can really limit your contributors who don't know all these tools. And then look at whether increases or decreases the maintenance burden. It decreases it. That's a good sign, right if it adds a test that that is that more code but it kind of increases your confidence in the software and reduces the regressions. If it kind of removes functionality that it's not really being used that that's good for you as well. If people are adding new things that have kind of expensive cost to you. You can say no, or maybe you need to change that to be something that's more compatible with how you're looking at the software. And there's a great talk a couple years ago called choosing boring technology and thinking about the innovation tokens and these are finite and number maybe have free musk coins, Elon Musk coins, and you want to spend them wisely and maybe not spend them at all, or spend one or two of them. Like, if you're starting a new project where we're taking on something new, like, you're, if you're spending one of these tokens, what will that dependency or feature you're taking on with that. Essentially will that be over the long term, or will it create more problems for you over time. And so the, these are the talk with shoes boring things. If you don't have, unless the situation warrants it, and so that's, it's kind of just being safe. And the reason for this is if you take all the risks. One of them will get will burn you pick all the shiny objects. And some projects start with that way. You just get weighed down by one of one of those unlucky choices. So thinking about the project evolution. If you're taking on a new library will that new library have maintainers next year, where you have to start maintaining that library yourself as well. It tends to be like older projects tend to have a bigger community and live longer, and so they have a advantage that you maybe trust them to be around in the future as well. Okay, technical debt. This is a lot of meetings, a lot of people that I would say that any issue that increases your development friction, this technical debt. There are testing tests, flaky tests, or slow tests. The number of hours are potentially day or that I've wasted on tests that had unnecessary sleeps and, you know, or the test took two minutes instead of one minute. So this is just worth fixing. And of course flaky tests, the things are randomly failing. It's not good because you spend time diagnosing that flaky failure. And I would even say just just disable that test is not complete. Remove it or disable it until someone can fix it. This thing tests are tough. You know if you don't have test coverage you essentially in the dark for regressions. Those are usually harder to backfill. A lot of work to backfill. Other kinds of technical debt include outdated dependencies. This, this can be, this can be buggy, maybe security holes or things like that, and upgrading tends to at least give users confidence, your engines are confidence that this project takes these issues seriously. Obviously, unnecessary dependencies are possible to where maybe the standard library of your language takes on certain feature that previously was your part of library for. It's good to kind of react those. Those can even be good first bugs for potential contributors. Hey, can you help me with this kind of thing. And generally you, if you can you want to move from entry custom implementations to shared third party libraries. So this is to decrease your burden. You want to push those things out or use common code. This is easier to reason about for new contributors. Let's work for you. And similarly, I look at can you push features out of your project into other projects. This could be the custom implementations or could be even little libraries. So I long story, but I had written a HD to be clone HD been clone in Java. And it was one of the testing things I had written. And it was just better to push that out in its own project that has a couple of contributors now it's more useful to more people. And I would recommend that you try to pay down some of your existing debt before you take on new debts. And if you move the technical debt you have to the credit card and if you hit the limit, you're usually in a bad situation because you can't keep borrowing against the credit card. So try to pay down some of that debt before you take on the ones. Here's kind of a negative case study again from a three of us. This, this implements a S3 client via lip curl. This is this is for a good reasons this was done back in 2007 for C++ third party libraries existed. And I think this has been a source of bugs, you know all sorts of things with URL encoding and all the silly things. And we fix this gradually over time. But there's other features that are more difficult. Mostly advanced authentication mechanisms. And these are missing in S3 of us that are present in most other S3 applications. And it's frustrating users they don't understand why we wrote it this way. And so we can actually fix this. We transitioned to the AWS SDK would address this debt. It comes with some trade offs. Or as a new new reciprocals compiler and we could probably do that easily. We've heard some of our legacy users, but I'm personally factoring that it's not a lot of fun. Not a lot of times but always always defer it. It's always something more important to do. And unfortunately the maintainers, me and the other maintainer, we keep paying the short term costs fixing these little bugs, instead of addressing the long term issue. It's always, I'll do it tomorrow. And we said yesterday. So technical leaders need to get me the habit of thinking out loud, and maybe over communicating. And that makes some kinds of collaboration more difficult. You know, you can't just have a coffee with someone and hash out, you know, your technical issue or maybe even interpersonal issue. And so you want to foster a sense of community with your contributors and users. And this is more than just sharing your code, you want to share your ideas. And so you can do this and get have issues. And some older projects have mailing lists. Those are good too, especially threaded discussions. Twitter Twitter's okay, but you essentially want to say it like hey you know this this is what I'm thinking about this feature. What do you think. Right. And maybe you can improve your design that way, or maybe it's just a heads up to people like this is, this is coming, you know, do you have any, any objections to this and maybe in front load. Some of this before. And would buy us towards over communicating. Just just tell people you think you know I just like to be loud, being loud is my favorite. You can share work in progress commits. There's some people that are shy about contributing but if you show them like hey this is my process, you know, and here's here's something incomplete when I'm iterate iterating on maybe they'll feel more comfortable with the project. And again, you're trying to keep people really heads up about things that might be happening in the project. You want to talk to me or design somewhere other than code non developers rarely read code comments. I just put, just like, you know, sometimes a paragraphs enough, just put it in the, in an issue, or commit messages is okay PR wikis or, you know, markdown files in the main repo, often times better. It's just more accessible to users than trying to figure out, you know, connect these this function to this function the code and say like is this what did you mean here. It's just an explanation of like how maybe how a cache works or you know how how errors are handled or never cares or something like that that can actually be really valuable to your users. Okay, thinking about sustainability. That's part of the talk. So I've described to you more work essentially, which some of you may be scratching your head like how will this sustain my project. What you're going to need to make is you need to write less code to do these other things. And that's kind of not not really what I want to be doing, but I want to make these projects successful and so I do them. And so the kind of the thing I have my head is I want to do fewer things and I want to do them over longer periods of time. So just thinking about like, if I have n work I'm going to do over two years, maybe instead I will do, you know, sort of in half and half work every year I'll do and over 10 work or something so I can do things for five years instead of two years. And that's, and that's just thinking about stretching yourself out over time these projects have a lot of value with age, the more people adopt them, and you want to make sure there's consistent in the kingdom. Sometimes it's better if the original author just step aside and let others maintain the project, just because you created something or contributed to it once isn't like a lifetime guarantee. And if you can find someone that's better to take over the project or collaborate with, please promote them to from contributor to maintainer. Yes, that's good for you and good for the ecosystem for everyone. And I've been in projects with the original author step aside, and that was fine. They moved on to new projects and created new great things. And, you know, no, no hard feelings there. So, I think that it's, you want to think about the long term as a maintainer. It's, I think it's entirely reasonable to think about where do you want the product to be project to be next year, you know, that they kind of allow you to make some more meaningful investments and maybe tooling or testing or, or something that, you know, I'm going to be around a year. I want this project to be better for me and better for our users. I want this project to get there because that's probably not just fixing a couple issues. I might be, you know, thinking about some kind of speed or compatibility or data, data integrity or something like that. And I think it's reasonable to think about the project. It might exist in 10 years. Maybe you're not making a year by year plan. But, you know, is there some, is there somewhere you're going as a project. Sometimes it's useful to have a big idea, right, like J Cloud's idea is to create the widest across cloud abstraction that it can. And that's a kind of a good goal. But how are you going to, how are you going to get there you need to keep opening the aperture of this compatibility over time with more providers and more API is this kind of thing so think about how you're going to get there. So ask yourself a couple questions. What, what kinds of changes are truly impactful for your users, because it's really easy to just be reactive. You fix random issues. So here's, here's an issue, there's an issue, boom, no progress. And that's the reason that's not good is because there's a lot of users that kind of advocate for things and change the story, like how with things you think are important. So you really want to put your product manager hat on and think about what is most important. And are there any broad themes you progress on performance, probably these kinds of things. And so your project may outlast your interest in it, and can you prepare for the next maintainer, and sometimes that doesn't mean like hey you over there you you need to maintain this now all that that's really great when that happens. So keeping the project in a state of good repair is a good idea. I've seen a couple projects where the maintainer quit kind of rage burnout and that was tough for the project to move forward. And so you really kind of want to reduce your involvement over time for planning to move instead of just up in my way. Think about your, your commitment to the project, how much time you really want to spend on this project per month on this project. And I think that there's this kind of three buckets you put this into one hour, I think you can effectively maintain some project with one hour a month, you know, just reviewing PRs and periodically, periodically cutting releases, that's that's fine. So if the first month is a little more interesting, you can actually kind of invest in the project, and not just be reactive, and maybe you work on, write some code. It's usually fun. There are projects that you can put 100 hours in a month and two. I've started some projects for the first month was pretty intense and that was great. Certainly couldn't sustain that without corporate sponsorship. It's not your day job, where do you get that kind of time from. So when you, when you think about your time commitment, think about setting a budget, like I am going to spend an hour on this project every month. You know, maybe you don't review all the PRs you don't respond all the issues when you just pick the things you think are important, and then you stop. And that's okay. Because otherwise you kind of tend to just go in random directions and oh this looks interesting now you know maybe I'll spend five hours in this. And, you know, maybe that's fun. And maybe it's okay that happens but when you think about maintainership I really think that if I'm going to do one hour of maintainership then I need to do that one hour. Also think about the quality of service you want to provide a lot of developers work in interrupt driven manners and they kind of context switch between things and that's expensive. And a lot of the work we do require concentration. And so it might be better to batch process things and so you know I'm going to look at these issues once a month once every three months maybe some projects and work through them and to keep all that context in my head. This can also be good batch processing because users can kind of figure out things on their own sometimes and maybe you didn't need to be involved and react immediately. And reminder that not everything needs to be done today. You know there's always tomorrow. And maybe maybe something never need to be done. There's certain kinds of features that kind of come in into a fad and then go away. Cloud providers and all sorts of things and you know maybe they, you don't need to do this and you can always say not yet. So wrapping up here, kind of hit the main points again, you want to prioritize the issues are important to your users. You want to enable contributors and outsource as many tasks from you on to the community that you can make technology decisions that allow you to evolve the project over the long term. It's okay to say no or not yet say it early and often it's okay you will not hurt people's feelings and think about the long term. So this project will be a lot of projects are still used a year or 10 years after the creation and they are valuable that the small ones that becomes an everywhere between. Thank you for your time. Thank you for the slides at call that works on Fox, and I believe there's a chat Q&A following this. Thanks again.