What We Owe to Each Other

Hi, JS Nation. My name is Brian Hughes and I'm a staff front end engineer at Patreon. I've been a part of the open source community for about a decade now, which is kind of wild to think about. You know, I've seen this community grow so much during that time.

And you know, I've been fortunate that I've been able to play a variety of roles within the community. You know, I've started my own smaller open source projects. I used to be pretty involved in the Node.js project. I've also been working as developer relations in the community. I presented at lots of conferences, and, you know, I've used open source in my day-to-day work a lot.

And like over this time, I've thought a lot about like what it takes to build a good community and how we can help this community thrive because we really are independent at the end of the day. So I want to spend this talk talking about exactly that. How do we help grow this community? How do we help each other out? Basically, you know, what do we owe to each other?

So this talk is inspired by this book of the same title by T. M. Scanlon. Scanlon's a moral philosophy professor, wrote this book about 25 years ago. I don't expect many of you have actually read this book. Admittedly, I'm only about a third of the way through this book myself, but a lot of you have seen this show, The Good Place. So it turns out The Good Place is actually inspired by T. M. Scanlons book and it kind of has that philosophy at the core of the show and the show. I love the show so much because it's all about growing and becoming better than we were yesterday and how we come together, support each other. And it's, you know, through all of these characters growing closer together that they end up, you know, succeeding with all of their wild adventures they go on. And it's just all about community. You know, that's what they do is they form their own small community. And you know what? We're a community, too. It may not always necessarily seem like that, but we really are. Even if we're just using open source, we're still taking part in this community. And, of course, for all of you listening right now, this is a conference for us to come together as a community. And I think this is so important. And it's led me to ruminate on this question of what does it mean to be a good community an upstanding citizen in the JavaScript community.

This is a complicated question. And there's no one-size-fits-all answer to it. A lot of it depends on what kind of role you have within the community. And we could spend all day talking about there's so many different kinds of roles people can play. But we only have so much time together, so I'm going to focus on three in specific. I'm going to focus on the role of companies, focus on the role of developer relations, and on that of project maintainers themselves.

Let's start by talking about companies and the role they have to play in the JavaScript community. Because really these days, companies stand on the shoulders of open source giants. Every single web app I can think of that's out there today I'm sure has open source at the heart of it. How many web apps that companies have created are getting out there, getting customers and all of that, how many of those products are based on top of Node.js in the or Python or some of the other open source server runtimes? How many apps are written using React? How many are written using Webpack to build? How many use TypeScript? VS Code? All of these are open source. Some of these were created by companies, yes, but not all of them. But they're all open source regardless. And so, you know, the fact that we can build code so much faster, we can build more complicated apps faster than we used to be able to, even if it still feels like it's, you know, pulling teeth at times, there's so many options. We have improved so much because of open source. And companies benefit from this. And so, you know, I think it's really important for companies to give back. And the main way that companies can do this is supporting with time and money. And, you know, I know this sounds like, you know, companies should be altruistic, but it's not really the case. There's a symbiosis between companies and the open source community. And companies supporting open source ultimately helps them, too.

As a good example, I used to work at a startup called Observable. And we based our code editor on the open source project CodeMirror, which is a great project, by the way. Just a lot of great work from Ren, the lead maintainer, and everyone else who worked on it. And because we were using this as such a core part of our product, Observable actually ended up sponsoring the project. You know, donating money to it specifically so that, you know, all of the maintainers on the project could focus on it full-time. And by doing so, the project grew faster, it became more reliable, bug fixes, all of that that ended up helping us in return. We didn't have to hire someone to do it ourselves because we could, like, you know, enable the project to do it for us. It was a great symbiotic relationship between the two. I think all companies, at least if there's, like, open source was a really core part of what you do, if there's especially one or two projects that are at the heart of what you do, you know, think about how you can contribute. With the Node.js project, for example, companies can become members of the OpenJS Foundation, which oversees the project.

That's a great way to give back. But it's not just money. Money is important, but time is, too. You know, what I would love to see more of, this isn't very common, but what I would love to see more of is when companies give developers, you know, 5%, 10% out of the week to contribute back to open source projects that that company uses. This is another way to, you know, further enrich that symbiotic relationship between the two. Because, you know, whenever companies are giving back to open source projects, it helps, you know, the projects themselves have a better understanding of how products, or their projects are being used inside of products. But also the other way around is it helps companies to better understand the open source world and those open source projects. And being able to better plan around like how things move, how quickly or slowly things get released, fixed, and updated.

But, you know, a lot of us don't actually sit in a position of power such that we can make these decisions, you know. Where I see is oftentimes, you know, this is a little above our pay grade. But there's still a role for us, too. And that's that devs should report bugs. Whenever we encounter bugs in open source, which we all do, I have certainly found some. We should make sure that we're filing bugs for those projects, that we're letting them know, hey, we ran into this issue. But when we do so, we should do so with kindness. You know, I've also, like I said, I've been involved in open source. So, I've been on the other side of this. And unfortunately, one thing I noticed is that a lot of folks filing bugs feel kind of entitled, in a way, to immediate support. And I get where that comes from. Whenever we run into these bugs, you know, we're frustrated by it. And understandably so. These bugs are the things that's getting in the way of us, you know, shipping the features that we need to ship, especially when we're on a deadline. But we've got to make sure we aren't taking that out on the open source maintainers themselves. And unfortunately, I see that happen all too often. So, when we're reporting bugs, we need to remember that a lot of times these folks, they're doing it in their spare time. And even if they're doing it as part of their job, their actual paid job, it's still usually only part time. And, you know, these projects are typically under-resourced. So, we need to remember that and just be kind.

So, moving on. And now, I want to talk about developer relations. Now, you may not have heard of this before. This is a newer field. It's definitely much smaller. And it goes by a lot of names, too. It's also called developer evangelism, developer advocacy, technical evangelism. And, you know, these are just the titles I've had when I was working that job. There's even more of them out there. But it's a really important part in a big part of the community these days.

So, what DevRel does, which we call it DevRel for short, developer relations, is it connects companies and the community to each other. The idea is that when someone is working as a developer advocate, we're going out into the community. And this is attending conferences and giving talks, it's running workshops, it's all of these things to help the community learn more about the products that the company is offering. And usually, DevRel folks are attached to a specific product or a couple of products in the IOS area of expertise. And it's also what they're trying to get folks in the community to use. There's a bit of a sales aspect to it. I don't think that's actually a bad thing, though. I think sales oftentimes gets a bad rap. Who thought I'd be standing up for sales in this talk today? But that's only one part of what DevRel does.

So DevRel also takes feedback from the community back to the company. And so there's this two-way street between the community and the companies that DevRel facilitates. Well, at least in theory. Unfortunately, what I've seen in practice is not that. It's really hard to be DevRel and to really balance things such that the work that DevRel does helps both the company and the community. And there's a lot of pressure on DevRels and also a lot of incentives that aren't great. But this is where, as a DevRel, this is where we do have some influence. And this is where we have to make sure, when you're a DevRel out there, that you're being a good community member. And the first and most important thing to do is to be honest and transparent about what you're doing. So, if you're giving a talk at a conference, running a workshop, anything like that, be open and honest. Say, I'm a DevRel at this company.

I'm supporting these products, and I'm here to talk to you about them today. This doesn't have to be a bad thing, but we have to be open, honest, and transparent about the work that DevRel is doing. And specifically, as part of that, is don't be exploitative.

And in a way, I can't believe I even have to say this, but in my experience, it has to be said. It's very easy in the position of DevRel, at least from a company incentive perspective, to try to go for the short-term gains for the company, and this often comes at the expense of the community. Back when I was working at DevRel at a certain company that I shall rename nameless, they tried to institute this program where they were looking at who were the biggest detractors of the products that we were working for that were out there in the community and had some amount of followers, notoriety, whatever it is. And then they looked to say, which one of us as DevRel were actually friends with these folks, and they wanted us to go leverage our friendship in order to get them to change their mind. And we weren't allowed to tell them we were doing that. And we were even supposed to track private conversations in all of this stuff without the knowledge or consent of the people involved. Of course, we threw a huge fit about that and we managed to get them to cancel the project, but this kind of stuff happens. And something just for the non-DevRel folks to be aware of is that most DevRel organizations, they are heavily tracking everything that people say online on Twitter, on GitHub and various other open source places. You're running sentiment analysis and things like that. This is all public data, so I suppose we shouldn't be too surprised. Pretty much any org that's at least a little bit salesy is doing this. But, you know, just something for everyone to kind of remember. And there will always be some of it.

As DevRel, it's important that you push back whenever things cross a line. And the last thing that I think is important for DevRel to do is to ensure that this two-way street is actually two-way. A lot of times, you know, it's of course very easy to get out into the community and to talk about what the company wants you to talk about, that that's what they hired you for. And that's, you know, very much— that makes the company happy to do that. But then there's that other piece of taking feedback from the community back to the company. And that's where I often see things falling down. This of course can be like bug reports and like the typical kinds of feedback, right? Hopefully DevRel has good channels for that. But where I see this fall down the most is at a higher level. And this isn't like, oh, this specific feature in this product is a little wonky. It's more of things like, this product you're selling isn't good for the community. It's encouraging bad practices, it's encouraging lock-in or any of these things. I think we all kind of know those products. Those ones that feel a little predatory, let's say. And what I've noticed and what typically happens, unfortunately, is that whenever that feedback is happening from the community to DevRel, DevRel will return it and it just falls in deaf ear.

So as DevRel, it's important that you do whatever you can to make sure that your employer is actually listening to that feedback.

All right, so now on to project maintainers and collaborators of open source projects. And collaborators are an important part of this, but I'm mostly gonna focus on maintainers for this part of the talk. So maintainers make the web happen. Maintainers are so critically important that, you know, this sounds like a grandiose statement, but it is true. You know, without maintainers, we don't have open source. And without open source, we don't have the modern web. Simple as that. And I know this is kind of an obvious thing to say, right? You know, if there's no one to develop open source, there isn't any code. But I feel like we tend to take that for granted a lot. We, being companies, developers working there, we just kind of, open source is so common now. We almost can't imagine a world without it. So we don't think about what's often at stake. And so maintainers are just so, so critically important.

And so from the role of a maintainer, there's a couple of things that I think are really important for maintainers to do to make sure, on our end, that open source projects keep running. The first thing to remember is that open source projects are more than just code. Something I've always liked to say for a long time now is that you can write the best code in the world. It can be performant, it can be scalable, extensible. It can have an incredibly elegant API design. It can have all of those things. It could be the best thing out there. But if it's not documented, might as well not exist. Because the truth is like, documentation matters more than code. Which I know it can be kind of hard to hear. Most of us don't like writing documentation. I certainly don't like it. But it is so important to the success of a project. And you know, we need all kinds of documentation. You need to have those API guides that have, you know, the reference of like all the nitty-gritty of how it works. We also have to have the getting started guides, you know, the tutorials.

You know, we also need, you know, change logs and upgrade guides and things like that. And it's amazing how many open source projects I've come across that don't even have a change log. And so I see there's, you know, a major version upgrade. I have no idea what broke unless I go and read through the commits which sometimes I do, but sometimes I just give up and use another project or something else like that. So it's important that we have that documentation for our projects so that we can bring people into our projects and, you know, get them onboard and using our projects and being happy with them. You know, and at least hopefully, you know, that's the whole reason we even created this stuff as open source to begin with is to share our code with others so that other people will hopefully use it.

And the next thing is to be inclusive because it's really going to help you out if you can be inclusive and welcoming to new folks to your project. And I know this is kind of like a subject that's been talked about a lot. Some people may think too much, but I don't think it's fully really sunk in yet. Like inclusivity is so important, and I do mean inclusivity in the classic sense of like, are we welcoming to folks of different genders, people of different races and things like that? There's other parts that I feel like are even less talked about in open source that are just as important. And for example, how inclusive are we for time zones? For the kind of project where, say, once a week we all hop on a call, which, you know, this is pretty common. Let's say we're a North American centric project. What times are we holding those calls at? Are we making sure that we have times available for folks in Europe such that they're not having to hop on these calls in the middle of the night? Or what about folks in Asia where they have not hop in early, early in the morning? You know, it's important that we think about how can we bring in more people? Because at the end of the day, being more inclusive and welcoming means more people helping us with our projects, right? I've never seen a single project that I'm aware of that has too many developers. Too many developers and not enough work to do. It's always the opposite. There's always so much more work to be done than there are people to do the work. And when we focus on inclusivity in our project, it means we get more people to do the work, right? And that helps our projects out. It helps the projects be more successful.

And the next thing I want to recommend is to embrace change. Like, the best way to run a project changes over time. When we start off with that project, it's usually just us. We're coding on our own laptop. We're committing straight to main and pushing up. You know, we just publish to NPM whenever we feel like it. And that's great in the early days. It allows us to move fast. But as we start to bring on more contributors, that becomes less true. You know, then we have to start thinking of, like, well, what's our pull request process and things like that, you know, making sure that's documented. And then as that continues to grow, then we have to start thinking of, well, how do we delegate decision making? Do we have to start thinking of coming up with something like, you know, the big projects have, which is, you know, usually a technical steering committee, and then a bunch of working groups below that. You know, the way that we approach work and who we bring in to become collaborators and what that process looks like needs to change over time. And if we're not adapting our project as it grows, then that's a pretty good way to make sure that it's going to become unmaintained later because it, you know, collapses under its own weight. You know, sadly, there's some really big projects I've seen that have done this, some that are sometimes even some of the most popular open source projects, you know, in their area.

And so I kind of want to end this talk by refocusing a little bit on like what we owe to ourselves. How do we support ourselves in this process? Because, you know, the unfortunate truth is that right now the incentives in open source software are inhumane. It's bizarre to think of, you know, we spent all this time, you know, contributing and, you know, just to turn out and see our projects being, you know, used by companies who make all this money when, you know, especially for folks who are doing open source full time, you know, can be really struggling just to make ends meet. And you know, again, like I was talking about with filing bug reports, there's a lot of vitriol. There's a lot of angry people. You know, it's kind of those things where, you know, the unfortunate reality of open source is if we do the absolute best job we can, no one will notice. People only notice whenever we make mistakes. And since we're humans, we do make mistakes. And it's hard and brutal. You know, everyone is overworked. So many open source maintainers I know are burned out. Just things are not OK in the open source world. You know, it pains me to say but it's true. Like we really need to work on fixing things. We need to work on supporting this community better. And, you know, and it isn't even just with, you know, open source maintainers who are struggling. It's dev rel too. You know, like I was talking about, it is really hard to be an ethical dev rel these days. Like things need to change. But, like, so what can we do about that? Well, you know, the answer has in a way been around for thousands of years. You know, the classic saying of know thyself. You know, I mentioned so many maintainers and dev rel folks I know are just burned out. You know, they're done. And I think one of the things I've noticed is so many of them don't even really know they're burned out. So I think one of the things that's really important for all of us to learn is to recognize, you know, the signs of burnout or to learn and recognize when we're doing work that isn't sustainable for us or doing work that ultimately doesn't bring us fulfillment. And so it's all about understanding ourselves because only once we understand ourselves can we start to think about how we can contribute better and how we can actually, you know, become more sustainable and more effective and help the community as a whole. You know, sometimes it means we have to rethink how we stay involved. You know, maybe we need to start delegating some work to other folks. Maybe we need to, if we're open source maintainers, really start prioritizing bringing in other maintainers at the expense of doing new features. Sometimes in DevRel, maybe it means we need to change teams or change companies to continue to do it.

But you know, at the same time, sometimes the best thing is just to leave because the truth is I left DevRel several years ago and I'm never going back. I was actually at another conference, one that was really important to me and I had this light bulb moment where I realized there was no possible way for me to do the work at the company I was working for and be an ethical member of the community. I was always having to fight against the two. And so the best thing for me was to leave.

I've mostly left open source as well. I still do some personal projects, but I left an OJS project. I'm not involved in the day-to-day at all. In any form or fashion in that project anymore. I certainly still stay in touch with folks. I love talking to them, but I'm not involved anymore. And that was the right decision for me. That was such an important growth area for me and I'm a lot happier and healthier now because of it. But that sucks. But open source should be a part of our life and not all of it. It's all how do we find that healthy balance? Because if we're burned out, if we're barely hanging on, we're not doing anyone any favors, including our projects. If we're burned out, that makes it so much harder for us as maintainers to be kind and gracious in bug reports. If we're burned out as DevRel, it's that much harder to make sure that we're doing the right thing and pushing back against our employers when we need to be.

But for all of this negativity, I'm ultimately still hopeful. I am starting to see signs of this changing. I'm seeing burnout being talked a lot more with open source maintainers. I'm starting to see more talk about with DevRel and how do we do that ethically? And the reason I am seeing this happen is because we're talking more with each other. You know, we're starting to support each other more and help each other out, and I think that's the way out. So I want to end with a quote from the good place again by Thierry Hennigan, who said, why should we choose to be good? It's because of our bonds with other people and our innate desire to treat them with dignity. Simply put, we are not in this alone. I think that's the key. When we remember that we are a community together, if we can help each other out, that is how we get our community into a better and happier and healthier place overall. And it helping everyone out, you know, including companies.