 content warning. This talk is about burnout and stress, and in the process of unpacking a common software engineering metaphor, I spent a little time talking about war and the consequences of violence. Also, especially given the tenor and the content of today's talks, I feel like bringing up that this is a story without a clear resolution or conclusion. This is about a process that I and my team are going through. We're in the middle of figuring things out. I don't know where I or the project where my team is going to end up. In large part, this talk is about figuring out how to stay healthy or at least functional while we go through this process. I also want to take a brief moment to give my sincere thanks to all of the speakers who spoke this weekend. I feel almost a sense of responsibility to not let everybody down being the last speaker, especially in the light of how incredible and moving so many of your talks were. Also, on a more prosaic selfish note, a lot of you gave parts of my talk for me, which means I had a little more time to talk about other things. With that, let's go. You're all ready to spend just a little bit more time talking about open source and feelings? All right. I'm Forrest Laywalder-Norval, and I'm the manager of the team that maintains the NPM command interface. My background is in backend web development, which I've been doing in one form or another since 1995. I've been doing this job since 2014, when I took over maintaining the NPM CLI from Isaac Schluter, who wrote basically the whole thing while running NPM's registry and NPM's website, and also the Node.js project, something that seems pretty inconceivable to me now, but maybe isn't for reasons I'll discuss in a bit. Quick check. How many of you heard of NPM? NPM's big enough now that people far beyond its original audience of server-side JavaScript developers pay attention to it. It's a general purpose package manager for JavaScript, and if I have anything to say about it, it will eventually be an indispensable tool in every web developer's toolbox. This chart is taken from a web post that came out on Monday by Philippe Hoffa, and that highlighted, at least when it comes to issue comments and a number of people making them, NPM is actually among the most active projects on GitHub, and this is actually a tremendous validator for me and my team, and probably the whole company, because we feel that activity. We feel that in our bodies and in our souls pretty much. In this talk, I've tried to concentrate on what's happened to NPM that's applicable beyond the bounds of our project, but I kind of hate empty thought leadership, so I'll start by saying this is a story about the challenges our project has faced, and our story is not the same as yours. NPM's CEO, Isaac Schluter, spoke at the first open source and feelings last October. Yesterday afternoon, you heard my colleague Rebecca Turner's talk about defamed popular technologies and why they were important. My other colleague, Cat, is here, meaning my entire team is with me. The values of this conference are near and dear to our hearts. We have some big problems to solve, and they are problems that this conference speaks to. One of those big problems is burnout, a problem that NPM shares with many of other big open source projects. I promise you, every week I hear stories either from my friends in open source or concerned friends of my friends in open source that one or more of them is in the process of burning out. It's been feeling like a bit of an epidemic for a while now, so let's talk about burnout. But first, I love you, Wikipedia editors, never change. Anyway, the last OS feels opened with a powerful talk by Jacob Kaplan Moss, who used to be one of the primary maintainers of the Django content management system. I say used to because his talk was in large part about the process by which he came to no longer be involved with Django. Thanks to Carolyn Moore's great talk yesterday, we've learned more about that process, which is called burnout. Jacob pointed us at this page, which is a dry, methodical rundown of the manifestations of occupational burnout. I felt such a strong sense of recognition upon reading this page that it caused me to largely rewrite a talk I was about to give myself. Seeing myself described so clinically and accurately was a real wakeup call. I think it's a page that's important for everyone involved in open source work, paid or otherwise to read. One thing that many people who work in open source shares a strong sense of mission and that mission, that desire to be helpful, causes many of us to try to do impossible things. If there's one thing I want you to take away from this talk, it's to keep that sense of mission in perspective and remember that everything starts, as Carolyn said, with all of us taking care of ourselves. You've got to put your own oxygen mask on first. You can't help anyone else when you're incapacitated. So NPM's company values are rooted in intent-based leadership, nonviolent communication, and a deep commitment to work-life balance. These are all healthy, sensible things designed to keep us happy and productive. So how did we end up in a place where many of us, particularly in the company's management, are frequently on the edge of being burnt out? Let's talk about numbers. Those of you who follow NPM are probably familiar with this chart because Lori Voss, our CEO, likes to trot it out whenever possible. It's a rolling average of the last 28 days worth of downloads. There are many interesting things about this chart, but one of the most interesting aspects is its shape. If you can't make it out, it's the exponential growth curve so beloved by investors. NPM distributes billions of packages a month, and if there is a limit to its growth, we haven't found it yet. But let's put that growth into perspective. Here, I've taken that number of downloads and set it next to the number of people working for NPM Incorporated. This is an extremely inexact picture of reality. The two numbers are on vastly different scales. This includes everyone at NPM and not just the CLI team or engineers in general. It doesn't say much about how many packages people pull down at a time, but it gets across the way I feel, which is that the size of NPM's audience is growing far faster than the team that supports them. Here's another picture of that same data, which involves some frankly absurd numbers. Around the time I started at NPM, there were about 50 million monthly downloads for each employee at NPM. Now, there are close to 200 million. That's a lot. Even with some fairly conservative assumptions, that represents several hundred thousand users relying on the work that my team and the rest of NPM do. No pressure. This is the first important point I want to make. Popularity scales geometrically, teams don't. There are inflection points at which things feel different, strategies that used to make sense no longer work as well. NPM, the project that Isaac started back in 2010, was not NPM, the project that he was supporting when he took on leadership of the Node project in 2012. That NPM was not the same as the NPM he handed off to me in 2014. It's changed several times since then, at a rhythm of every three to six months, so much so that I think Isaac's mental model of what it's like to run the project no longer applies. There have been several points along the way when things have just stopped feeling like they did before, and things that seem very important or top of mind. It's like weather or climate or seasons. It's deep and it's structural and it's cyclical in some way that I don't really even understand yet. Put another way, before I can figure out where to go, I need to know where I am. I have to step back and figure out what's actually happening with the project and around me right now, before I can figure out where to concentrate my team's resources. There is a constant barrage of information and noise coming in, through social media, through the issue tracker, through any and every communication channel you can think of. When I started getting Twitter DMs from NPM users at 3 a.m. in the morning, I knew that something in my life had changed, hopefully not permanently. A skill I've had to improve is to not let the volume or urgency of the community's communication set me on fire, to sift through everything and find the important details without taking on for too much of the emotional load that accompanies it. I want to stress this several times, like this is emotional labor. Almost all of the work that I and my team do is emotional work. It is the code is important, the code is critical to the success of the project. My team is very talented, but at the same time, the most important work we do is in our relationship to the community and tending that community and keeping the project oriented in a certain direction. So I'll put out a little hyperbole here. These are from Nicholas Acas, who is the lead maintainer of the ESLint project, another very popular open source tool. He says once an open source project has more than a dozen open issues, it's basically impossible for one person to keep up with every issue. I'll give you a little spoiler. There are a few more than a dozen or even three dozen open issues open on the CLI issue tracker. Last time I looked, it was about 2,400. The MPM CLI team, me, Rebecca Turner and Kat Marchand are extraordinarily fortunate to have three people dedicated to the project with the resources of a company backing us. The vast majority of open source projects don't have companies backing them and even fewer have paid dedicated contributors. But even so, it's nowhere near enough to handle the demand from your users. There's no way we can scale the team to meet the need. I think that the need is always going to outgrow the pace that we can sustainably grow a team that can handle that need. Once popularity passes a certain point, it's basically just a living raw fountain of need. It will never stop. And this is like the reality of the place where we live. That said, we've tried a bunch of different approaches and they've all been useful, so let's go through them as well as where and how they've broken down because they all have. So this is a pretty obvious first step and is how Rebecca and Kat ended up working on the CLI. If you've got the money or you've got the motivated volunteers, even one additional person working on a project with you makes it feel a lot less intimidating. Like the jump from one to two has the biggest impact on how a project feels because you then have somebody who you can talk to who understands what you're saying and can shoulder that load with you. Again, emotional labor. First problem, the great thing about a Creative Commons is that people who want the help will just show up. That's fantastic. On the other hand, there are no guarantees that the skills or the inclinations or the motivations that they bring to the project are going to be the skills the project needs or at least needs right now. Quite frequently, people will want to write new features. Quite often, the last thing you want to add to a popular tool is new features. Like the thing that gives the people the reward and the sense of fulfillment are quite often not the things that the project needs to move forward. Also, growing an open source project team is just like growing any other team. People who are going to be working together need to share goals and values and finding those people takes hard work. The fact that the people working on the team may or may not be getting paid for their work and are motivated by a shared love for whatever the project is for does not make it easier to find people who will be a good fit for the project and the existing team. It can often make things considerably harder because it can be hard to understand why an offer of free labor might be turned down by a team that very obviously needs help. There's also a whole other conversation to be had about who can afford to do unpaid work on projects, what kind of people can afford to do unpaid work on projects, and another whole conversation to be had around open source values. Both of those conversations are important and way beyond the scope of this talk. Open source developers have a tendency to try to reduce things to code and to architecture and to pretend that the rest is noise. In my experience, and I think the experience of this group, that isn't true at all. And if there isn't some basic consensus or cohesion around values, the project is going to lack direction, or even worse, end up mired in arguments over basic stuff, like how code gets released and what voice to use in responding to issues. Like teaching people on open source communities to respond to issues with empathy and with patience and with tolerance, it's not a natural skill to a lot of people, especially in the open source world. So that takes a lot of time and effort that that additional resource kind of absorbs from what you were trying to gain by building it out. The next thing you can do is to both have a clear documented process and to be very transparent with your community. And I really wanna give a shout out to Sean for the talk he gave yesterday because a lot of the stuff in his talk are both things that we do or things we need to do better. And I think that that was a really useful summary of a lot of those things about doing open source work in a documented reproducible, transparent kind of way. You know, you can have things like road maps. You can add tooling and bots to help shoulder the load of managing a big complicated issue tracker. You definitely want to codify and document your process and you want to promulgate it. All of those things are very important. There is immediate thing that comes up, which is the process has limits. Having a clear documented process is sort of a magic trick. It helps outsiders understand what you're doing and why, which gives them the context they need to let the team have the space to work. Also, taking the implicit structure of how people are doing things and codifying it into lists and checklists removes a lot of cognitive load from everyone working on the project. But sometimes you just gotta think and argue and muddle your way through. There becomes a point where a process gives you diminishing returns, especially as there's more work for the team to do. Also, I don't think I have to stress this one too much to this audience, especially after today's incredible moving talks. But technology professionals often seem to believe that the solution to every scaling problem is more technology. Intel machines develop a lot more empathy and I'm willing to believe that maybe they will someday. A lot of the problems that have to be solved support understanding how to get your project to fulfill user needs, hammering out differences of opinion when users want your tool to do something different. All of these problems need to be solved through conversation and interaction between people which takes time and emotional resources. Also, this is kind of a little thing that's I think maybe specific to larger projects, but you will probably encounter it at least a couple times in your open source career. We use GitHub issues to track feature requests and I started organizing those in the categories to keep track of all the useful functionality people were proposing and to kind of come up with a master roadmap that we could use to kind of build out what order the team was going to do things in. At the beginning of this year, Rebecca and I sat down and went through that list and Rebecca's best guess was there was about 10 years worth of work for our current team in there. Putting my manager's hat on, I'm gonna say that's functionally equivalent to never. We're never gonna do all that. Think about Nicholas's tweets from earlier again. Coming up with an idea, even coming up with a really good problem statement which is something that every product manager craves is much, much easier than building the feature and figuring out how to integrate it into the rest of a complex project or product. Also, this is one that I have learned hard core in the last year or so. Transparency is an incredible commitment. You can't just say what you're doing. You need to make sure that that knowledge reaches people which gets harder and harder the more people are using your project. NPM has, let me see if I can just freestyle this all out. We have a blog that probably reaches 10 to 15% of our audience. We have several Twitter feeds, some of which are used to retweet others that probably reaches about 10 or 15% of our user base. We put an extraordinary degree of effort into our release notes to make the usable for our end users. Generously speaking, that reaches about 10% of our user base. We have, we speak at conferences. We are on podcasts. We are doing things like this. That reaches another, I don't know, two to 5%. There is no single channel of communication that we have that we can use to reach everybody which leads to me to another one of my kind of left field observations that I came up while working on this talk which is, it's probably a good idea when you're growing out your project to find, to define and to nurture one means of communication with your users at a time and make sure they all know about it and are paying attention to it like, I don't know, piggyback it on a webcomic or come up with lots of good dad jokes. I don't know. But if you decide to change it and you probably will because the needs of a project is at scales are going to change, shut down the old channel and move everybody over to the new one. Learn from our pain. We have so much difficulty just letting people know that there's a new version of MPM out even when it's got something really important like a security fix in it. So, keep that in mind. So, Triage has proven to be the most essential tool that I've had available to keep my team moving forward which is good because my team has been operating in the state of Triage for two years now. This is kind of the hardest part of this talk for me because this is the part that I feel most keenly as a leader of my team and as somebody who has been living in a state of pretty high stress for a really long time now. Before I proceed and talk a little bit more about Triage, let's talk about the word for a moment because it's a useful concept but it brings some really heavy baggage along with it. It's the name for the process by which medics dealing with battlefields and other catastrophes sort victims such that the people who need most help and can most benefit from it are prioritized over those who are either relatively unhurt or too far gone to be worth the very limited resources available. Like a lot of metaphors we use in software it's hyperbolically harsh and sort of casually brutal but there's an important truth in there. When you're triaging pretty much everything you're evaluating is important. Maybe even critical. It's probably really critical to somebody out there in your user base but you as a team have to be reasonable and only commit yourselves to what you can actually do. This is important for you as members of the team as well as for the people who are consuming your project. Don't set yourself up to fail. So, MPM has a maximalist goal. We wanna be something that every web developer is trusting and relying upon and we want everybody to be using our tools and benefiting from the giant commons of code on our registry but it requires a minimalist focus. We only work on one or a few things at a time. If it's not essential right now throw it overboard. The goal is to know where we're going what's the smallest number of small steps we can take to get there. Often, nearly daily we have to let go of things we care about to focus on things that are more immediately and urgently relevant. So, the first problem with this is pretty obvious. Living in a state of triage is hard and often frustrating emotional labor. Everybody wants their highest priority to be our highest priority and constantly being called on to explain why is exhausting and occasionally dismaying. This is where the difficulty of communicating with our users gets especially challenging. I think that one of the challenges of guiding a project where anybody can contribute is that instead of the traditional role of product management where you say no to almost everything, open source challenges you figure out how to say yes. Even so, we have to say no to things. Feature proposals, pull requests, prioritizing certain bugs every day. It's hard, I feel this personally. Because we need to fix the bugs that cause support requests and because we need to address the usability issues that make NPM confusing, we don't have the time to address support issues. We don't even look at them most of the time. Because we want to be clear about what we're doing we close most incoming feature requests sometimes with some encouragement to the community to tackle those issues themselves if they have the resources to make it happen. Because we need to keep the tool useful and learnable we have to reject requests to merge pull requests that do things that seem perfectly reasonable to the proposers sometimes without a whole lot of feedback. Because we can only do so much we often have to defer what feels like important and urgent work like say making the CLI faster or more secure a ways down the road. None of these decisions come easily. Triage is a tool for managing crises. It's very effective for that but it doesn't solve the problem completely. Eventually there's nothing left to throw overboard and now you're down to the bare floor of what it is you can get away with not doing. There's nowhere left to go. What now? I think the place I get to sometimes is really accurately captured in this Twitter thread from my friend and former colleague Alice Goldfuss. These are only excerpts from the whole thread. When I put my slides online all this will be linked so you can go through and read the whole thing. There's a lot of other good thoughts in there particularly around how you end up relating to your community and your peers when you're in this state. The fun thing about burnout is it never happens to people who don't care about their job. People say too much work burns you out but you can't be overworked if you don't care about your job in the first place. Burnout takes people who care a lot about their jobs and makes them not care anymore. And if you're seeing those burnout sentences too you know that the only way to head them off is to care less. So the price for caring too much is feeling like shit and the cure is to stop caring. Here Alice is speaking with burnout's voice. It's worth keeping in mind that occupational burnout is a form of depression. What Alice is saying here may or may not be factually true but it's definitely emotionally true. I've lost track of the number of times where I've told my boss some form of the only way out of this is to stop caring and I don't know how to care less. I have to care about the things I'm working on just to get anything done. I believe that this is the crisis point that many open source projects reach. Somebody writes a useful piece of code other people come to rely on it. Conscientious maintainers do their level best to support their user community and that community grows to a point where no team of maintainers could possibly address all of the community's needs. Figuring out how to navigate the situation has been the problem occupying my thoughts for most of the last year. First I have a set of things we do as a team to help keep the project on track and then I have some thoughts on how to take care of yourself in the process. First off, it's important to have a definite goal in mind for your project and your work. That goal should be something towards which you can tangibly feel the project growing closer. What burns me out the most is when I feel like we're working furiously just to stay in place or we have no idea where we're going. On the flip side, I can put up with a lot if I believe I'm getting where I need to go even if it's only slowly. Second off, know your values. What do you care more about? A good experience for new users? Performance? Ease of maintenance and extensibility? There are always trade-offs. Look at Rails. Part of its success has to be due to the fact that David Handemire Hansen, which I have the age of from my notes because that's how I think of him. But anyway, has always been very clear that it exists primarily to fulfill 37 signals needs. He has a very definite use case in mind for Rails and that has given it a focus that it's needed to retain its forward momentum and retain its focus and coherence as a project. For me, it's just as important to know what I'm not interested in doing. NPM can't be all things to all people. As product managers, we need to define a few things it will be good at and focus on those. Trying to balance too many competing demands is stressful and likely to produce something that really satisfies nobody. This is an interesting thing. Focus on what you're good at. Give yourself that permission. You started working on this for a reason and maybe the reason wasn't answering support tickets on weekends. You know, if that's perfectly valid, if that's the way you feel, then follow the recent example of a lot of projects and just turn off your issue tracker and only accept pull requests. That's fine, I give you permission to do that. Maybe it's writing code. Do that. I give you permission to manage your project in a way that makes sense to you. I give you permission to find people who are more interested in doing those other things than you are and handing that work off to them. It takes a lot of different kinds of personalities to make for a successful project and you shouldn't feel bad because you're not good at all of these things or you're not interested in all of them. This is a lot for a single slide. As Caronda said yesterday, in a very different context, being kind is better than being nice. When we decide, as a team, that we're not going to implement a feature request, we thank the filer for their time and close it. When somebody tells us our priorities wrong, if we disagree, we say so. In the long run, it's much more respectful of everyone's time and energy to communicate clearly and directly. Don't feel bad about talking to people as one adult to another. Assume confidence and good faith on everybody's part and presume that they will in return extend that courtesy back to you. Another big piece of this because I really only kind of touched on one of the core aspects of my reality, which is just getting hit by a huge wad and entitled nerves, day in, day out, saying, why isn't my thing fixed yet? What are you working on? How are you spending your time? A thing that we have had to learn to do, the most important part of emotional labor that we've had to kind of pick up a skill at, is learning to respond rather than react. Developers typically don't come to an issue tracker unless something is frustrating them. Remaining aware of that and responding to the underlying need rather than meeting frustration with frustration is much more likely to lead to a positive outcome. One of the most important things I've learned while doing community management is that my desire to be light gets me into trouble. Jokes and sarcasm are tools that I reach for frequently to diffuse awkwardness or to remind my friends that we're friends. It's really easy for that to go wrong. Especially if I'm feeling frustrated, people can pick up the right intent with the wrong words or the wrong intent with the right words. I try to not leave much to chance. Our issue tracker's pretty dry, that's on purpose. I wanna make sure that people understand that we are speaking directly to them as adults and that we're not trying to hide anything and that we're not trying to be defensive. Also, here's a potentially controversial piece of advice. Try to avoid tone policing. Moderation and enforcing the safety of your space are very important. But as soon as the conversation becomes about how the conversation is being conducted, the odds are good that the productive parts of that discussion are over, probably permanently. It's better to disengage and move on to the next issue. There are always more issues. Also, put time into your team. A burden shared feels much lighter than trying to carry it alone. If your project's smaller, then you're not likely to have a whole lot of collaborators working on it. But there is a huge network of us. I have these interactions all the time now. We're on talking as a maintainer to another maintainer. I just had an interaction yesterday. I'm gonna totally mask Kerr's name. Ferros of Buttigieg. Whoo, I think I got that close to right. The maintainer of the standard code style for JavaScript, which is a whole other story, was tweeting about somebody showing up in his mentions with a whole lot of aggression around how he was running the project and how he was dealing with their issue. And one thing that we can do is just say, yeah, I hear that, that's tough. Like, I'm here with you. I gave him a little fist bump emoji. That's something all you need to do. Find those people, lean on them. You cannot do this stuff alone for very long. In light of that, there is a conference that Jesse Frizel, the Docker community, is organizing for some time next year. This is a conference for maintainers. These are our people. We need to find these, we need to get together and figure out how to get together. And I just really like the conceptual idea of the won't fix cabal, because it's a joke that really only makes a lot of sense after you've been doing this for a little while, and yeah, like, no, we're not gonna do that. Sorry. So, on to the last section here. My colleague and manager, CJ Silverio, who knows a thing or two about making it through hard times to the other side, frequently tells me that I need to take care of myself. To put on my own oxygen mask first before I try to solve the problems of my team, my company, and my community. I've had to think pretty hard about how to do that well. Once you get through the basics of self-care that Caroline talked about. It's, I'm, I have a very powerful super ego. I do not give myself permission to take much time off. I do not give myself much time away from this. And thanks to social media, I have an external super ego to help me out in case I ever start backsliding. So, here's a big disclaimer, and I think it's important that I say this. I am burnt out all the time. Preparing for this talk has been a hard process of extracting useful lessons and trying to avoid lying to you. This work is hard and worthwhile, and I am constantly trying to figure out how to do it better without exhausting myself and stressing out the people around me. My success is frequently partial. The following notes are for myself. Without the backing of MPM's management, without Kat and Rebecca, and without the involvement of the community, and especially the small number of volunteers who shoulder the burden of community management day in and day out, my job would not be tentable. It's essential to have people to talk to, to share the load, and if you're like me, to process things. Rebecca, Kat and I are defined in part by our desire to help people and be useful. We believe that what we're doing is important. This is kind of dangerous because it helps us set standards for ourselves that nobody can reach, and it makes it hard to withstand the social pressure when a catastrophe like left pad happens. If you somehow don't know about that, and thank you to Emily for her discussion of it earlier today, the upshot is that a dispute over who got a package name when MPM's registry escalated to the point that the substantial number of the internet's builds started breaking, and it was extremely messy and traumatic for everyone involved. And I will just tell you that if what was happening outside MPM looked messy and chaotic and painful, it was orders of magnitude of worse within the company. There were relationships that were semi-permanently damaged within the company. It was a rough time for all of us, which is, I'll say, why I get so touchy about people talking about it in social media like it's some kind of joke. But that's because we care very deeply about our mission. We care very deeply about people's builds working. We care very deeply about honoring the creative commons that is the MPM registry and people's ability to participate and to not participate in that commons. There are a whole host of complex interrelated concerns there that are very difficult to break down and very important to handle with responsibility. A very important tool for me in doing the work that I do is nonviolent communication. At the last open source and feelings, Isaac, our CEO, and Alex Harms spoke about nonviolent communication. The talks complement each other and about as good a concise introduction to nonviolent communication, which is notoriously unapproachable to newcomers as I can imagine. I recommend them both highly. Nonviolent communication needs to be retooled a bit to work as a community management framework. Those of you who've been in activist circles for a while know that there's kind of a weird valence around nonviolent communication. That it can be used as a tool for control and a cool tool for undermining and gaslighting as much as it can be used as a tool for good. And that it gets even more dangerous when you are presuming a situation in which the audience you are addressing is not necessarily conversant with those tools. I've kind of boiled it down to its essentials for the work that I do in interacting with NPM's community. Really, the first step is to trust the ouch. When somebody tells me that something is a problem, I don't try to argue it with them. Also, I try to immediately hear the need, which is kind of one of the core tenets of nonviolent communication. What is this person actually looking for? Is it just to be heard? Are they actually expecting an action from us? Try to boil it down to that basic need and respond with action. So instead of having a debate about things, instead of being contrary and just try to figure out what's the thing I can do that will resolve this user's need and get us to a point where we are actually communicating with each other. It has been an incredibly valuable tool. And again, it's difficult to learn and it's easy to abuse, but it's one of those things that if you are spending a lot of time interacting with other people, you spend your time doing a lot of emotional labor, it's worth the investment, in my opinion. So, Zen is a stripped-down form of Buddhism, and Soto Zen is perhaps the most stripped-down form of Zen. It's focused on Zazen, just sitting, almost to the exclusion of all else. Soto Zen uses meditation as a way to see things as they truly are and the emphasis on learning to calmly let thoughts and feelings flow through and pass you without holding on to them is about the best tool I've found for seeing what's actually happening around me and not reacting in the heat of the moment. Shobo Genzo, the compilation of writings by Dogen, the founder of Soto Zen, is a fascinating, challenging, and useful collection, even if you, like me, aren't actually Buddhist. I'm an atheist from an agnostic family, so it's not my intention to prescribe faith to you, except to say that this kind of mission-driven, emotional labor certainly has a spiritual dimension, and I've personally gotten a lot of value out of the analytical and metaphysical tools Zen has to offer. And that kind of leads naturally into my next slide. Pretty much from the moment I wake up in the morning to sometime in the evening when I force myself to turn it off and processing. From dealing with issues in people on Twitter coming at me and the team with pointed questions to trying to make sure, really sure, that how the team is spending their time is the best thing we could be doing right now, to figuring out how to work with my fellow managers to try and keep the shift that is NPM pointed in the right direction to working with my fellow community managers to figure out how to keep ourselves positioned in the larger NPM community to figuring out how to make the node community a more inclusive and welcoming space, which is a task that most of the time it feels like we are signally failing to do in any meaningful way. I'm doing emotional labor all the time. I don't know about you, but I need someone to help me sort through my feelings and to help me handle the load of taking on so much of other people's emotional labor. Counselors, therapists, priests and pastors, these are people whose role it is to listen and to help you put down that load. So far, I've been leaning on my girlfriend and friends to help me sort through this and that's great, but if I'm being really honest, it's a lot of emotional support work to lay on them and since I have the resources available to hire the help, I really should be doing that. So here's the awkward place where I say that after all that, I still don't have any solid answers for you all. I don't even know how my own story ends. I don't know if I'm gonna be working at NPM at the end of the year or if I'm just gonna have pieced out at some point. So far, I've had the good fortune to have a very supportive community and worked hard to take care of everyone involved in NPM, including myself. I don't think I'm a better person than someone like Jacob Kaplan-Moss who went as far as he could with Django and then bowed out with grace when he couldn't go any further. I don't think the JavaScript community is better or worse than the Django community, so I have to conclude that I've been privileged and lucky. This means that I don't really have the standing to tell you how to run your projects or live your lives. I hope that this has been useful for you anyway and this helps you find the support you need to succeed with your own projects. Remember that everything starts with you taking care of yourself and prioritizing what makes you feel safe and happy. Speaking from experience, it's so easy to forget. Thank you for your time and thanks to the organizers and volunteers of OS Feels for having me and for creating this space for all of us to talk about open source and feelings. See you next time.