Sustaining Open Source - Nicholas Zakas (ESLint)

On today's episode, Sarah Dayan discusses open source sustainability with Nicholas Zakas, creator of ESLint. ESLint is a widely popular JavaScript linter with a giant ecosystem of third-party plugins. If you have a JavaScript project with a continuous integration, you are certainly using ESLint and you do not want it to fail. Nicholas is also a seasoned author who wrote several books about JavaScript since the early 2000s and more blog posts that you can probably afford to read.

A recurring meme is that all modern digital infrastructure somehow depends on a project that some random person has been thanklessly maintaining for decades. Sustaining open source projects that support countless enterprise products has been a particularly hot topic in tech for the last couple of years.

- How do you actively maintain a project that others rely on but doesn’t bring revenue?
- How do you deal with stress and fatigue?
- Is the promise of open source still holding?

• Nicholas Zakas: @slicknet / humanwhocodes.com
• Sarah Dayan: @frontstuff_io / sarahdayan.dev
• ESLint: @geteslint / eslint.org
• Algolia: @algolia / algolia.com

Transcript

Nicholas Zakas: 0:00

If I'm trying to engage with you on an issue. And every response to me is rude, sarcastic, disrespectful. I have no problem. Just closing the issue and saying, I'm sorry, I'm not gonna be able to continue on with this issue in this way. I have already tried my best to be respectful and replying. You are not responding the same way. So I'm going to move on to other things now and just leave it at that. Maintainers are not under any obligation to continue a conversation that is negatively affecting their mental health that is draining the, um, uh, you're not being paid to deal with that. There's no reason to put up with it.

Sarah Dayan: 0:49

Hi everyone. And welcome to developer experience a podcast by Algolia. We chat with guests who build products for developers about their developer experience strategy, what it means for them, why it's. And so on, on today's episode, we are going to talk about sustaining open source projects. So there's a recurring meme that you will see if you spend some time on tech, Twitter, and it's that all modern digital infrastructure somehow depends on a project that some random person has been thankly maintaining for day in Nebraska. And this has been a particularly hot topic in tech for the last couple of years. How do you actively maintain a project that others rely on, but don't bring revenue. How do you deal with stress? How do you deal with fatigue and is the promise of up, and so are still holding that you will learn that you will grow and meet other people. Is that still holding? So to talk about this today, we have Nicholas Zais. Nicholas is the creator and maintainer of lint, a widely popular JavaScript linter with a giant ecosystem of third parts he plugins. So if you have a JavaScript project with a continuous integration, you are certainly using it and you do not want it to fail. Nicholas is also a seasoned author who wrote several books about JavaScript since the early two thousands and more block post than you can probably afford to read. Nicholas. I'm delighted to have you welcome on this show.

Nicholas Zakas: 2:27

Thanks for having me.

Sarah Dayan: 2:29

So let's get started right away. Slint has become a staple of the JavaScript ecosystem. There is no question about that. Most JavaScript projects use it. We all run lint in our CI. We all rerun our CI because we forgot to lend something and we forgot to make it automatic on our machines. And because it's highly extensible, you even have other projects that are in the same domain, like pretier for example, that can be run in Esly. So they kind of enter the ecosystem while being different projects. How do you handle becoming a pillar of an ecosystem? And what does this concretely means in terms of load time, investment and responsibilities?

Nicholas Zakas: 3:17

Well, I think the, at the most important thing for not just me or any of our maintainers on the ES Lin team is to have a lot of respect for the developers and their time. And that really causes us to think long and hard about what changes we we make. And when, because we know that esent is embedded in a lot of companies, CI systems, that means if we introduce a change that breaks some existing behavior, we could be wasting dozens or hundreds of developers time for several while we seek to fix that. So we spend a lot of time thinking about how are we going to impact somebody's life if they upgrade to this tomorrow? And as a result, I think that we're a little less risk averse than some other projects in the similar domain, because for other projects, if something breaks, it's almost always because of something that they did. But if we update a rule that all of a sudden is flagging something as a warning that wasn't previously flagged like that that's something that can block a lot of developers from doing their job. So it's a responsibility we take really seriously. And we do put an extra amount of thought into all of the changes that go in so that we're not disrupting the ecosystem at any random point in time.

Sarah Dayan: 4:53

So what's really interesting in what you just shared is that there is a strong mindset. Like it does look like it's starts from values and a mindset, and I'm really interested in how you build something like that, how you build such a mindset and like, you know, the size of lint could be thought of as, oh yeah. When you contribute to something as big as lint, obviously you're gonna be careful, but at the same time, I'm not so sure, like there are many reasons why people contribute to open source. Not everybody is necessarily as passionate about it or wants to apply the same level of professionalism that they would in a job where they get paid for it. So I'm wondering how do you create that culture? Where does stem from?

Nicholas Zakas: 5:43

I think if I were to trace it back, I would go back to the first year of ES L's existence, where there were just a small number of people who were using it, but they were really passionate about it. And I was still managing it as just a hobby project. And at one point I made a commit directly to the main branch and it was something that broke a previous behavior. E even though it was fixing a bug and I thought, you know, I was doing the right. And so I released it. And one of the contributors sent me a message and just said, Hey, you know, you changed this. I didn't know it was coming. It broke my workflow. You really shouldn't be committing to the main branch directly. You should be sending a poll request so that people book can be made aware of what changes are coming in. And that was the first time anybody had really mentioned anything like that to me, that they were relying on the project. And I couldn't just sneak in stealthy changes whenever I wanted, because it was something that I thought was right for the project, because that's a really fast way to alienate users. And that was really the beginning of the thought process on the project of, okay, this is a tool that people are starting to rely on. We can't just make changes whenever we want, even though I'm the author and the sole maintainer at that point in time, I can't just be committing directly to the main branch without letting people know what's landing and allowing them to voice their concerns before it gets released. And we've just continued to build on that theory over time, where if you go on our readme, we have our published semantic versioning policy. And that was developed over years as a team, as we figured out the mistakes that we made, like, okay, we made this change, even though it seemed right. It caused everybody CI system to break. So what's more important here. Well, it's much more important to us that people CI systems continue to work. And that if for some reason they're not going to work, then that is most likely going to be a major version release for esent so that they know ahead of time that it's coming. And it's a way that we think about maintaining the project that some folks can find strict. Like we get all kinds of issues and poll requests of people asking us to make changes. And a lot of times we just say no, because the change would be too disruptive to the eco a system, even though for some set of developers, it might be beneficial. So it's, it's definitely a different balancing point. And to your point, there are a lot of people that come to the project and just think, Hey, cool. I wanna add something to ES Lin. I think it'll be great. And they don't fully think through how it will affect all of the existing users. And, you know, that's where having a strong team of maintainers really is important to just hold that line and protect the end users.

Sarah Dayan: 9:16

So how do you create such a team? Like I work on open source, but, uh, it's part of my job. And so I'm in a team and we are, it's all our jobs, right? We are all working for a company and we get to do open source, but then you see some projects that have like a single maintainer and many people rely on it, but you also see projects like esent, or VJs comes to mind with really strong, close knit communities and teams of maintainers that seem to really be, to really agree on the mission to really agree on where they're going. Lal communities also comes to mind. How do you create that? How do you make that happen?

Nicholas Zakas: 9:59

Well, I think that it starts with having a maintainer who has an idea about what they want the values to be. And then I think it really is just a matter of repeating those, you know, in the issues in the poll request. So people become aware and then it, the contributors that you have that accept that that's how the project works. Those are the people that you want to really draw in and get them to be more active in the community because you, as a single maintainer or even just two maintainers, it can be really hard to just police every issue, every poll request that comes in, especially if it's a large and popular project. So you need to start building the community around the project by rewarding the people who are upholding the values that you've set up. And that's something that, uh, once I decided I didn't want to be a sole maintainer anymore. That was something that I put a lot of thought into was just how do I start rewarding the people who are behaving the way that I want them to behave, and that is beneficial to the community. And that's when I started experimenting with creating a core team, eventually the technical steering committee. And then as I saw people that were contributing meaningfully to the project, inviting them to join and become part of the leadership of the, and I think through that, we've been able to sustain the values that the project believes in by making sure that we're looking out for new contributors, who are participating in a beneficial way and who seem to really buy into the structure that we've set up to hopefully get them more and more engaged and eventually bring them onto the team as a regular maintainer. I don't see a way of really sustaining a project as a single maintainer for very long, especially if a project ends up becoming popular.

Sarah Dayan: 12:17

Do you believe that at some point you also need to, like, as you create a team, do you need to give other maintainers a little bit of leeway? Like you've been working on that thing for so long and you have a strong vision and maybe you consider it as your baby, but does, at some point, do you also need to accept that people will invest better and more if they can bring a little bit of themselves and their ideas?

Nicholas Zakas: 12:44

Yeah, absolutely. One of the things that was really hard for me initially, was giving up S some of that power and not being the sole decision maker anymore. But on the other side of that, we were able to build a really awesome team by doing that. And by letting people voice their opinions on where the project should go and what should happen in when certain types of submissions come in, you know, our semantic versioning policy started from somebody other than me who was on the team, who said, you know, we keep running into these issues. Maybe it's time for us to document it well, great. That's a great idea. And then we all continue to build on afterwards. And there were certain decisions that were taken on the team that I personally didn't agree with, but the larger team decided that it was the right way to go. And so I decided to accept that and continue on, on, because at, at this point in ES Lin's history, there are large parts of the code base that I'm not familiar with because the project has grown so big. And at a certain point, I realized that, and I had to realize that there were team members who are more familiar with certain parts of the code than I was, and that it would be a good idea to really rely on their expertise, to decide how that part of the code should grow and develop. And I think that the project and the team as a whole has been better, the more that we've been able to incorporate other people who have other ideas and other strengths than I do, because there are some things that I don't know that well and somebody else does. So right now, we're going through and trying to start adding, uh, type definitions to the various repositories. And I have very little experience with that, but we have a couple of team members who are very experienced with type script. And so being able to lean on them and let them lead those endeavors have, has really made us go a lot farther, faster than if I tried to stay deeply involved with those projects.

Sarah Dayan: 15:18

I think you're making an excellent point on the fact that, yeah, it's, it's the whole thing of you'll go faster if you are alone, but you'll go farther. If you're a team. And personally, like after looking at many open source projects, many projects, but also many open source projects, there is no recipe for success and whatever that means for you, but where I've seen the most traction and the most happiness is in the projects where of course you have to have a, like a good idea that solves something from the ground up, but is the projects where the maintainer opened the project to other contributors early, because ultimately it's the same thing in a company. People don't want to just, you know, dust up the parts of the projects that you don't want to touch. They want to have an impact. They want to make something that they believe in. They want to get something out of it, whatever it is, whether it is just, you know, learning something new or having something to put on the resume, whatever it is, they want to have an impact. And I've seen project Lin is one, but also I'm thinking of, uh, former Algolia employee. Uh, no Noma is working at laal and he is, is a big open source contributor in the PHP community. Most of his projects, if not all, are really successful, partly because he opens them to external contributors really early. Usually when the prototype is out, he opens it. And then in many cases, even just gives them out to other people to, to be the core container. And I think that's, uh, it can be difficult, especially when you care about something, when you spend a lot of time of thinking, you want to keep that prop pretty, but you will likely, never go as far as fast, if you're trying to do it all yourself. And if you are basically just asking people to do what you ask them to do, people are not contractors. People want to be part of something. They wanna be part of a team.

Nicholas Zakas: 17:37

Yeah. I think that that's one of the interesting struggles of open source projects is know, I, in my mind have some places where I'd like ES LT to go, but if I don't have the time to do it, is that something someone else wants to do or not? And one of the things that we've generally stuck with over the years with ES LT is it's going to be a lot easier to attract contributors if we allow them to work on, what's interesting to them, even if that isn't something that's on the official roadmap. And it's interesting to see where people go when you give them that type of free freedom, because we can say, you know, these are the high level priorities that the TSC has set for the next year. And these are the things that we would like to accomplish if anybody would like to help with those great. But if other people have other ideas and more importantly, if they're willing to work on them, then a lot of times, especially if it's not gonna be a breaking change, we're more than willing to let people propose that change through the RFC process and then go forth and implement them on their own and we'll help out as they need it. And we've had some really interesting features come out of that process that we wouldn't have otherwise thought of or prioritized for the TSC to work on, but because somebody came along and they had an idea and they were willing to work on it, then we were willing to consider it. And then where it ended up. And I think for an open source project to be sustainable over the course of years and not just months, you really do need to be open to those contributors coming in with their ideas that maybe are not something that you would think of or would prioritize on your own. But if you have somebody who is willing to put in the work to build it and document it, you can get some really amazing contributions that way.

Sarah Dayan: 20:04

Yes. And the show is about developer experience. And, and in that case in open source, there are many developers that you're catering to the developers on your team, the maintainers, what is the experience that you are giving them? And ultimately, it's also about being honest with where you want to take a project. It's okay for a project to stay a pet project, to be something that you want to maintain. That's fine. And people will want to rely on it, but you can be upfront about the fact that something is not meant to be used in production. That it's just a toy project for you to learn. But yes, if you want to really take something somewhere, you will likely not do it on your own. There are very, very few projects that really took off being maintained by a single person. If they are the exception, they should probably not be a model. Anyway. So speaking of developer experience, there's one thing that when you shop for a, a new dependency, a depend you, something that you need, one of the things that you are look into is, is this repository maintain. That can mean a lot of things that can mean. When was the last comment? What is the number of open issues? Open PRS basically? Is there any activity, is there any traction? And when I'm looking at the main ESL in repository, I'm not talking about the plugins, of course, because they're, most of them are third party, but looking at the main repository, it has an incredibly low number of open issue and poor requests relative to the size and the impact of the project. This is really impressive. What are the bottlenecks that you identified over time and what systems did you put in place to manage the day to day upkeep,

Nicholas Zakas: 21:53

Keeping the issue and pull requests count low is a priority for the team, because we found early on that the more issues in pull requests that were the harder it was to maintain the project needing to go back and forth between hundreds or I think at one point we actually had over a thousand open issues was really stressful for the team. Uh, cuz you know, every issue, every poll request you have to, to kind of load back into your memory, the entire context of what was going on in that issue and swapping between all those issues was really difficult. And it seemed like we were just facing and never ending on lot of things that needed addressing and people, you know, leaving comments, Hey, there's been no update on this in two weeks, so would need to be circling back. Uh, and eventually we just decided that, that we couldn't possibly keep up that way. Uh, so we've experimented with a bunch of different systems for managing that. Uh, at one point we added in a stale bot, uh, that would just automatically close issues that were older than I think it was 90 days. Um, because we had found looking at our issue history that once an issue was accepted, which means that the team agreed that we were going to address it, that 90% of those issues were closed with a poll request within 90 days. And if an issue was open for longer than 90 days, the chances that it was ever going to be resolved were just incredibly small. And, and this was all driven from actual data. We pulled all of our GitHub issues from the beginning of the project and crunched all the numbers on it. So with the stale bot, we just said, okay, any issue that is not resolved within 90 days is likely to never be resolved. So we'll just close those. Uh, and that was our first attempt and that really helped a lot. And yes, some people got upset that their issues were being closed automatically, but fundamentally the data on how we were running the project backed up that decision and we left as nice a message as possible, uh, about why we were closing it and invited people to open new issues. If they really felt strongly that, um, the issues should be addressed since then we moved on and just identified some issues and poll requests that we didn't really need the team to triage. And we knew they could just be closed automatically. Uh, so we got very strict about what type of changes we would be making to core rules because at this point we have almost 300 core rules and so we can't just continue adding more rules. It gets really difficult to maintain when I first started the project, I never envisioned ES L having more than about 50 core rules. And so at some point we realized that we just couldn't be, uh, as loose with accepting new rules into the core. So that helped us just start to close proposals for new rules, a lot faster. Uh, we have a bunch of rules that just enforce style preferences and we decided we were not gonna add any more options to those rules because you can keep adding options for style preferences until the end of time, there are just too many ways that people like to tweak their style preferences and we can't keep adding new options. So that everybody's one-off exception is supported with those two restrictions. We're able to just very quickly start closing some of the issues that we're proposing, either new rules or changes to those stylistic rules that we are not gonna be implementing. So that has helped a lot. And then for poll requests, we do prioritize reviewing poll requests over, uh, reviewing issues because if somebody's taken the time to submit some code or some documentation, um, we want to try to get them an answer as quickly as possible. And sometimes that answer is this. Isn't something that we're gonna merge, uh, either because of the rule restrictions or because it's something that needs to first go through the RFC process. So we're able to get people or response fairly quickly. Uh, and then we do still have a stale issue and stale pull request bot that runs after 90 days. But in reality, we don't end up with a lot of automatically closed issues and pull requests at this point because of, of all of the strict triaging that we do upfront

Sarah Dayan: 27:47

Does the triage involve bugs as well, because you mentioned people who want new rules and that your vision and that you have a strong vision is helping a lot deciding whether this is a good idea or not, but issues are another topic when you have bugs in Lenton. I imagine that even after many, many years of solidifying the core and adding many, many tests, you still have issues and bugs every now. And then do you have any kind of prioritization when it comes to the types of bugs? I would say the type of gab issues that you tackle first, do you have systems to make sure that a bug ticket is legit? Do you require that issues are filed in a certain way? Otherwise you close it. Do you have any systems when it comes to reproduction of alleged bugs?

Nicholas Zakas: 28:42

Yes. So we do try to prioritize bugs and bug fixes, cuz those generally tend to be smaller and easier to merge into a release without affecting people. We do have a GitHub issue template for our bugs. So we do force people to provide a certain amount of, of information. We generally try not to close issues, even if they don't have enough information off the bat. Well instead just say, Hey, you haven't really given us enough information. Can you please go back and fill in all the information on the template? And then we can take another look and sometimes people will go back and fill in the information, a surprising percentage of the time. People just never follow up after that. And then if we haven't heard back in about a week, we'll just close that issue and consider that it was not reproducible. Otherwise we do go through the process of making sure that somebody can reproduce the issue. We do ask for a minimal reproduction case, uh, in the issue template. Sometimes we get that sometimes we don't, if it's easy enough to reproduce, like we do have the online demo for Slint. That is a really quick and easy way to try to reproduce basic issues. Any of the issues having to do with rules or parsing, you can usually reproduce using the online demo and that way we can quickly reproduce issues. Even sometimes if I'm on my phone, I can just copy paste that into the demo and verify if it's a legitimate bug or not. Otherwise we'll ask people to set up a minimal repo, especially if it is a potential issue that has to do with plugins because the ecosystem is so vast. We do get a lot of bug of reports that are actually not related to esent itself, but are related to a plugin or a parser or a custom rule. And those can be a little bit trickier to figure out, especially if they're just using a custom parser, because we want the core rules to work with as an, any custom parsers as possible. And we do go out of our way to make sure that the core rules will work with type script. For example, uh, even though Esly core doesn't support type script, we've found that in a lot of cases, just some simple changes to the rules will allow type script code to work, even though it won't be considering the type definitions as part of the rule itself. So in those cases, we might need a minimal like repo to be set up so we can debug it. Or sometimes we'll ping a plugin owner or parser maintainer to just comment on the issue to let us know if it's something that they think might be a core issue, or if it has more to do with the plugin or the parser

Sarah Dayan: 31:54

Earlier, you mentioned that at some point, you'll also have to learn how to say, just know to contributions or issues that don't don't match the vision don't match, what you're trying to achieve and something I've I've noticed when, you know, reading conversations around fatigue in open sources, that one of the things that maintainers get tired with is support questions in issues. You know, you will have people who encounter an issue and that's actually documented. That's a behavior that is documented. There is also sometimes rudeness in issues when people are really passionate and you can see that on very heart repositories. If you look at the react repository, you have some flame wars over there and I'm curious, what's your take on that? Is that something that we have to not accept the rudeness, but accept that it'll happen? And when it systems, is it something that you're still trying to figure out? How do you handle all that kind of stress?

Nicholas Zakas: 33:01

I think to a certain extent, you need to expect some level of rudeness. You need to expect some level of laziness as well. When it comes to people, opening issues where they could have just searched the dock implementation and found the answer there as well. Um, it it's something I think that is always going to be a part of open source, especially on GitHub, where they make it basically zero cost to open an issue, uh, which is something that I have struggled with over the years on GitHub. I think that the zero cost issue opening is a problem to where the person opening the issue. It costs them very little to do so, but the person triaging the issue that costs, there's usually a fixed cost for every issue that is higher than the cost of opening the issue. And that imbalance is part of maintainer burnout, at least in my opinion, and until GitHub helps us by raising the cost of opening in a issue a little bit, which issue templates help, but are still not quite there. It's going to be up to maintainers to help maintain their own sanity. And I have a zero tolerance policy for bad behavior on issues. If I'm trying to engage with you on an issue. And every response to me is rude, sarcastic, disrespectful. I have no problem. Just closing the issue and saying, I'm sorry, I'm not gonna be able to continue on with this issue in this way. I have already tried my best to be respectful and lying. You are not responding the same way. So I'm going to move on to other things now and just leave it at that. Maintainers are not under any obligation to continue a conversation that is negatively affecting their mental health that is draining them. Uh, you're not being paid to deal with that. There's no reason to put up with it and I'm very quick to close issues. If I see the discussion isn't going anywhere and I do that without any regret. Uh, and generally what I'll do is say something along the lines of thanks for the discussion at this point. I don't think we're going to be moving forward with this. So I'm closing the issue and then I close it. And I unsubscribe from all notifications that are on that issue. And I'm done if people want to go back and complain that the issue is closed, that, but that's not something I'm going to engage with going forward. I would much rather spend my time on the issues and pull requests where people are being respectful and considerate and are making meaningful contributions to the project as a whole. And that way I'm able to keep myself refreshed, interested, and just cut off any of the more toxic interactions that I'm having.

Sarah Dayan: 36:24

Yeah. I think this is really full of extremely good advice, especially for maybe younger folks who are starting out their open source journey and trying to gain knowledge and experience through open source. There are so many great things that you can learn from open source because the barrier to entry is very low. You can get started right away. You can open up a request right away. There are many, many things to learn, but maybe one of the biggest is that you are entitled to own sanity. You are entitled to being respected. And even when you get paid for it, like you're a support engineer support agent, you are not supposed to get abuse from clients. There is no reason on earth, why you would have to accept it. And then of course it depends on the communities and it depends on the kind of atmosphere that is created, but in no way, this is justifiable that people will talk to you badly. Even if you broke their build, like you can understand sometimes that people get frustrated, but there is a limit to the kind of behavior that you can intake. And yeah, no matter whether you broke something at the end of the day, it is only software. We are not putting anybody's lives in danger. Yeah. I feel that it's extremely important for folks to understand is that this kind of behavior can only continue if we let it happen. And it's not enough that we say no to it, but it'll only fester if we let it happen.

Nicholas Zakas: 38:05

Yeah. There's still a lot of bad behavior out there. But I think that part of keeping your sanity is just limiting how frequently you engage with it. I have a bunch of canned reply I saved in GitHub. So for any type of issue that is stressing me out, I have a way out that I thought about when I was calmer and not stressed out that I can just put in, like, you know, if somebody has opened an issue for something that is documented, then I have an auto reply to say, Hey, thanks, sorry, you're having a problem. Here's where you can find the answer and just paste in the link and then close the issue. Like I, I think the other thing leads to burnout for open source maintainers is not every issue or pull request, deserves weeks of conversation. And that's something that burned me out very early on where I thought like, wow, you know, anytime and brings me an idea. I need to fully vet it. I need to ask questions to make sure that I understand where they're coming from. I, I need to respond to all of the criticisms that they have about my response to it. And now my approach is every issue deserves that level of scrutiny. Not every poll request deserves that level of scrutiny. It's completely fine that if an issue comes in and you know that you are not gonna take any action related to it that day, that you just close the issue and say, uh, I'm sorry, we're not gonna be moving for, with this. Thanks for the idea. And then just be done with it. And yes, people will come back and complain and feel like that their issue hadn't gotten their day in court, but their issue didn't deserve a day in court. So you don't have to give it. And, and that, that's why I'm very strict with myself. If I close an issue that I have no intention of following up on again, then I also unsubscribe from the notifications because the extra amount of time it's going to take me to read through somebody's complaint about my having closed. The issue is not worth the time or the stress that it's gonna cause me. I have other things that are more important to the project to work on, and I need to give myself permission and all maintainers need to give themselves permission to just move on from an issue. And don't engage with any of the complaints that come in after it closed.

Sarah Dayan: 40:59

It makes a lot of sense, especially after you mentioned like the amount of quality that you expect and, uh, like the fact that one of your biggest values is that you do not want to add something lightly. If it may cause breakage that you have a steer in committee, like all those things contribute to quality. They are not easy things to put in place. They take time, they take resource. And it is, I believe that, uh, people in open source, especially when they put such care in their work are also entitled to expect a certain level of care coming from the people who are users, because ultimately we have that messaging that comes from the corporate world where you need to be customer obsessed and customer centric on all that open source. And of course it may be a bit different if you use open source in the frame of a company, but open source, you have users, they're not customers, and you can apply really high quality standards. You can see that with, uh, Linux, for example, huge, extremely strict quality standards and Lin external. But at the same time, the people using your software are not paying you for it. You are doing that on your own time, and that's not here to justify that. Oh yeah, we don't care about people. Complaints. It's just that the relationship is not the same. There is no contract kind of a moral contract, but there is no contract that you do this because I pay you. Uh, and so it's also a learning experience for the user when you are using open source. And maybe that's also where a lot of the misconceptions come from you are participating in open source. It's not just a shop of free software. You're using community may maintain software. It's very different from free. Just grab it, like you become a part of it. And so there also are expectations on people who consume, especially when a project has really high quality standards.

Nicholas Zakas: 43:10

Yeah, absolutely. I mean, it, it really is a two two-way relationship, more than anything else. It's, uh, as a user, when you go to the GitHub repo, you are entering into a relationship with the project that is two-way, you use the project, but also you can contribute and, you know, contributions, aren't just code. Every time you open an issue, you are contributing every time you open a discussion or a poll request, you are contributing. And anytime you participate in the project's chat room or discord server, you are contributing. And that's why it's important to establish a code of conduct upfront early on in the project's lifecycle so that you can set the expectations for what the behavior of the community is. I mean, for every issue that is opened on ES LT, we say right at the top, in the template that by opening this issue, you agree to adhere to the code of conduct. Like that is part of the agreement that you make when you make a contribution to the project. And the earlier that you get that laid out, I think the better off your project is going to be. And part of that is not just what we consider enforcing a code of conduct, which is if somebody does something bad, you let them know that they're in violation and either warn them or punish them in some way. Now that's one side of it. But the other side is you really need to reward the people who are behaving in the way that you want the community to behave. And whether that is by inviting them to join the team, you know, on Slint we actually have three different levels of team members. So committers reviewers and the technical steering committee, and as people contribute more, they can progress up that ladder until they become a part of the steering committee. But also what we've started doing is paying contributors when they make of contributions. And we particularly are looking at not just code contributions, but how people behave on the issues, how people behave in discord. If people are submitting documentation, if people are just generally helping out in the ecosystem, once a month, we as a team get together and we award people some amount of money for any contribution that was beneficial to the project. And in that way, we have been able to really encourage the type of contributions that we want, because even though the dollar amount isn't a lot, so it starts at a hundred dollars. I think we've done as much as 500 for some really outstanding contributions. People realize that their contribution is being valued by the project, and they're then willing to contribute more in the same way.

Sarah Dayan: 46:39

So speaking of money, that's an excellent segue to my next question lately, there has been several attempts at monetizing open source. We've seen many different ways like donations, some of the ways I've been criticized by the way, but the nations sponsorships, things like that more recently, VC funding has started for opensource projects. There are several projects now that are backed up by VC funds. I wonder, do you think opensource needs to solve this problem of monetization? Should opensource have a business model to, to begin with?

Nicholas Zakas: 47:14

I do think that opensource needs to solve this problem because the more projects that we have that businesses are dependent on the more risks that we have, as well as we saw with heart bleed and log four J uh, all of these projects that people are using and might not even know that they're using, these are actually significant security risks for companies. And in the past, we used to talk about like, well, the risk is if the maintainers stops maintaining the project and your company is reliant on it, then you can't get bug fixes, which is an annoyance, but not the end of the world. Now we're at the point where the problem, if a project goes unmaintained security risks to your company, to your company's customers. And that is where I think the only real solution is to figure out how to fund these projects at such a level that you can minimize that risk going forward, because open source soft, where is the way that so many startups get started, there's no way that they could get started if they needed to pay for the equivalent of the commercial versions of all of the projects that they're being built upon, it would just cost too much money. And I think that there is a responsibility then when those startups get their funding to start contributing some of that money back to the projects that they are reliant upon in order to grow their business. Because if you're able to get that companies started specifically built on the back of free and open source software, if you are then able to turn a profit, then I think that it's time to start funneling some of that money back to opensource projects. And there are a lot of companies in the past few years that are starting to do that, which is, but I think we need to move past the point where it's companies practicing altruism to fund open source projects, to having it be a fundamental part of their business model, that a certain amount of the money that we take in needs to go back to open source projects so that our business can give back to the projects that were built upon and ensure that we can continue using them going forward by paying the maintainers to continue maintaining those projects. And I do think it's so some point we are going to need some kind of government intervention to do that probably in the realm of tax credits of some sort, to really encourage companies to do that. Because if we have to continue relying on the kindness of companies, I don't think we're gonna make any progress going forward.

Sarah Dayan: 50:36

That's, uh, that's an excellent point. I definitely am grateful for the fact that more and more companies are trying to give back whether it's altruism or, uh, you know, PR to me is besides the point, as long as it gets done, but it's not a system. If it's not something that people can rely on, it is not a system. And the fact that you mentioned some kind of government intervention in the form of tax credit, for example, is really interesting because is no denial that technology is now everywhere. It might not have been the case 20 years ago and could have been easily, you know, overlooked. But today, even like, when I look at my city's website, because I need to register to both, or what of something like that, they have a website that is built on open source. Of course they are, and everybody is. And so we can no longer ignore the fact that our entire lives and human experience is being digitized. And that it happens on the labor of people who just take the time to do that on their free time. They're not being compensated and this is not sustainable. Um, so I think this is, this is really interesting. I, I want I'm wondering, because this is not something that exists yet. Are there things that you've tried to sustain ENT that either have failed and you can re as not really good ways and are they things that succeeded?

Nicholas Zakas: 52:13

Yeah. So we've definitely done a lot of experimenting in this realm. Uh, the first thing was approaching companies to sponsor the project directly, which was difficult. There were three companies that reached out initially saying that if we were to start collecting sponsorships, that they would donate, uh, which was part of the reason we started accepting sponsorships was because we knew that we had at least three companies willing to sponsor the project. Then we went through contacting companies individually, which is time consuming. It's difficult. A lot of companies are not set up to sponsor O open source projects, which means that you need to deal with their budgeting process, which sometimes can take an entire year to get through just to get money allocated for this purpose. You know, I, I spent a lot of time early on going through my network, asking them to find who the right person at their companies would be to talk to about sponsoring esent and then sometimes working with them on how to make budget for proposals to do that. And I wrote a whole post about that on my blog about everything that I had learned about how to talk to your employer, to help them figure out how to start donating to open source projects. Uh, and so the amount of time that took, uh, was definitely out of proportion with the number of sponsorships we got at the end. I'm still glad that I did it. Uh, there was a lot of learnings there, um, that hopefully will make that process easier for other people in the future. So I, I would say that that was a mild success. Another thing that we did was we put ads on our website and that I would say has been a success. We use carbon ads. So they're one of the ethical ad companies that are out there. Uh, and that has been a moderate success. We're bringing in about a thousand dollars a month through that ad placement, which is fantastic. A lot of people go to our website to read documentation. So that's just an easy way to monetize that traffic. Uh, we purposely kept it to just one ad because we didn't want to go the route of filling up every page with ads. That wasn't the type of experience we wanted for our users. We tried doing t-shirts and stickers, and that was a failure. We, none of us are marketers. So even though it seemed like a cool idea that never really brought in too many sales, even though we would periodically tweet about it or have somebody share it that really, I think in total, over the several years that we've had that shop up, I think has brought in less than a hundred dollars. So kind of cool to have, especially if people are going to conferences, um, but definitely not a big source of revenue for the project. And really the, the times where we have received the most in donations have been after we have talked about a problem that we were having with funding. So after we wrote about our experiment with having a part-time 20 hours a week maintainer and how that didn't work, because we didn't have enough money to really fund somebody at that level, nor did we have enough money to hire somebody full-time we, we ended up getting a bunch of donations after that, and that seems to coincide with other open source projects. I know when babble blog that they were running out of money, they got a big influx of donations as well. Uh, obviously it's not really a sustainable model. You need to complain about not having enough money in order to get donations, but that's been our experience so far.

Sarah Dayan: 57:12

So esent is the defacto JavaScript center right now. It has been that for a while. Uh, but it's not the first and it's not the only one. And I would love to understand what you learned from previous art, such as like JS hint, for example, which I used a few years back and what you are learning from newer kids on the block, like Rome, for example, which is trying to, to disrupt many different things in the JavaScript ecosystem, is it influencing the future of EES L are we going to see things that come from learning from the past and being pushed by what's coming?

Nicholas Zakas: 57:55

Absolutely. Uh, there's definitely a long history that ES lent is built upon. So I way, way about in the day when I was at Yahoo, I had created a custom version of JS lint for use on the homepage team in order for us to enforce our own standards. And JS lint of course, was not pluggable or extendable in any way. So you actually had to go, go right into the core and add it right there. Uh, and then I did contribute to JS hint as well. Uh, and a lot of the pain points I had from JS lint and JS hint, I addressed in lint the most obvious S one being the ability to have plugins custom rules, custom parsers, and stuff like that. Because for a little while, JS hint got stuck implementing S six. And when ES lint got waiting for APRI a to implement E six, we were actually able to switch to a different parser and just continue going. And so making esent pluggable, I think was one of the first decisions I made based off of my experience with JS LT and JS hint to allow ES LT to move faster. And the more pluggable it was, the more we were able to adapt as different things popped up. So when react came out with JSX, uh, we were able to use Facebook's custom par to allow ES lint Tolin react code, which gained ES lint. A lot of followers in the react act community because they couldn't use J ENT. And now going forward a Rome and Dino lint just came out. There's also RS lint, which is a Java script litter written in rust. Uh, these are all things that we are looking at to see what ideas might make sense for esent. Uh, right now we're actually in the process of looking to see if it will be possible to use the parser used in Dino ENT in esent just by plugging it in, uh, that that's actually just popped up within the last week, because those rust based parsers are obviously a lot faster than the JavaScript based parsers. And if you're going to, belying a large code base that could potentially give you some dramatic speed improvements overall, though, I I've always been of the mind that ES lint will not be the dominant JavaScript linter forever. And none of us on the team have any false delusions about that. Like at some point something is gonna come along. That's better, faster, and everybody will move on to that. Uh, and our goal is really just to continue improving ES LT in ways that make sense for the community. We are not in a competition with Rome or Dina, lint, or RS LT or anything like that. I, I do don't believe that that's the right mindset to have in the open source community. I think it's much healthier to think about making the best product you can build for the community that you have. And yes, if there are things that you can learn from other projects that make sense for your project, then yeah, let's pursue that. And let's see if we can make that work. But if we reach a point where other projects are just objectively better at solving the problems that ES lint is trying to solve, we may reach a point where we say, you know, it's not worth continuing the project. We should be encouraging people to use this other project. I don't know how far in the future that will end up being, but I know at some point it will happen and I started ENT to solve a particular set of problems. And if at some point in the future, some other tool is better at solving those problems. Then the whole team will be more than happy to let people know that and help with people's transit in onto whatever that better tool might end up being.

Sarah Dayan: 1:03:02

That's a great mindset and an excellent way to wrap this up. Nicholas, where can people go to find you online?

Nicholas Zakas: 1:03:10

So you can find me at my website, which is human, who codes.com. You can also find me on Twitter. I am at slick net, which is S L I C K N E T. I also do have a human who codes Twitter handle, but that's mostly just an automated feed, but you can get to me through there as well.

Sarah Dayan: 1:03:34

All right. And you can find me on Twitter, on front stuff, underscore IO, and, and you can find my work@zion.com. If you are interested in, Esly check it out online, the search is actually powered by Algolia. And if you're interested in Algolia, you can find us@algolia.com. We are also at Algoa on Twitter, Nicholas, thank you so much for chatting with me today. Thank you for your time. I learned a lot of things. It was really interesting listeners. I hope you enjoyed this. I hope you learn new things as well. Thanks a lot for following developer experience and stay tuned for the next episode. This was developer experience, a podcast brought to you by Algolia. You can find this podcast on your favorite podcast platform. We are on Spotify, apple podcasts, Google podcast, Pandora, overcast, everywhere. If you want to know more about Algolia check us out on algolia.com and we are at Algolia on Twitter.